编程频道|软件玩家 - 软件改变生活！
管理员组
文章数量:
人月神话读后感
首先人月神话中有许多内容，有些可能只有参与过大项目的人员才能真实感受到，因此我主要根据人月神话、没有银弹等几个小部分谈谈自己的看法
人月神话：
1、程序员不应该乐观主义
本章解释了为什么进度落后的项目通过增加人手也不能加快进度，总结就是不可避免的培训时间，且会打乱原有人员的进度（用于与新进人员进行沟通）。
但小型团队在减少沟通上的高效性在开发大的项目时无法套用（因此考虑该因素的影响在大型项目开发中无法回避）。
提出了外科手术式的模式：主刀医生实际操作，剩余团队为其提供支撑。一个人负责一件完整的事情，减小了交流的损耗，其他人为其提供支撑。个人理解：有一个最高级的编程人员负责所有代码的整合，他对需求及架构最了解，由他向所有其它人员发布任务并要求对应的接口，由他将所有的模块代码整合起来，其它人的水平不需要太高，能根据需求完成对应代码的编写即可。
总结就是：之所以人月不能等乘积交换，是存在新增人手的培训，即使一开始定许多人参与工作，沟通上又会存在损耗。有意思的问题是在这种情况下人月的定义是怎么来的？有点马后炮的感觉，因为没法估计准，除非有先验的经验，而且经验还只对工作量接近，参与人员数量接近的情况下有效。
没有银弹：
书中指出：解决管理灾难的第一步是将大块的“巨无霸理论”替换成“微生物理论”，不要指望有一个体系或者语言的诞生能解决所有的问题，这与软件的内在属性相违背。
硬件的发展过快，能实现流水线作业大大提高生产效率，个人观点：目前软件开源利用率还不够。还不能规模化根据需求产生代码，是需求不够细化还是？感觉这里的硬件是拿芯片举例，这样的话软件不应该由不同软件作为代表，而是更为基础的操作系统、开发环境作为代表，即其它软件产品的开发基于这个基础的软件，这样看，基础的软件也具有较高的生产效率。
个人疑问：复杂度为什么是软件的固有属性？如果封装库足够多，也都经过了测试，仅仅是这些库的组合所带来的问题也会很复杂吗？还是说没有专门的学科研究这样带来的问题及难点，因此像所谓软件工程史前时期一样，软件开发像小作坊一样问题重重。
“由于复杂度，列举和理解所有可能的状态十分困难，影响了产品的可靠性”，感觉类似机器学习中分类的问题？人能对学习过的事例举一反三，即使只满足部分属性，但这也导致人的判断并非一定是正确的，说明所谓“知识就是忘掉所有在学校学的东西剩下的”，人类擅长记忆的不是具体的例子以及规范，而是将其抽象、模糊后的属性，从而具有拓展性和易错性。让人从事编程并企图让完成代码没有错误，这与人模糊的认识世界的本质也相违背（用魔法打败魔法）。
从这个角度我反而认为不是软件本身的复杂性而是编程人员对实际世界的理解不够，当他不能想到有某种可能的时候，当然无法在初始编程的时候想到对其的处理。但不悲观的看，人都有试错成长的过程，一些所谓的不能提前预料到的状况能否根据以及发生的错误估计的事故案例引申出可能的问题呢？毕竟引申创新才是人优于机器的地方。
