软件何以为工程
人件
橘生淮南则为橘，生于淮北则为枳。
以人为本，环境塑造工作方式。
人件
原作名：Peopleware: Productive Projects and Teams
出版社：清华大学出版社，第二版作者：[美] Tom DeMarco / [美] Timothy Lister
译者：UMLChina
远远超过最终用户需求的质量是一种取得更高生产力的手段。
质量是免费的，但只是对那些愿意为此付出巨大代价的人而言。
把工作做好的惟一方法是制订一个不可能的、乐观的交付日期。
软件管理的七个不真实期望
- 有使你的生产力剧增的新诀窍，你已经错过了。
回答：你不会愚蠢到错过如此重要的东西。你在不停地研究新的方法，试图找出最重要的方法。 - 其他经理的成效是正100%、200%或者更多。
回答：忘掉它。通常向你吹嘘的魔术工具主要着眼于软件开发周期中的编码和测试环节。 - 技术正飞快地发展，而你正在被淘汰。
回答：是的，技术是在飞速发展，但是（又是高科技幻觉）你所做的大部分工作并不是真正的高科技。当机器已经发生了巨大变化时，商业软件的开发却已经是相当静态的。 - 改变语言将使你收获巨大。
回答：语言是很重要的，因为它们影响着你思考问题的方式，但话又说回来，它们只能对项目的实现部分产生影响。 - 因为待做的项目堆积如山，你需要立即加倍地提高生产力。
回答：大多地谈论堆积如山的软件项目是荒诞的。我们都知道项目的最终实际成本会大大超过我们一开始的估计成本。 - 其他任何事情你都顺其自然，是不是你对手下的软件开发人员也放任自由？
回答：这是高科技幻觉的另一个变种：相信软件开发人员能轻松地自动化地、完成工作。 - 如果将你手下的人置于很大的压力下，他们会工作得更好。
回答：他们不会工作得更好——相反，只是他们享受工作的乐趣减少了。
经理的职能不是强迫人们工作，而是让人们有可能工作。
有100万种方法使你丢掉一个工作日，但却没有一种方法把它补回来。
当你需要对任何事情做出度量的时候，总会有这样或那样的度量方法比选择干脆放弃度量要强。
记住你不只在收集数据，你还在帮助人们改变态度。根据你有规律地记录的不受打扰的时间，你在正是证明这个概念：人至少应该有一些不受打扰的时间。
人月神话
慢即是快，欲速则不达。
人月神话
原作名：The Mythical Man-Month: Essays on Software Engineering
出版社：清华大学出版社，第一版作者：[美] Frederick P. Brooks, Jr.
译者：UMLChina
编程为什么有趣？
- 这种乐趣来源于造东西的成就感。
- 这种乐趣来源于制造对他人有用的东西。
- 乐趣来源整个过程体现出的一股强大的魅力——将相互啮合的活动部件组装在一起，看到他们以精妙的方式运行着，并收到了预期的效果。
- 这种乐趣来源于持续的学习，来源于这项工作的非重复特性。
- 这种乐趣还来源于在易于驾驭的介质上工作。
编程固有的苦恼：
- 苦恼来自对完美的追求。
- 苦恼来自由他人来设定目标、供给资源和提供信息。
- 设计宏大概念是有趣的，但寻找琐碎的bug却是一项重复性的活动。
- 投入了大量的辛苦的劳动，产品在即将完成或者终于完成的时候，却已显得陈旧过时。
这，就是编程，一个让许多人痛苦挣扎的焦油坑，以及一项乐趣和苦恼共存的创造性活动。
在众多软件项目中，软件项目的进度安排不合理普遍发生的原因是什么呢？
- 我们的估算技术还很不成熟，说得更严重一些，它们反映了一个悄无声息但很不真实得假设——一切都将运作良好。
- 采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
- 由于对自己的估算缺乏信心，软件经理通常缺少安托万大厨那样的有礼貌的固执。
- 对进度缺少监控。
- 当意识到进度有偏移时，下意识（以及传统）的反应是增加人力。
缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。
人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。
在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。
关于进度安排，我的经验是1/3计划、1/6编码、1/4构件测试以及1/4系统测试。
Brooks法则：向进度落后的软件项目增加人手，会使进度更加落后。（Adding manpower to a late software project makes it later.）
尽早交流和持续沟通能使架构师有较好的成本意识，使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
想到成功，架构师必须做到以下几点：
- 牢记是建造人员对实现有创造性和发明性的责任，所以架构师只是建议，而不是下指令；
- 时刻准备好提出实现所指定事物的方法，同样准备接受其他任何能达到目标的方法；
- 对上述建议保持低调和不公开；
- 准备放弃所坚持的改进建议；
- 听取开发人员在体系结构上的改进建议。
在开发第一个作品时，架构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以会谨慎、仔细地工作。
在开发第一个作品时，他会对面不断产生的装饰和润色功能。这些功能都被留存在一边，以备“下次”使用。
第二个系统是一个人所设计过的最危险的系统。而当他着手三个及以后的系统时，先前的经验会相互验证，得到对此类系统通用特性的判断，而且系统之间的差异会帮助他识别出经验中不够通用的部分。
一种普遍倾向是过度设计第二个系统，向系统添加很多修饰功能和想法，它们曾在第一个系统中被小心谨慎地放在一旁。
第二个系统效应的另一个表现于纯粹的功能修饰有所不同，也就是说存在对某些技术进行细化、精炼的趋势。由于基本系统设想发生了变化，这些技术已经显得落后。
架构师如何避免开发第二系统效应？显然，他无法跳过第二个系统，但他可以有意识地关注这个系统的特殊危险，并加以额外的自我约束，来避免那些对功能的过多修饰，并避免延伸出会因假设和目的的变化而废除的功能。
项目经理如何避免第二系统效应？他要坚持要求，资深架构师至少有两个系统的经验。同时，保持对特殊诱惑的警觉，他可以提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。
一句古老的格言警告说：“不要携带两个时钟出海，而是带一个或三个。”同样的原则也适用于形式化和记叙性定义。如果同时具有两种方式，则必须以一种作为标准，另一种作为辅助描述，并照此明确地进行划分。这两者的任何一个都可以作为主要标准。
组织，是成功的关键。交流和组织的技能需要管理者付出大量思考，并具备与软件技术本身同等丰富的经验能力。
因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。“由于存在对其他人的各种假设，团队成员之间的理解开始出现偏差。
团队应该以尽可能多的方式进行相互之间的交流：非正式地进行简要技术陈述的常规项目会议，共享的正式项目工作手册。
除了运行时间以外，程序所占据的内存空间也是主要开销。特别师对于操作系统，它的很多程序是永久驻留在内存中的。
即便如此，花费在驻留程序所占据内存上的金钱仍是物有所值的，比其他任何在配置上投资的效果都要好。规模本身不是坏事，但不必要的规模是不可取的。
软件开发人员必须设立规模目标，控制规模，发明一些减少规模的方法——就如同硬件开发人员为减少元器件所做的事情一样。
在大型团队中，各个小组倾向于不断地局部优化，以满足自己的目标，而较少考虑对用户的整体影响。这种方向性的问题是大型项目的主要危险。
一旦认识到试验性的系统必须被构建和丢弃，具有变更思想的重新设计将不可避免，那么，面对整个变化现象就是非常有用的。第一步是接受这样的事实：变化是与生俱来的，不是不合时宜和令人生厌的异常情况。
程序员不愿意为设计书写文档，不仅仅是因为惰性，更多的是源于设计人员的踌躇——要为自己尝试性的设计决策进行辩解。
只要管理人员和技术人才的天赋允许，老板必须对他们的能力培养给予极大的关注，使管理人员和技术人员具有互换性；特别是希望在技术和管理角色之间自由地分配人手的时候。
具有两条晋升线的高效组织机构存在一些社会性的障碍，人们必须警惕并积极地同它做持续的斗争。
一天一天的进度落后比起重大灾难更难以识别，更不容易防范和更加难以弥补。
根据一个严格的进度表来控制大型项目的第一个步骤是制定进度表，进度表由里程碑和日期组成。
里程碑必须是具体的、特定的和可度量的事件，能进行清晰的定义。