翻开扉页，购书日期：2003.2.10。实在汗颜，且此类书，我的案头还有许多。
在两周中抽出时间，翻看完了这本传说中的经典。
总的感觉，收获并不多，虽说有些东西并未能完全理解，但大多在作者看来是未来的东西，已早成为现实。大致看来，没有什么新的概念。
于是，也谈不上读后感，只是把看的过程中的笔记重新写一遍，当作另一个自已的索引吧。
(注：突然下决心，凡是看完一本书，都应有一篇读书笔记，否则，有可能就白看了)。
若干前言，序言，将本书称为神品。
来，看书吧。
一：焦油坑
编程是什么？许多人痛苦挣扎的焦油坑。它是乐趣与苦恼共存的创造性活动。
有些体会吗？没有，那你，转行吧。
二：人月神话
哇，这么快就切入主题了。
2.1：人月不能用来衡量工作的规模。但显然大家都是用这个来衡量，作者并未讲不用这个还能用啥。
2.2：1/3计划，1/6编码，1/4构件及早期测试 1/4系统测试。嗯，一半时间用来测试。我所在公司现在的状况确实如此。只不过领导们把
测试多是安排在了加班时间中。
2.3：向进度落后的项目中增加人手，只会使进度更落后。这有些绝对了，如果添加的人手得力，还是可以提升进度地。
三：外科手术队伍
嗯，这是很专业的队伍。
3.1：大型项目划分为若干部分，每一部分一个团队，团队按外科手术队伍的方式组建。外科医生难求噢。
3.2：由系统结构师来协调若干个外科医生。
四：贵族专制，民主政冶和系统设计
4.1：为了得到概念上的一致性，需要无任何歉意的贵族专制。
4.2：在稳定体系统结构下的实现的设计，同样需要创造性，不要低估或悲观。
4.3：体系结构未完成，编程人员做啥？作者说：很简单，体系统结构完成后，再雇佣他们。
4.4：有时，体系结构、开发实现、物理实现可以同时开始和并发进行。
五：画蛇添足
5.1：结构师与承包商与开发人员应该有良好的交流准则和机制。
5.2：设计师的第二系统往往会有毛病：一是过分设计，二是对已落后的技术进行细化和精练。
六：贯彻执行
6.1：文档化的规格说明很有意义，另外，可再进行形式化定义，一种为主，一种为辅。
6.2：周例会，年度大会的作用。
6.3：多重实现可保证定义更简洁，更规范。是这样的吗？
6.4：总结FAQ是好的工作方式。
6.5：产品测试小组是顾客的代言人。
七：为什么巴比伦塔会失败
7.1：失败的原因，缺乏交流以及相应的组织。
7.2：大型项目中的交流方式：电话，会议，手册。有些落伍了，呵呵。
7.3：项目工作手册的制作方式。
7.4：大型项目中的正确组织架构。其中，最关键的角色，产品负责人和技术主管的多种协作方式。
八：胸有成竹
8.1：对编程人员生产率的若干调查，得出结论：
8.1.1：我们总是对人员的工作时间做了不现实的估计，某些其余时间被忽略了，这差不多占一半时间。
8.1.2：交互越多，生产率越低，大致有1-3倍的差距。
8.1.3：使用适当的高级语言，可以将生产率提高5倍。
九：削足适履
9.1：程序空间也是成本，开发人员必须为此设计目标和实现。(显然，现在对此的要求大大降低了)
9.2：规模控制的方法：制定总体规模预算，个体间多交流勾通。
9.3：空间相关技能：功能与空间，空间与时间，技术积累。
9.4：数据的表现形式是编程的根本。仔细思考程序的数据会得到好的效果。
十：提纲挈领
10.1：文档的作用(在管理方面)：项目监督，预警，查查列表，状态控制，汇报的数据基础。
10.2：软件项目的关键文档：目标，技术说明，进度，预算，工作空间分配，组织图。
10.3：只有书面文档才是精确，可勾通，可检查的。
十一：未雨绸缪
11.1：构建一个试验性的系统，然后抛弃它。
11.2：为变更做准备，为变更设计系统。
11.3：为主更建立更强大的团队，组织结构要更灵活。管理与技术人员可互换，最小化人员间的接口。
11.4：程序维护通常是开发成本的40%,缺陷恢复通常以20%-50%的几率引入新Bug。
11.5：软件维护是提高混乱度的过程。
十二：干将莫邪
12.1：配备专门的工具管理人员的必要性。
12.2：我们需要的工具：目标(辅助机器)以及合理的进度安排(这点可能已经不是什么工具了)。编程工具，文档系统，性能仿真器。
12.3：解释高级语言与交互式编程。
十三：整体部分
13.1：整体考虑一个系统，我们需要：
使Bug更不易产生的方式来设计。
编写测试规格说明，采用精化方式，自上由下设计.
采用结构化编程。
13.2：早期测试的四步：本机调试，内存转储，快照，交互式调试。
13.3：系统集成调试的方法：使用经过调试的构件单元搭建系统。
十四；祸起萧墙
14.1：使用里程碑来控制进度。
14.2：采用关键路径技术来判断偏离的关键。
14.3：老板应该尽量减少角色冲突来得到更真实的报告。
14.4：需要拥有能了解状态真相的机制或者是通过计划和控制小组。
十五：另外一面
15.1：用“如何做”来代替说教之词。
15.2：程序文档的需求：使用程序，验证程序，修改程序的不同需求。
15.3：弱化流程图的作用，并简化之。
15.4：用程序来自动生成文档。
十六：没有银弹
16.1：软件的根本任务——打造构成抽象软件实体的复杂概念结构，它始终未得到改进，所以，生产率不能得到数量级的提升。
16.2：软件开发的根本困难是：规格说明、设计和测试这些概念上的结构(我没太明白噢)。
软件系统的内部特性：复杂性、一致性、可变性、不可预见性。
16.3：解决次要问题的一些方案：高级语言、分时、统一编程。
16.4：银弹的希望：
高级编程语言、面向对象编程、人工智能、专家系统、自动编程、图形化编程、程序验证、环境和工具、工作站。
16.5：针对概念上根本问题的有前途的方法：
购买构件、需求精练、快速原型、增量开发、培养卓越的设计人员。
十七：再论“没有银弹”
17.1：作者回应某些反驳“没有银弹”的评论。
17.2：面向对象技术的现实情况。
17.3：重用的情况。
十八：《人月神话》的观点：是与非？
复习人月神化中的重要的十五个观点。
十九：20年后的《人月神话》
19.1：概念完整性需要结构师来保证。
19.2：开发第二个系统的问题，再强调：盲目的功能，无确定的用户群，瞎猜。
19.3：图开界面的成功。
19.4：用增量开发模型取代不正确的瀑布式开发。
19.5：信息隐藏的重要，不应该对开发人员公布所有技术文档，大多数，接口足以。
19.6：人月配备与进度的平衡，再次进行证明。
19.7：人的作用决定一切，推荐《人件》一书。
19.8：构件开发。
19.9：软件工程的状态和未来。
应该说，第十九章是最重要，也是我们最应该关心的一章，但可惜的是，由于年代过于久远，并未看到什么新鲜的东东。
在两周中抽出时间，翻看完了这本传说中的经典。
总的感觉，收获并不多，虽说有些东西并未能完全理解，但大多在作者看来是未来的东西，已早成为现实。大致看来，没有什么新的概念。
于是，也谈不上读后感，只是把看的过程中的笔记重新写一遍，当作另一个自已的索引吧。
(注：突然下决心，凡是看完一本书，都应有一篇读书笔记，否则，有可能就白看了)。
若干前言，序言，将本书称为神品。
来，看书吧。
一：焦油坑
编程是什么？许多人痛苦挣扎的焦油坑。它是乐趣与苦恼共存的创造性活动。
有些体会吗？没有，那你，转行吧。
二：人月神话
哇，这么快就切入主题了。
2.1：人月不能用来衡量工作的规模。但显然大家都是用这个来衡量，作者并未讲不用这个还能用啥。
2.2：1/3计划，1/6编码，1/4构件及早期测试 1/4系统测试。嗯，一半时间用来测试。我所在公司现在的状况确实如此。只不过领导们把
测试多是安排在了加班时间中。
2.3：向进度落后的项目中增加人手，只会使进度更落后。这有些绝对了，如果添加的人手得力，还是可以提升进度地。
三：外科手术队伍
嗯，这是很专业的队伍。
3.1：大型项目划分为若干部分，每一部分一个团队，团队按外科手术队伍的方式组建。外科医生难求噢。
3.2：由系统结构师来协调若干个外科医生。
四：贵族专制，民主政冶和系统设计
4.1：为了得到概念上的一致性，需要无任何歉意的贵族专制。
4.2：在稳定体系统结构下的实现的设计，同样需要创造性，不要低估或悲观。
4.3：体系结构未完成，编程人员做啥？作者说：很简单，体系统结构完成后，再雇佣他们。
4.4：有时，体系结构、开发实现、物理实现可以同时开始和并发进行。
五：画蛇添足
5.1：结构师与承包商与开发人员应该有良好的交流准则和机制。
5.2：设计师的第二系统往往会有毛病：一是过分设计，二是对已落后的技术进行细化和精练。
六：贯彻执行
6.1：文档化的规格说明很有意义，另外，可再进行形式化定义，一种为主，一种为辅。
6.2：周例会，年度大会的作用。
6.3：多重实现可保证定义更简洁，更规范。是这样的吗？
6.4：总结FAQ是好的工作方式。
6.5：产品测试小组是顾客的代言人。
七：为什么巴比伦塔会失败
7.1：失败的原因，缺乏交流以及相应的组织。
7.2：大型项目中的交流方式：电话，会议，手册。有些落伍了，呵呵。
7.3：项目工作手册的制作方式。
7.4：大型项目中的正确组织架构。其中，最关键的角色，产品负责人和技术主管的多种协作方式。
八：胸有成竹
8.1：对编程人员生产率的若干调查，得出结论：
8.1.1：我们总是对人员的工作时间做了不现实的估计，某些其余时间被忽略了，这差不多占一半时间。
8.1.2：交互越多，生产率越低，大致有1-3倍的差距。
8.1.3：使用适当的高级语言，可以将生产率提高5倍。
九：削足适履
9.1：程序空间也是成本，开发人员必须为此设计目标和实现。(显然，现在对此的要求大大降低了)
9.2：规模控制的方法：制定总体规模预算，个体间多交流勾通。
9.3：空间相关技能：功能与空间，空间与时间，技术积累。
9.4：数据的表现形式是编程的根本。仔细思考程序的数据会得到好的效果。
十：提纲挈领
10.1：文档的作用(在管理方面)：项目监督，预警，查查列表，状态控制，汇报的数据基础。
10.2：软件项目的关键文档：目标，技术说明，进度，预算，工作空间分配，组织图。
10.3：只有书面文档才是精确，可勾通，可检查的。
十一：未雨绸缪
11.1：构建一个试验性的系统，然后抛弃它。
11.2：为变更做准备，为变更设计系统。
11.3：为主更建立更强大的团队，组织结构要更灵活。管理与技术人员可互换，最小化人员间的接口。
11.4：程序维护通常是开发成本的40%,缺陷恢复通常以20%-50%的几率引入新Bug。
11.5：软件维护是提高混乱度的过程。
十二：干将莫邪
12.1：配备专门的工具管理人员的必要性。
12.2：我们需要的工具：目标(辅助机器)以及合理的进度安排(这点可能已经不是什么工具了)。编程工具，文档系统，性能仿真器。
12.3：解释高级语言与交互式编程。
十三：整体部分
13.1：整体考虑一个系统，我们需要：
使Bug更不易产生的方式来设计。
编写测试规格说明，采用精化方式，自上由下设计.
采用结构化编程。
13.2：早期测试的四步：本机调试，内存转储，快照，交互式调试。
13.3：系统集成调试的方法：使用经过调试的构件单元搭建系统。
十四；祸起萧墙
14.1：使用里程碑来控制进度。
14.2：采用关键路径技术来判断偏离的关键。
14.3：老板应该尽量减少角色冲突来得到更真实的报告。
14.4：需要拥有能了解状态真相的机制或者是通过计划和控制小组。
十五：另外一面
15.1：用“如何做”来代替说教之词。
15.2：程序文档的需求：使用程序，验证程序，修改程序的不同需求。
15.3：弱化流程图的作用，并简化之。
15.4：用程序来自动生成文档。
十六：没有银弹
16.1：软件的根本任务——打造构成抽象软件实体的复杂概念结构，它始终未得到改进，所以，生产率不能得到数量级的提升。
16.2：软件开发的根本困难是：规格说明、设计和测试这些概念上的结构(我没太明白噢)。
软件系统的内部特性：复杂性、一致性、可变性、不可预见性。
16.3：解决次要问题的一些方案：高级语言、分时、统一编程。
16.4：银弹的希望：
高级编程语言、面向对象编程、人工智能、专家系统、自动编程、图形化编程、程序验证、环境和工具、工作站。
16.5：针对概念上根本问题的有前途的方法：
购买构件、需求精练、快速原型、增量开发、培养卓越的设计人员。
十七：再论“没有银弹”
17.1：作者回应某些反驳“没有银弹”的评论。
17.2：面向对象技术的现实情况。
17.3：重用的情况。
十八：《人月神话》的观点：是与非？
复习人月神化中的重要的十五个观点。
十九：20年后的《人月神话》
19.1：概念完整性需要结构师来保证。
19.2：开发第二个系统的问题，再强调：盲目的功能，无确定的用户群，瞎猜。
19.3：图开界面的成功。
19.4：用增量开发模型取代不正确的瀑布式开发。
19.5：信息隐藏的重要，不应该对开发人员公布所有技术文档，大多数，接口足以。
19.6：人月配备与进度的平衡，再次进行证明。
19.7：人的作用决定一切，推荐《人件》一书。
19.8：构件开发。
19.9：软件工程的状态和未来。
应该说，第十九章是最重要，也是我们最应该关心的一章，但可惜的是，由于年代过于久远，并未看到什么新鲜的东东。
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：http://jackxiang.com/post/1840/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
Linux在串口下接收数据时忽略了0X0D问题
【转】Eclipse + FDT + MTASC教程+学习心得，这本书不评论列表
