Chapter 11 未雨绸缪
•试验性工厂和增大规模
对于大多数项目，第一个开发的系统并不合用。现在的问题是“是否构建一个实验性的系统，然后抛弃它”
为舍弃而计划，你一定要这样做
实话，没有看懂最后的结论。是翻译的问题么？作者的意思是说要构建一个第一版本的项目，并且做好舍弃的准备？那么，这个第一版本的项目是否要发布给用户进行使用呢？其实这个问题在现在看来已经是一个很普遍的现象了，通常情况下，无论哪个软件厂商都会发布一个beta版本供用户进行试用，然后进行改进，并且beta测试面向的受众数量也日益增加。这点在「the Cathedral and the Bazaar」这篇论文中有所提及，实际上beta版本号召所有用户参与进行测试的理念其实借鉴的是开源软件在这方面的思想，是的软件的健壮型增强，将软件测试的任务由仅仅交由专业人士处理扩散到了更多用户的头上。这样做是有意义的。
所以，Brooks的观点有待argue，暴露自己软件自身的缺点是否是一个不好的行为？或许在一些小应用上，未必不好（忽略某些金融领域的应用）。
抛弃原型的概念本身就是对事实的接受﹣随着学习的过程而改进
其实看到这里，可以理解Brooks倡导的是一种迭代开发的模型，并且他认为一开始的原型是肯定会被舍弃的。这个，在设计复杂系统的时候是这样，不可能有一开始就设计完美的算法，因为很有可能系统逻辑的复杂度会超过个人的掌控范围，而团队的逻辑设计则会牵扯到交流沟通方面的问题，针对大型复杂系统的设计做到天衣无缝，即使是花上很久的时间也未必是可行的，微软基本在3~5年的周期以几千个优秀工程师为团队，加上出色的管理者，也未必做到（至少现在还没做到…）。
∙为变更计划系统
变更的阶段化是一种必要技术。每个产品都应该有相应的数字版本号。
这个思想同样在raymond的论文中所提及，他同时也表示这个是Linux可以成功的关键之一。所谓的版本控制在今天看来已经是一件十分普遍的事情了，各种版本控制的工具已经十分成熟，如svn,cvs,github等等，包括许多商业化的软件也采用了Linux 命名法则模式，用来标识各个不同的版本。
•为变更计划组织架构
为变更组建团对比为变更进行设计更加困难。当系统发生变化时，管理结构需要进行相应的调整。
老板必须对他们的能力培养给予极大的关注，使管理人员和技术人员具有可换性。
比较了Bell实验室和IBM的做法，同样都是可行的，各有各的好处，应该是因为性质的不同而有所不同，管理者在用人的时候不应该过多的瞻前顾后，担心大才小用等等问题，果断的在适当的时候用适当的人解决问题即可。
•前进一步，后退两步
程序维护中的一个问题﹣缺陷修复总会以固定（20%~50%）的几率引入新的bug
这个是常见的问题，也是由于软件自身的复杂度造成的，但是诚如作者所言，机器在进步，配置在进步，到了一定程度之后必然需要在基于遗留系统的基础上进行新系统的重新设计。
软件开发是熵减的过程，所以它是处于亚稳态的，软件的维护是处于熵增的过程，只是放缓了系统退化到亚稳态的过程。
所以，根据这一论点我们可以推断出的就是原有软件在旧有基础上维护升级到达一定版本之后必然会导致全部地推倒重来，或许其核心的设计细想不会改变，但是必然会跟随硬件的发展而作出适应性的重新设计，正是由于其核心思想不变，故在很长一短时间内将会保留其与遗留系统的兼容性，从而兼顾用户体验，当新系统维护到一定时间渐渐对更新系统有所诉求时，将会抛弃上一代的主要特性，当然，这也是和硬件技术的不断发展分不开的（以上乃个人胡诌…）。
Chapter 12 干将莫邪
这章主要讲的是软件开发过程中用到的工具，包括软件平台和硬件平台
软件平台主要讲的是开发用的IDE环境也有，当然，当年只能是针对不同的编译器进行比较，还有就是选择的开发语言很重要。这点也是作者所指出的，项目管理人员同样要对这一方面作出相应的管理和规定，不同的开发项目应该选择不同的开发语言加以实现，在选择不同语言的同时同样要选取不同的编译器，编译器的优化性能不一样同样会影响到开发出的项目。
硬件上，首先是开发平台的统一。开发者需要在同样的开发环境中共同完成开发任务，其次是涉及到不同的目标机器上的测试时，也要考虑目标机器的选取。这两个硬件平台都是需要被考虑到的。
当然，本书写的年份因为比较早，所以很多东西在今天看来已经是习以为常了(¬_¬)
Chapter 13 整体部分
剔除bug的设计
关键的工作是产品的定义，许许多多的失败完全是因为那些产品未精确定义而造成的。
当遇到一些意想不到的问题时，按步就班的流程并不意味着步骤不能逆转，直到推翻顶层设计，重新开始整个过程。一些糟糕的系统设计往往就是试图挽救一个基础很差的设计，对他添加了各种表面装饰般的补丁。
首先，在「没有银弹」一文中，作者就提出了什么是软件开发过程中的主要部分，什么是软件开发过程中的次要部分。软件开发的难点就在于识别并且规格化一个软件，也就是文中所说的规格化。因为规格化的过程其实是一个明确软件要做什么的一个过程，规格的越详细，造成的歧义越少，那么软件开发的过程也就会越顺利，bug相应也会较少，同时，在软件开发的过程中，作者提到通常情况下，
我们采用的是自顶向下模块化开发，所以针对模块大小的划分就显得尤为重要。
•构件单元调试
本机调试：这个步骤的重大＂罪过＂是没有把程序划分成测试段，并对执行终止位置进行计划的前提下，就粗暴地按了＂开始＂。
内存转储：本机调试非常有效。
快照：有选择的转储､选择性跟踪和将快照插入程序。
交互式调试
测试用例
无论是使用何种先进的调试手段，良好的计划都是必须的，良好的计划是可以充分利用先进技术地有利保障，如果没有良好的计划,在先进的技术也是白搭。
•系统集成调试
系统调试的花费会比预料更长，它的困难证明了需要一种完备系统化和可计划的方法。
搭建充分的系统测试平台：测试平台指的是供调试使用的所有程序和数据。
一种测试的辅助形式是伪构件：仅由接口和伪数据以及一些小的测试用例组成。
微缩文件：仅包含典型纪录，但是涵盖全部描述的小文件。
特例：伪文件、辅助程序
测试没有详细的看过，完全欠缺这方面的知识。但是作者的意思大约是说，需要构建完整的测试用例，必须要避免乐观主义态度占的主导地位，我们需要假设的是系统中会有很多的错误，而不是一个，并且在测试的时候需要保持有良好的日志记录，修改后的代码以及之前含有bug的版本。
快速对于bug进行修复是我们需要有的态度。但是，我们修改完之后对于正式版本的发布还是要有一个阶段化的周期安排，而不是无序的
Chapter 14 祸起萧墙
•里程碑还是沉重的负担
里程碑的选择只有一个原则，那就是必须要是具体的，特定的，可度量的事件，能够清晰定义。
里程碑的边界和明显没有歧义，比他容易被老板核实更为重要。
定义里程碑是一项很关键的任务，在里程碑的选取上也需要十分讲究技巧，不是选择容易被核实的里程碑，而是选择容易被定义被理解被程序员接受的里程碑，容易被老板核实的里程碑未必是边界清晰的，迷糊的边界会造成进度的误报，有可能实际情况是无法被老板核实的。这也是项目进度会落后的原因之一。实际上，在商业项目的开发中，如果不是因为兴趣而聚集到一起的人进行的开发很有可能是无法完全准确地汇报当前的进程的。这点不管怎样都是很难解决的问题，除非你能保证每一个组员都对于这项任务又无可比拟的热情或是有共同的利益目标。
第二就是在里程碑的设置上，讲求的应该是一个短期快速实现，不断迭代估计设置的方法。我觉得里程碑不应该只在项目的开始时候设置一次，或者说，项目的每个阶段，甚至是每周都要明确里程碑，这实际上也是对于项目进度的一个控制，但是不宜设置过于频繁，过于频繁地设置会带来心理上的压力。
∙“其他的部分反正会落后”
并不是每一天的滞后都是灾难
随着项目的推进，PERT图为前面那个泄气的借口，“其他部分反正会落后”提供了答案。它展示了某人为了使自己的工作远离关键路径，需要超前多少，也建议了补偿其他部分失去时间的方法。
评价一个人的工作是不是滞后了，是不是会影响到项目整体的进度，不是单凭一个人某一天的计划完成的状况而制定的，而是根据项目的关键路径来进行判断的，根据这一个观点，可以找到项目滞后的原因，也可以找到着力点来进一步提高项目在下一阶段的生产效率。
第一份PERT图通常是很恐怖的
我们永远无法完美的制定计划‼注意，永远无法‼实际上无论计划的怎么好最后都会出现意料之外的变迁。后面调整的PERT图可能会更加适应本团队在该项目上的计划进度之类，可作为进度规划辅助参考工具之一。
•地毯的下面
有两种掀开毯子把污垢展现在老板面前的方法，它们都必须被采用。一种是减少角色冲突和鼓励状态共享，另一种是猛地拉开地毯。
在一个大型项目中，拥有一个计划控制小组是很有必要的，该小组首先是对于项目进度有一个控制，其次是对于未完成的部分进行一个计划。这点很像风险评估，一个项目组中，这样的小组存在是很有意义和必要的，尤其是大型的项目种，所有的计划评估均有项目经理来完成的话显然是不妥的。并且使用有经验的人来进行这一职务的担当更为有利。
•里程碑还是沉重的负担
里程碑的选择只有一个原则，那就是必须要是具体的，特定的，可度量的事件，能够清晰定义。
里程碑的边界和明显没有歧义，比他容易被老板核实更为重要。
定义里程碑是一项很关键的任务，在里程碑的选取上也需要十分讲究技巧，不是选择容易被核实的里程碑，而是选择容易被定义被理解被程序员接受的里程碑，容易被老板核实的里程碑未必是边界清晰的，迷糊的边界会造成进度的误报，有可能实际情况是无法被老板核实的。这也是项目进度会落后的原因之一。实际上，在商业项目的开发中，如果不是因为兴趣而聚集到一起的人进行的开发很有可能是无法完全准确地汇报当前的进程的。这点不管怎样都是很难解决的问题，除非你能保证每一个组员都对于这项任务又无可比拟的热情或是有共同的利益目标。
第二就是在里程碑的设置上，讲求的应该是一个短期快速实现，不断迭代估计设置的方法。我觉得里程碑不应该只在项目的开始时候设置一次，或者说，项目的每个阶段，甚至是每周都要明确里程碑，这实际上也是对于项目进度的一个控制，但是不宜设置过于频繁，过于频繁地设置会带来心理上的压力。
∙“其他的部分反正会落后”
并不是每一天的滞后都是灾难
随着项目的推进，PERT图为前面那个泄气的借口，“其他部分反正会落后”提供了答案。它展示了某人为了使自己的工作远离关键路径，需要超前多少，也建议了补偿其他部分失去时间的方法。
评价一个人的工作是不是滞后了，是不是会影响到项目整体的进度，不是单凭一个人某一天的计划完成的状况而制定的，而是根据项目的关键路径来进行判断的，根据这一个观点，可以找到项目滞后的原因，也可以找到着力点来进一步提高项目在下一阶段的生产效率。
第一份PERT图通常是很恐怖的
我们永远无法完美的制定计划‼注意，永远无法‼实际上无论计划的怎么好最后都会出现意料之外的变迁。后面调整的PERT图可能会更加适应本团队在该项目上的计划进度之类，可作为进度规划辅助参考工具之一。
•地毯的下面
有两种掀开毯子把污垢展现在老板面前的方法，它们都必须被采用。一种是减少角色冲突和鼓励状态共享，另一种是猛地拉开地毯。
在一个大型项目中，拥有一个计划控制小组是很有必要的，该小组首先是对于项目进度有一个控制，其次是对于未完成的部分进行一个计划。这点很像风险评估，一个项目组中，这样的小组存在是很有意义和必要的，尤其是大型的项目种，所有的计划评估均有项目经理来完成的话显然是不妥的。并且使用有经验的人来进行这一职务的担当更为有利。
Chapter 15 另外一面
•需要产生什么样的文档
不同用户需要不同级别的文档
•自文档化的程序
每个数据项包含两个文件都需要的所有信息，采用指定的键值来区别，并把它们组合到一个文件中去。
考虑到流程图方法的落后以及高级语言占统治地位，把程序和文档放一起显然是合理的。
本章一开始提到的文档化的方法正是我们现在常用到的文档化的方法，包括很多模板也是这样提供的。
但是文章后半部分所提到的“代码即文档”的观点，不正是当今所谓的敏捷开发所提倡的么？所谓的“代码重用的意义”不仅仅在于开发时候的代码重用，同样的，在文档的记载上也存在着重用这么一说，如果注释恰当规范，不仅仅是减少了代码阅读以及文档编写的难度，同时也提高了代码重用的可重用度，不是么？从某种意义上来说，代码如果可以构建话量产，那么必然需要合适的说明书，就好比是组装宜家的家具，价廉物美不乏设计性，但是大部分的器件仍旧是通用的，软件开发想要做到这一步，估计规范化是一个很大的难题，除非是系统计的应用开发，在一个新的软件出现很长时间内，只要构件规范，我觉得未必是不可能的，不过，话又说回来，软件的生命力在于不断的革新，可不可以以后就看作是这种元器件技术的不断革新？
有没有可能？
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
