人月神话---软工读物。

读人月神话

1、焦油坑

媒体吹嘘个人英雄主义，说一个跨时代的软件产品通常都是两个小伙子在自家的车库里面随便做做就出来了。这就吸引了许多年轻人相信自己也是这样的大神。但是我们编程是有乐趣的，我们个人编程是为了什么？是为了创造出本不属于这个世界的东西，或者把自己的想法展现出来，并帮助别人，并且在和别人配合上得到我们预期的结果。
但是并非每个人都可以成为大神，每个人都会忍受不断去调试BUG，而且要接受不断学习的过程，这些过程是枯燥的耗时的。我们在焦油坑煎熬着，快乐着，这就需要我们拥抱快乐忍受痛苦，成功的在焦油坑生活的时间长些。

2、人月神话

为何我们给了项目充足的时间，但是还是时间还是不够？
这是因为我们按照一种常见的思维逻辑去解决了，当我们碰到快来不及的时候，尤其是在其他行业都会出现一种解决方法，那就是利用增加人数来解决问题。这个解决方法对于创建软件是适用的嘛？
不，不适用，软件的创建是一项创造性活动，其他行业可以用此法解决的大都也都是流程固定的，没有太大思维发挥余地的工作，你设想一个歌手创造歌曲假如说一个月一首，那么你就那么肯定我安排两个歌手就会一个月创造出两首以及两首以上的歌曲了嘛？不一定吧，这两个人会不会因为创作的分歧而打起来都是一个很正常的问题。
除此之外，软件是服务与用户的，那么也就意味着我们需要对我们开发的软件针对的用户有足够的了解，这也意味着我们开发这个系统之前是花费了极大的时间去调查和研究用户的需求。
Ok，假设你开发的是一个很有创新性的软件，那么你再你得项目中加入新的伙伴的时候，你需要告诉新的伙伴你现在开发到哪了，告诉他软件开发的种种情况，这个时间的耗费是巨大的，而且要是一个新手来的话，你还需要对他进行培养，总结一下，增加人数不会是得速度变快，从整体来看交流的耗时，和新手理解上下文的耗时会极大的减慢我们的速度。这也就是所谓的人月。
而且我们要考虑一个问题，加速开发是不是可以做？可以，那就会是像厨师做菜开大火一样，毫无用处，反而会使得菜变得极为难吃。

3、外科手术队伍

承认吧，普通人和天才之间的差别是巨大的。正如邵东老师在课堂说的那样，两个坐在一起的程序员，他们的薪资差别不到一倍，但是开发能力可能差了一百倍，这一点是经过调查研究的。那么我们怎么根据这样的特点去利用其来加快我们的软件开发速度和质量呢？
简单来说我们要对每个人根据其特点来分工，而并非让所有人都去解决同一个问题，要分工，由一个经验老道的主程序员进行规划，有副手来给主程序员出谋献策，管理员负责管理等等。

4、贵族专制、民主政治和系统设计

概念的完整性对于提升效率，以及软件整体的质量来说是至关重要的。那么怎样确保概念的完整性呢？我们如果选择一群各有各的想法的程序员来进行民主选举，那么会导致因为观念不同而争论不休，这时候最有效的方法就是专制，专制不一定是一个人也有可能是一群少数但是观念相同的人员。这样的话就尽可能的确保了我们体系结构的完整性。但在等待体系结构设计的过程中程序员会无所事事。但我们现在有方法去解决，把时间错开，再确定需求后的一天左右先确定大框架，然后让程序员去学习以及模拟实现，按照他们的想法让他们各自实现，这并不是无意义的，当他们有好的实现的点子可以保存着等到真正实现的时候充分的利用上去。这就是程序员的创新之处。从而可以大大减少没必要的时间浪费，提高效率并且使得概念完整性大幅度提升。

5、画蛇添足

这里的画蛇添足主要反应在结构师在设计与第一个系统类似的第二个系统之时。刚开始的第一次大家都很仔细，这很正常。但是有了第一次的“成功”之后，人就开始不满足，要知道人是最贪婪的生物，当然也是这种贪婪促使着我们人类的进步。在开发第二个系统的时候那么他会根据自己的想法来给第二个系统加上各种各样复杂的功能，然而这些功能本可以推迟到第二次迭代的时候再去实现（第一次我们应该尽快拿出一个可用的系统展示给用户，让用户得以追加投资）。这样做的结果就是不停的加功能，不停的推迟时间。最后创造出来一个预算和时间双双超标的系统。对于这样的结果也不必完全责怪结构师，因为他们也没办法。人的天性不是那么好改变的。那么对于此的解决办法就是让两个结构师互相说，这样有着比较，就会较好的控制流程。

6、贯彻执行

千里之行始于足下，要干，不能坐在那说空话。但是如何确保我们干了，且按照正确的道路走着呢？
首先是要手册，要精确的定义规定了什么和没有规定什么。其次是形式化定义，这样的形式化定义方便大家理解，同时减少了沟通的时间浪费。然后要开会，虽说天天开会不可取但是周会和年会还是有必要的。周会主要是创新，小组内部的。年会的话是处理堆积的问题以及学习技术。记录电话日志，在周会的时候分发，避免其他人出现了相同的问题。最后要关注测试，一旦出现错误就要立即修复。

7、为什么巴比伦塔会失败

交流的重要性，设想下你与你得同事一个说的英语一个不懂英语只会中文，那么你们有可能将这个同事关系保持多久呢？
那么怎样才能确保有效的沟通交流以及组织呢？对于交流推荐是通过非正式途径，会议，工作手册等来达到共识。对于工作手册要保证及时更新这样才会使得我们每次看到的都是最新的内容。但是过度的交流也是浪费时间降低效率的毒手，所以我们需要减少不必要的交流，这就需要我们对于工作内容的划分，也就是构造树状组织架构。

8、胸有成竹

一个人的生产效率并非我们想的那么简单。首先人不是机器，人是需要进行休息和会出现各种各样意料之外的情况的。同时我们开发软件也不可以单纯的几个程序员坐在那里不进行任何沟通交流一个程序就被开发出来了，这是不现实和不可靠的。我们的沟通和交流也是消耗时间的。那么这也就意味着我们无法对于系统编程的工作量进行精确的估计。

9、削足适履

我们要学会控制，这个观点在之前的硬件是应当如此，但是现在的硬盘是如此之大，以至于我们可以很少的考虑硬件的问题，而将自己的注意力集中于代码编写。但是一个良好的程序员虽说可以不考虑硬件的问题，但是对于软件的相应速度还是应当给予适当的注意的。我们都希望自己的软件可以给用户更快的反馈，比如说我们的时间复杂度从O(n^2)到O(logn)这就是很大的进步，当然如果能到n那就更好啦。

10、提纲挈领

文档特别重要，我们看文档主要就是从其中找到我们的目标，看出来我们需要用到哪些技术，在什么时间，预算是多少，工作怎么分配的，都和哪些人一起。同时文档还会给我们说明出为什么会出现问题，以及我们可以根据文档进行必要的更改和调整，这样的话所有的一切都是有迹可循的了，

11、未雨绸缪

世界上最大的不变那么就是变化，这句话我特别喜欢。我之前在生活大爆炸上看到过这句话，这几天又反复咀嚼，很明显的我们的软件产品是要满足用户的需求的。用户是人吧，是一群人吧。很少我们编写一个软件是为了某一个人进行服务的。那么就会出现一个问题随着我们和用户越来越接触，用户的需求也会逐渐变化，这是正常的。如果我们是用户的话，我们也会希望系统可以随着我们的思维的变化迅速变化。于此同时这也是为什么程序员不愿意进行文档书写。不是我们懒惰，而是有可能今天我照着用户和我达成的共识列了一个文档，然而明天用户的需求就有可能发生变化。因此我们需要为了变更来规划系统和组织架构，在交付后的修复缺陷以及增加新功能的时候，必定会引入新的BUG这时候不要惊慌，我们软件就是如此，即使是最牛的大神来了也只是放缓引入BUG的速度。

12、干将莫邪

关于开发所用的工具，文档工具，还有各自的程序库，现在由于信息的发达我们在各个网站很容易获得这方面的知识。

13、整体部分

软件的每个部分我们都可以写，我们也可以写任何程序，但是问题是我们写的程序真的没问题吗？为了尽可能减少BUG我推荐自顶向下设计这样我们可以很好的避免一开始就考虑的特别多进而导致失败的场景出现。同时要进行系统集成测试，但是我们每个测试阶段都要尽可能大些，不然很容易现如到具体的细节，进而导致我们开发的不稳定。

14、祸起萧墙

项目的延迟，以及预算的超支，往往都是因为一件一件小事积少成多而导致的。我们不否认PERT图的好处，但是人往往会比较其他人的模块的开发速度总会晚于我们，那么我们稍微迟一点也没什么问题吧。结果就会真的都出大问题了。同时老板要对项目经理报以信任，给与支持，不要越俎代庖。

15、另外一面

16、没有银弹—软件工程中的根本和次要问题

我们永远无法规避的问题，也就是软件的内在特征：复杂性，一致性，可变性和不可见性。