人月神话阅读笔记01

第一章：焦油坑

 编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”，提供了五种

乐趣：
 创建事物的快乐
 本书第一章就明确的讲述了编程职业的乐趣，无论是创建事物的乐趣，还是简单学习的乐趣，还是驾驭介质之上的乐趣，还是开发了对人类有用的产品的乐趣等等。这些是每一个编程人或多或少都会体会到的乐趣。书中的一句话，我就体会尤为深刻：对于编程人员而言，对其他的依赖是一件非常痛苦的事情。这使我想起之前自己入门的时候，不会自己动手，也不会尝试的去解决自己的问题，只会依靠大佬，寻求他的帮助，只要有bug,就会第一时间想到寻求他人。只有自己真正地走出那一步，真正地自我完成或者解决一个问题之后，这样才会有很大的收获。现在的我感觉就在不断地成长一样，即便有点缓慢，但是我深知那才是真正属于我自己的东西。之后我会尽量的学会自己去解决问题，然后有目的性的去寻求帮助，有目的性的去学习。
 面对不重复的任务，不间断学习的乐趣 //学习总是充满了乐趣 说明你还是热爱这个领域的
 工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动，其存在、移动和运转方式完全不同于实际物体。

 同样，这个行业具有一些内在固有的苦恼：
 将做事方式调整到追求完美，是学习编程的最困难部分
由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）；权威不等同于责任
 实际情况看起来要比这一点好一些：真正的权威来自于每次任务的完成
 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外

 人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢（感同身受，对于想要尽快完成的任务往往越想越慢，还是要静下心来慢慢思考，保持之前的速度，心静下来，我就是比较毛躁的一个人，遇到事情容易慌张，我希望我自己可以改掉这个毛病，于是冷静，遇到最后的关头越要冷静）

 产品在即将完成时总面临着陈旧过时的威胁

第二章人月神话

1. 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。

2.书中说所有的编程人员都是乐观主义

3. 我们的构思是有缺陷的，因此总会有bug。（对于bug来说我遇到问题会想到自己解决，但是自己抵御软件跟编程的知识有限代码中的bug会越来越乱，自己的信心会越来越少）

4. 我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。

5. 在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。

6. 关于进度安排，作者的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。

7. 因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。（对于老师的压迫，我们往往是抱着反抗，并没有积极的去面对我们应该积极的面对而不是去埋怨去抱怨，这是提升自己的一个很好的机会）

8. Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。Brooks法则，人月神话一文的核心观点

9. 如何使得项目进度不落后；要想使得项目进度不落后，就要制定出合理的项目进度。

 

第3章外科手术队伍同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍。小型、精干队伍是最好的——尽可能的少。自己就是写代码的效率很低，可能感觉自己不是不会写，只是自己的马虎使一很小的问题导致程序的不运行，我找错误的时候心急，可能忽略的东西变很多，我还是需要增加我的耐心跟坚持能力，相信会变得很强大；对于真正意义上的大型系统，小型精干的队伍太慢了。 两个人的团队，其中一个项目经理，常常是最佳的人员使用方法实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本、速度缓慢、不充分的，开发出的产品无法进行概念上的集成。两个人的团队往往会进行互补，相互修补；才会互赢；

 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法——既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。

 概念完整性是系统设计中最重要的考虑因素。 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。 体系结构、设计实现、物理实现的许多工作可以并发进行。 

尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。 结构师如何成功地影响实现： 牢记是开发人员承担创造性的实现责任；结构师只能提出建议。听取开发人员在体系结构上改进的建议。第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计。关于这一点也许是正确的，但是这是一个回避不了的问题，如果没有开发第二个系统经验的人，就不可能有开发第三个系统经验的人了。对于自己所分配到任务需要及时跟自己组内的人进行沟通，可能两个或多个人的沟通可以有效的解决你们之间所遗留依旧的问题，是我们的任务可以更加的完善！