人月神话，人月神话
偶然发现以前看《人月神话》时抄下来的句子，现在看看，还是受益很多
----------------------------------
表面上看来没有任何一个单独的问题会导致困难，每个都 能被解决，但是当它们相互纠缠和累积在一起
的时候，团队的行动就会变得越来越慢。
系统编程进度安排背后的第一个假设为：一切都将运作良好，每一项任务仅花费它“应该”花费的时间
对于创造者，只有在实现的过程中，才能发现我们构思的不完整性和不一致性。因此，对于理论家
而言，书写，试验以及“工作实现”是非常基本和必要的。
用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间
是可以相互替换的。
无论多少个母亲，孕育一个生命都需要10个月
在时间进度中，顺序限制所造成的影响，没有哪个部分比单元调试和系统测试所受到的牵涉更彻底
向进度落后的项目中增加人手，只会使进度更加落后。
总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影
响还要大
这些研究表明，效率高和效率低的实施者之间的差别非常大，经常达到了数量级的水平
这就是小型精干队伍概念上的问题：对于真正意义上的大型系统，它太慢了。
要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界线，系统结构师必须一丝不苟地专注于体系
结构。
对于非常大型的项目，将设计方法，体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法
也就是说为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，
也不提倡独立和无法整合的系统，哪怕它们其实包含着很多很好的设计。
然而，我一直试图表达，并且我所有的经验使我确信，系统的概念完整性决定了
使用的容易程度。
实际上，产品的成本性能比很大程度上依靠实现人员，就如同易用性很大程度上依赖结构师一样。
体系结构陈述的是发生了什么，而实现描述的是如何实现。
如同Blaauw 所指出的整个创造性活动包括了三个独立的阶段：体系结构(architecture)
,设计实现(implementation),物理实现(realization)。在实际情况中，它们往往可以同时开始的并发地进行。
类似的，我观察到外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。
概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来自少数人的思想
同工作的水平分割相比，垂直划分从根本上大减少了劳动量，结果是使交流彻底时简化，概念完整性得到大幅
提高。
想要成功，结构师必须：
牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配。
时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到 目标的方法
对上述的建议保持低调和平静。
准备放弃坚持所作的改进建议。
是的，他无法跳过二次系统。但他可以有意识关注那些系统的特殊危险，运用特别的自我
约束准则，来避免那些功能上的修饰；根据系统基本理念及目的的变更，舍弃一些功能。
一个可以开阔结构师眼界的准则是为每个小功能分配一个值：每次改进，功能 X不超过M字节的内存和N微秒。
他只是坐在那里，嘴里说：“说这个！做那个！”当然，什么都不会发生，光说不做是没有用的。
手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物
。
...保持文字和产品之间的一致性....其实，对于在整个设计中，保证这些看似琐碎的问题的处理原则上的一致
性，决不是一件无关紧要的事情。
体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实现过程。
"决不要携带两个时钟出海，带一个或三个。“
显然，对于存有疑问的实现人员，应鼓励他们打电话询问相应的结构师，而不是一边自行猜测一边工作。
项目经理最好的朋友就是他每天要面对的敌人－－独立的产品测试机构／小组。
......现在整个大地都采用一种语言，只包括为数不多的单词。在一次从东方往西方迁徙的时程中，
人们发现了苏美尔地区，并在那里定居下来。接着他们奔走相告说：“来，让我们制造砖块，并把它们烧好。
”
于是，他们用砖块代替石头，用沥青代替灰泥（建造房屋）。然后，他们又说：“来，
让我们建造一座带有高塔的城市，这个塔将高达云宵，也将让我们声名远扬，同时，
有了这个城市，我们就可以聚居在这里，再也不会分散到广阔的大地上了。“
于是上帝决定下来看看人位们建造的城市和高塔，看了以后，他说：“他们只是一个种族，
使用一种的语言，如果他们一开始就能建造城市和高塔，那以后就没有什么能难得倒他们了。
来， 让我们下去，在他们的语言里制造些混淆，让他们相互之间不能听懂。“这样，
上帝把人们分散到世界各地，于是他们不得不停止建造那座城市。(创世纪， 11:1-8)
项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档
都必须是该结构的一部分。
减少交流的方法是人力划分和限定职责范围。
巴比伦塔可能是第一个工程上的彻底失败，但它不是最后一个。交流和交流的结果－组织，
是成功的关键。
实践是最好的老师。
实践是最好的老师，但是，如果不能从中学习，再多的实践也没有用。
Aron, Harr 和OS/360 的数据都证实，生产率会根据任务本身复杂度和困难程序表现出
显著差异。
对于常用编程语句而言。 生产率似乎是固定的。这个固定的生产率包括了编程中需要的注释，并可能存在错误
的情况。
使用适当的高级语言，编程的生产率可以提高5倍。
数据的表现形式是编程的根本。
技艺改进的结果往往是战略上的突破，而不仅仅是技巧上的提高。
...战略的突破常来自数据或表的重新表达－－这就是程序的核心所在。
为什么要有正式的文档？
首先，书面记录决策是必要的。只有记录下来，分歧才会明朗，矛盾才会突出。
第二，文档能够作为同其他人的沟通渠道。
最后，项目经理的文档可以作为数据基础和检查列表。
普遍的作法是，选择一种方法，试试看；如果失败了，没关系，再试试别的。不管怎么样，
重要的是先去尝试。
对于产品，影响了声誉，即使最好的再设计也难以挽回名声。
系统各个组成部分的开发者都会做出一些假设，而这些假设之间的不匹配，是大多数致命的难以察觉的BUG的主
要来源。
一次添加一个构件。
阶段化，定期变更。
项目是怎样延迟了整整一年的时间？。。。 一次一天
里程碑的选择只有一个原则，那就是，里程碑必须是具体的，特定的，可度量的事件，
能够进行清晰定义。
对于软件编程产品来说，程序向用户所呈现的面貌和提供给机器识别的内容同样重要。
文档：
使用程序。每个用户都需要一段对程序进行描述的文字。
1目的
2环境
3范围
4实现功能和使用的算法
5输入－输出格式
6操作指令
7选项。
8运行时间
9精度和校验
验证程序
没有任何技术或管理上的进展，能够独立地许诺十年内使生产率，可靠性或简洁性获得数量级上的进步
所有软件活动包括根本任务－－打造由抽象软件实体构成的复杂概念结构，次要任务－－
使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。
我认为软件开发中困难的部分是规格化，设计和测试这些概念上的结构，而不是对概念进行表达和对
实现逼真程度进行验证。
复杂性 一致性，可变性和不可见性
由于Ada采用的是抽象数据类型，层次结构的模块化理念，所有的Ada理念可能比语言本身更加先进。
60年代，曾在内存和速度成本上广受谴责的操作系统，如今已被证明是一种能使用某些MIPS的廉价内存的非常
优秀的系统。
增量开发－－增长，而非搭建系统。
简单地回顾一下，尽管很多杰出，实用的软件系统是由很多人共同设计开发，但是那些激动人心
拥有广大热性爱好乾的产品往往是一个或者少数伟大设计师们的思想。
那些相看到完美方案的人，其实在心底里就认为它们以前不存在，以后也不可能出现。
... 毕竟，我的从业背景是程序员，乐观主义是这个行业的职业病。
我们太过倾向于遵循我们自己的乐观主义（或者是发掘我们出资人的乐观主义)。我们太喜欢忽视真理的声音，
而去听从万灵药贩卖者的诱惑。
不幸的是，c++中帮助程序员避免错误的强类型检查，使得从小型事物中构建大型物体非常困难。
解决软件构建根本困难的最佳方法是不进行任何开发。
实际上，类的容易重用和通过继承方便地定制是面向对象技术最吸引人的地方。
[解决办法]
SF,JF.
[解决办法]
mark
[解决办法]
经典之作，jf！
[解决办法]
jf
[解决办法]
mark
[解决办法]
这本书，读过几百遍都不厌，我真有种冲动想把它背下来！
