- 并不是所有的努力都是成功的。（XIV）
- 简而言之，我相信由于人员的分工，大型编程项目碰到的管理问题和小型项目碰到的管理问题区别很大；我相信关键需要的是维持产品自身的概念完整性。
- 如果我们想解决问题，就必须试图先去了解问题。（4）
- 相同功能的编程产品的成本，至少是经过测试程序的三倍。（6）
- 相同功能的编程系统构件的成本至少是独立程序的3倍。如果系统有大量的组成单元，成本还会更高。（6）
- 它（编程系统产品）的成本高达9倍。然而，只有它才是真正有用的产品，是大多数系统开发的目标。（6）
- 首先，这种快乐是一种创建事物的纯粹快乐； 其次，这种快乐来自于开发对他人有用的东西； 第三，快乐来自于整个过程体现出的一股强大的魅力——将相互啮合的零部件组装在一起，看到它们以精妙的方式运行着，并收到了所希望的效果； 第四，这种快乐是持续学习的快乐，它来自于这项工作的非重复特性； 最后，这种快乐还来自于在易于驾驭的介质上工作。（7）
- 编程的快乐在于它不仅满足了我们内心深处进行创造的渴望，而且唤醒了每个人内心的情感。（8）
- 首先，苦恼来自追求完美；其次，苦恼来自由他人设定目标，供给资源和提供信息； 下一个苦恼——概念性设计是有趣的，但寻找琐碎的Bug却只是一项重复性劳动； 最后一个苦恼，有时也是一种无奈——当投入了大量辛苦的劳动，产品在即将完成或者终于完成的时候，却已显得陈旧过时。（8-9）
- 我认为，学习编程最困难的地方，是将做事的方式向追求完美的方向调整。（8）
- 事实上，只有实际需要时，才会用到最新的设想，因为所实现的系统已经能满足要求，并体现了回报。（9）
- 实现落后与否的判断应根据其他已有的系统，而不是未实现的概念。因此，我们所面临的挑战和任务是在实际的进度和有效的资源范围内，寻找解决实际问题的切实可行方案。（9）
- 首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设——一切都将运作良好。 第二，我们采用的估算技术隐含的假设人和月可以互换，错误地将进度与工作量相互混淆。 第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续的估算这项工作。 第四，对进度缺少跟踪和监督。第五，当意识进度的偏移时，下意识（以及传统）的反应是增加人力。（14）
- 对于软件任务的进度安排，以下是我使用了很多年的经验法则：1/3计划；1/6编码；1/4软件测试和早期系统测试；1/4系统测试，所有的构件已完成。（20）
- 开发并推行生产率图表、缺陷率图表、估算规则等等，而整个组织最终会从这些数据的共享上获益。（21）
- 向进度落后的项目中增加人手，只会使进度更加落后。（25）
- 项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。（26）
- 经验和实际的表现没有相互联系。（30）
- 实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本的、速度缓慢的、低效的，开发出的是无法在概念上机型集成的产品。（30）
- Mills建议大型项目的每一个部分有一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。也就是说，同每个成员截取问题某个部分的做法相反，有一个人来完成问题的分解，其他人给予他所需要的支持，以提高效率和生产力。（32）
- 外科医生（他亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档）； 副手（它的主要作用是作为设计的思考者、讨论着和评估人员。他需要详细了解所有的代码，研究设计策略的备选方案）； 管理员（他（外科医生）需要一个控制财务、人员、工作地点和办公设备的专业管理人员，该管理员充当与组织中其他管理机构的接口）； 编辑（编辑根据外科医生的草稿或者口述，进行分析和重新组织，提供各种参考信息和书目，对多个版本进行维护，并监督文档生成的机制）； 两个文秘（管理员和编辑每个人需要一个文秘。管理员的文秘负责项目的写作一直和非产品文件）； 程序职员（他负责维护编程产品库中所有团队的技术记录）； 工具维护人员（他的工作是检查他的外科医生所需要的工具，而不是其他团队的需要。工具维护人员常常要开发一些实用程序、编制具有目录的函数库以及宏库）； 测试人员（外科医生需要大量合适的测试用例，用来对他所编写的工作片段，以及对整个工作进行测试）； 语言专家（语言专家则寻找一种简洁、有效地使用语言的方法来解决复杂、晦涩或者棘手的问题）。（33-35）
- Mills概念的真正关键是“从个人艺术到公共实践”的变成观念转换。它向所有的团队成员展现了所有计算机的运行和产物，并将所有的程序和数据看作是团队的所有物，而非个人财产。（34）
- 首先，外科医生和副手都了解所有设计和全部的代码。这节省了空间分配、磁盘访问等的劳动量，同时也确保了工作概念上的完整性。 第二，不存在利益的差别，观点的不一致之处可以有外科医生单方面来统一。 另外，团队中剩余人员职能的专业化分工是高效的关键，它使成员之间采用非常简单的交流模式成为可能。（35-36）
- 扩建过程的成功依赖于这样一个事实，即每个部分的概念完整性得到了彻底地提高——决定设计的人员是原来的1/7或更少。（37）
- 在这里，可以认为整个系统必须具备概念上的完整性，要有一个系统结构师从上至下地进行所有的设计。要是工作易于管理，必须清晰的划分体系结构设计和实现之间的界限，系统结构是必须一丝不苟地专注体系结构。（37）
- 我主张在系统设计中，概念完整性应该是最重要的考虑因素。也就是说为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。（42）
- 只有当这些功能说明节约下来的时间，比花费在学习、记忆和搜索手册上的时间要多时，易用性才会得到提高。（43）
- 因此，易用性实际上需要设计的一致性和概念上的完整性。（44）
- 对于非常大型的项目，将设计方法、体系结构方面的工作同实现相分离是获得概念完整性的强有力方法。（44-45）
- 系统的体系结构指的是完整的和详细的用户接口说明。（45）
- 体系结构描述的是发生了什么，而实现描述的是如何实现。（45）
- 不能与系统基本概念进行整合的良好想法和特色，最好放到一边，不予考虑。如果出现了很多非常重要但不兼容的构想，就应该抛弃原来的设计，对不同基本概念进行合并，在合并后的系统上重新开始。（46）
- 实际上，产品的成本性能比很大程度上依靠实现人员，就如同易用性很大程度上以来结构师一样。（47）
- 在毫无限制的实现小组中，在进行结构上的决策时，会出现大量的想法和争议，对具体实现的关注反而会比较少。（47）
- Blaauw指出，整个创造性活动包括了三个独立的阶段：体系结构、设计实现和物理实现。在实际情况中，他们往往可以同时开始合并发地进行。（49）
- 基本回答是结构师和建筑人员之间彻底、谨慎、和谐的交流。尽管还有很多值得关注的、更细致的答案。（54）
- 实际情况中，尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。（54）
- 面对估算过高的难题，结构师有两个选择：削减设计或者建议用成本更低的实现方法来挑战估算的结果。后者是固有的主观感性反应。此时，结构师是在想开发人员的做事方式提出挑战。想要成功，结构师必须： 1）牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配； 2）时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法； 3）对上述的建议保持低调和不公开； 4）准备放弃坚持所做的改进建议。 一般开发人员会反对体系结构上的修改建议。通常他是对的，当正在实现产品时，某些次要特性的修改会造成意料不到的成本开销。（54-55）
- 第二个系统是设计师们所涉及最危险的系统。（55）
- 一种普遍倾向是过分的设计第二个系统，向系统添加很多修饰功能和想法，他们在曾在第一个系统中被小心谨慎地放在次要位置。 开发第二个系统所引起的后果的另一个表现与纯粹的功能修饰和增强明显不同，也就是说存在某些技术进行细化、精炼的趋势。由于基本系统设想发生了变化，这些技术已经显得落后。（55-56）
- 结构师如何避免开发第二个系统所引起的后果，从而避免画蛇添足？是的，虽然他无法跳过二次系统。但它可以有意识关注这个系统的特殊危险，运用特别的自我约束准则，来避免那些功能上的过于修饰；根据系统基本理念及目的变更，舍弃一些功能。 项目经理如何避免开发第二个系统所引起的后果，从而避免画蛇添足？他必须坚持至少拥有两个系统以上开发经验结构师的决定。同时，保持对特殊诱惑的警觉，它可以不断提出正确的问题，确保原则上的概念和目标再详细设计中得到完整的体现。
时间： 2024-08-15 08:30:34