这是最近看《人月神话》时中途记录的一些笔记，书终于看完了，还不错，这篇是书最后几章(16-19章)的笔记和自己的一些想法。
这篇作为最后一篇是最短的，主要是作者写完书后的总结
没有银弹
- 软件开发的根本任务是打造构成抽象软件实体的复杂概念，次要任务是用编程语言表达这些抽象实体，在空间与时间限制内将其映射为机器语言
- 民间传说中，最可怕的怪物是人狼，对付人狼的方法是银弹
- 由于开发难度的不断增大，一定要仔细进行市场调研，进行快速原型开发快速迭代，不断更新产品，不断培养新生代的杰出概念设计人员
- 软件开发难度不断增大的根本问题是概念结构不可避免的复杂性，而让人感到有解决问题的幻想的原因是计算机硬件无与伦比的发展速度
- 计算机软件实体可能比人类创造的其他任何实体都要复杂，而这个复杂度是不可改变的根本属性，因为这正是软件开发所追求的本质
- 而这个复杂性是所有开发成员都要一致面对的，水平的差别与复杂度的一致造成了开发的苦难
- 软件再由于易于更改的特性面临了无尽的变更压力
- 再加上软件本身结构的不可见性和无法可视化的属性，一切对软件逻辑的可视化手段都是徒劳，严重阻碍了成员间的沟通，构成了难度的叠加
- 尽管软件开发的根本困难无法解决，软件开发的很多次要困难在硬件的发展中不断得到解决：高级语言的流行，分时思路的应用，统一编程环境的推广
- 面向对象，更好的编程语言，人工智能，专家系统，可能成为更接近银弹的事物，这些技术的目标是让具体应用的复杂度与程序本身相分离
- 自动编程是不现实的，因为所谓的自动编程时，提给计算机的“目标”，常常就是问题的解决方法，也就是新的编程方法而已
- 图形化编程不现实，就如同流程图是不必要的一样
- 可视化程序不现实，因为即使使用流程图显示了逻辑，仍然有大量交叉引用，嵌套等复杂的情况，要么不显示要么杂乱无章
- 完美的程序验证不存在，因为很多缺陷是有条件的，不是必然发生，甚至是无法预见的
- 对环境和工具的开发有很大意义
- 硬件的提升并非银弹，就如同之前50年的发展意义，根本的复杂性无法解决
- 构建软件的最可能的彻底解决方案是不去开发任何软件，意思是通过购买已经制作好的软件进行少量自定义来符合需要，如Excel
- 计算机硬件与软件成本的比率在不断降低，昂贵的定制软件越来越成为负担，通用软件越来越流行
- 客户并不知道自己需要什么，所以快速可用的原型开发和然后与客户讨论并快速迭代才是必要
- 原型的作用是对重要的界面进行模拟演示，然后增量开发
- 增量开发的做法对士气有很大提升，但同时需要更好的概念设计和自上而下的开发
- 良好的设计需要完善的设计方法，卓越的设计需要天才般的设计人员，培养好的设计人员非常关键
- 产品的最终特色依赖于设计人员
- 培育好的设计人员的方法如下：
再论没有银弹
- 软件开发的必要部分是概念结构，次要部分是实现过程
- 目前来说，次要部分已经下降到工作的一半以下了
- 重用和交互的构件开发是解决根本问题的一种办法
- 软件的复杂性是最严重的内在困难，不可避免，最好通过在更高级别开发软件，使用已有的大构件拼接来简化这个部分
- 开发时需要注意做好层次化方便重用和增量化使系统能持续运行
- “没有银弹”的论述是合理的消极想法
- 软件的质量是开发的追求，系统的开发方法不是为了加速而是为了解决质量问题
- 当软件销量达到一定程度时，支配性问题就是质量，性能，维护成本
- 工具需要注意好人的使用方便，而不是专业性，易于定制有很大吸引力
- 开发时要有意识地使用更大的构件来创建
- 面向对象在整个开发周期中都需要运用，投入很大，但是收益在后续维护中才会体现，所以很多人不喜欢，但是这是非常有用的
- 当用户决定寻找构件比自己编写更加昂贵时用户会考虑重新开发
- 重用的模块常常是通用功能，所以很多构件无法重用，这是限制
- 可用的产品化的构件成本是单独开发的三倍，所以少见
- 随着高级语言越来越丰富和复杂，软件重用会面临越来越复杂的选择，越来越大的词汇量
- 类比于记忆单词，制作构件时要制作一些例子方便创造上下文记忆，且将功能（词义）详尽的构件放在一起
- 随着时代的发展（距离“没有银弹”发布已经过去10年），我们越来越可以关注于纯粹的概念设计了，但是银弹仍不存在，我们仍然应该关注于解决次要问题而非寻找通式
人月神话的是与非
- 这是对之前部分的总结，如果没有时间通读全书的话，专注看这一章节即可
- 软件系统可能是人类创造中最复杂的事物
- 在很长一段时间中，软件工程的焦油坑仍然会使人们举步维艰，无法自拔
二十年后的人月神话
- 《人月神话》是关于人与团队的书，所以是淘汰缓慢的
- 书关注的是如何在很多人共同工作时保持概念的完整性
- 架构师就像电影的导演，管理经理则是制片人
- 概念的完整性是产品质量的核心，架构师是迈向完整性的重要一步
- 开发第二个系统的后果是盲目的无用功能和错误的用户频率猜测
- 开发前需要定义好用户群：他们是谁，他们认为自己需要什么，他们实际需要什么，他们想要的是什么
- 架构师应该猜测一系列用户需求的频率来确认目标和分清主次
- 通过类别已有物来获得概念的完整性是很重要且有用的，例如图形界面的设计就极好地类比了现实世界
- 架构师的最大困难是如何平衡用户功能与易用性，理想解决方法是把易用功能和专业功能一起提供
- 传统的瀑布模型是错误的，因为它假定了开发的一次性和无需回退，且将测试放于末尾容易造成无法补救的性能问题和错误
- 实际应该用增量开发模型，从核心循环开始逐步增加，时刻保证产品的可用可运行
- 每个加入的功能都需要先经过测试，加入后应该有整体测试，应很早开始用户测试并按照预算开发
- 变化较小的决策应该放在产品树的根部
- 增量时软件应不断重建，一周一次甚至一天一次
- OO的封装隐藏思路是唯一提升软件设计水平的途径(存疑，接下来看设计模式)
- alpha版本(第一个版本)的里程碑最优时间应是估计工作量(人月)的立方根
- 无论安排多少人手几乎没有什么项目能提早25%的进度
- 建议在开发后期加入新的开发人月，此时他们会专注于完善已有功能而非改变
- 人员的素质，组织和管理是项目成功的关键
- 开发中途不要破坏团队的完整性
- 创造力来自个人，不要破坏个人的主动性和创造力，项目经理应该专注于设计架构和流程
- 给低级别组织保留自由度和责任能让效率更高
- 软件成本是开发成本与数量的比值，包装和宣传市场的成本非常高
- Excel宏命令式的元编程可能流行，应该给软件留下可以交互脚本的窗口（MOD）
后记
《人月神话》这本书我也是看了蛮久，基本每周都是看三小时，差不多100页，边看边写写画画，然后隔一天总结成字记录下来。
如今看完了这本书，我心里的感受和刚开始看的时候差不多，那就是这书对于还没有什么项目经历的人例如我来说可能感触有限。书中我感觉最最重要的其实是第18章作者自己做的总结，如果没有时间全看完的话，认真看完第18章应该就可以了。
软件工程确实是如今工业界的一大难题，这本书出版至今已近50年，书中描述的东西更多是当时的十多年前的事物，实在是历史久远。但是为何如今还是有那么多人和我一样会来阅读这本老书，我想也和作者说的一样，这本书说的是人与团队的问题，是淘汰非常慢的。
还没有参与过真正软件工程的我看完书也只能对其充满崇敬，心里希望从书中得到的那些许有些理解的经验教训能成为以后的借鉴。尽管软件工程的前路困难重重，但这并非没有希望的，而仅仅是不够成熟，就如同当年二战后飞速发展的化学工程一样。
在这最后我推荐所有从事计算机的人都去阅读下《人月神话》的结束语《令人向往，激动人心和充满乐趣的50年》，也在此引用第19章《二十年后的人月神话》最后作者的话，算是对自己还有所有看到这些文字的人的激励：
软件工程的焦油坑在将来很长一段时间内会继续地使人们举步维艰，无法自拔。软件系统可能是人类创造中最错综复杂的事物，只能期待人们在力所能及的或者刚刚超越力所能及的范围内进行探索和尝试。这个行业需要：进行持续的发展；学习使用更大的要素来开发；新工具的使用；经论证的工程管理方法的最佳应用；良好判断的自由发挥以及能够使我们认识到自己不足和容易犯错的——上帝所赐予的谦卑。 Frederick P.Brooks.Jr
