这是我学习人月神话的学习笔记。
人月神话的英文是《Man-Month Mythical》（人月其实是软件工程管理工程量的单位，一个人每月工作量的含义），本书也主要是说明单纯使用人月方式估算大型项目是不靠谱的，只是一个神话的估算方式而已，并由此开始阐述如何去构建大型复杂的系统。
我们面临的挑战和任务是在实际的进度和有效的资源范围内，寻找解决问题的切实可行方案。
在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。
这点深有感触，这也是PM存在的价值，如果项目缺乏规划后果一定是失败的，其实做人做事不是都是一样的嘛？
所有的编程人员都是乐观主义者
sign… 不要将自己陷入到自信和永久做不完任务的泥潭中 :）
最重要是很多时候，我们的估算都是理想的，一个方案搞定之后，大概只完成了50%，还有很多的问题和决策可能还要到执行层面去继续思考和解决（个人感受）
使用人月可以精确计算的情况是：人数和时间可以互换，所有的任务都可以有效的分解。
但在实际的项目中，这种情况几乎是不存在的…oops…
Brooks法则：向进度落后的项目增加人手，只会使进度更加落后。
作者的逻辑点在于，精度落后 -> 增加人手 -> 新人上手需要时间和别人教的时间 -> 反而得不偿失。
外科手术队伍： 小型项目可以使用，小而精悍的人员构成的团队。这样子的效率是高的。但是不适用于大型项目，因为对于大型项目而言，人数太少一定是慢的。这种情况下为了平衡好效率和概念完整性，最好是由少数干练的人员来设计和开发。
在这本书中多次提到了概念完整性的概念，结合自己的项目开发经验，这点确实非常重要。尤其是一些底层架构的设计和构思上，一定要有一个一致性的结论和方案，而不是大家各自搞成一套，也许这个设计上存在问题或者不完整的地方，但是可以调整，但是不可以违背设计的初衷，否则整理的概念完整性就被破坏了，这在项目后期的时候会用更多的工作量来修复因为设计迭代所导致的级联问题。
不过说回来，这确实是经验活，在开始的时候就考虑到需要做的事情，预留需要的接口，都是对整个业务体系有深刻了解的人 ：）
System 360 系统的一致完整性仅来自于两名作者，思路是多个人的结果，但是最终形成规定和文字说明的只有两个人决定。例如，System 360需要决定在每次操作之后，如何设置返回的条件码。看似这种琐碎的问题，但其实对于整个系统设计而言，这些琐碎问题处理上的一致性绝对不是一件无关紧要的事情！
简单说是细节决定成败，大了说，所有优秀的设计和大型项目的构建都是具有绝对的规律和自律的）
古老的格言：“不要携带两个时钟出海，带一个或者三个”
要么没有想法，要么就有备份的想法。
精湛的技艺出自创造，精炼，充分和快速，程序设计也是如此。技艺改进的结果往往是战略上的突破，而不仅仅是技巧上的提高。更普遍的情况是，战略上的突破常来自于数据或表的重新表达，这是程序的核心所在（数据结构为王，数据为王呀！！！）。如果提供了程序流程图，而没有表数据，我仍然会很迷惑。而给我看表数据，往往不用再看流程图，程序的结构是非常清晰的。
深有感悟，结构的设计，算法的设计都是为了数据服务的，有了数据的设计，所有的问题都会变得明了。同理，设计系统的不好，很大程序上因为数据结构设计的不好。这也说明在设计的时候，对于数据结构的设计需要给予充分的时间以及配对的文档描述，这对于后期的维护和开发都是大有裨益的。原谅我做为一个服务端程序的「个人偏见」认识。。
实际上，数据的表现形式是编程的根本。
好吧，直接上升到本质的层次了…oops
程序维护的一个基本问题：缺陷修复总是会以固定（20%-50%）的几率引入新的bug。所以，整个过程是前进两步然后后退一步。
修复bug的熵。
为什么缺陷不能更彻底的修复？首先，看上去很小的错误，似乎是局部操作的失败，实际上却是系统级别的问题。何况后期开发的人员不是最初编写代码的开发人员，而是一些初级程序或者新手，他们在设计的时候往往是没有考虑全之前的设计的，导致的问题是：看似简单的任务却导致很多的bug。
结合我自己的经验，在我们的项目后期，因为时间紧张，我将相对不复杂的开发工作给了新的的同学，本来以为是件简单的事情，但是后期却出现了很多的问题，甚至是非常严重的问题。
这点给我的反思就是即使非常简单的东西，也需要考虑好结构，然后指导新手去完成，而不是直接告诉他们功能去实现，需要你去设计好结构，然后让他再去实现。毕竟后期加入的同学不可能也不会有时间去掌握你之前的设计，何况之前设计也许也是糟糕的或者是有很多坑的，再其中增加东西，不是只是简单的功能堆积，很可能会产生连锁的反应。
我们的大脑具有的多样性，自我保护和自我更新的能力，其中的秘密就是逐步发育成长，而不是一次性搭建。开发模式也是如此，迭代增量的开发，这种模式迫切的需要自上而下的开发形态。
这么久之前就开始推崇迭代的开发模式了。
但是软件最重要的部分一定是：人。卓越的设计者和一般设计者的产品差异差了一个数量级。卓越设计者生产的成果更快，更小，更简单，更干净，实现的代价更少。
优秀工程师和普通工程师是量级的区别。
There is nothing in the world constant but inconstancy.
比如说感情。。。
我们理解也好，不理解也好，描述都应该简短清晰。
KISS
关于进度安排，我的经验是：1/3 计划 1/6 编码 1/4 构件测试 以及1/4系统测试。
同感，计划，写设计文档，说明文档，需要给予足够的时间！
每个人看到每件事的目标是错误的！各个部分应该被封装，从而没有人需要或者被允许看到其他部分的内部结构，只需要了解接口。
分层！不要指望知道所有的事情，好的设计应该是你只要知道自己合适的位置去做合适的事情即可。剩下的交给架构师考虑吧。当然这也是努力的目标。
能消除，至少是能指明有副作用的程序设计方案，对维护成本有很大的影响
不要依赖于有副作用的方式，或者tricky的技巧，这些都可能是后期evil的根源。还是KISS。
从学校毕业进入到工作环境，或者生产环境才意识到，清晰是多么的重要。
人就是一切（或者说，几乎是一切）。我们行业的主要问题实质上更侧重于社会学而不是科学技术。
黑客技术的最top技术是：socical hacking…
不要低估产品的难度，难度估计的高点总是没有错的。
在确定任务进度的时候要争取更多的时间，这点我容易犯下的错误，不要低估了时间，按时按量的完成任务才是关键，何况很多东西就应该有固有的时间，时间紧张了，临时的方案，后面都是需要更多的时间和精力去弥补的，为何不在开始的时候就多留一些时间，设计出一个更加有效，灵活的方案呢。程序员都是自信的，对于进度估算上尤其如此，所以以后自己需要更加合理的估算进度，时间估算的多点总是没有坏处的。
套用书中的一份法式餐厅菜单上的句子「做好菜是需要时间的。如果人家让您多等会儿，那是为了让您最后吃得高兴。」