人月神话

按有用程度 按页码先后 最新笔记

• 

  第1页

  逆鳞 (考拉的一生也是很壮绝的！)

  “神话和传说中的魔术在我们的时代已变成了现实。在键盘上键入正确的咒语，显示出前所未有的或是已经存在的事物。 编程非常有趣，在于它不仅满足了我们内心深处进行创造的渴望，而且还愉悦了每个人内在的情感。“ 编程为什么有趣？作为回报，它的从业者期望得到什么样的快乐？ 首先是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到愉快一样，成年人喜欢创建事物，特别是自己进行设计。.. (更多)

  “神话和传说中的魔术在我们的时代已变成了现实。在键盘上键入正确的咒语，显示出前所未有的或是已经存在的事物。

  编程非常有趣，在于它不仅满足了我们内心深处进行创造的渴望，而且还愉悦了每个人内在的情感。“

  编程为什么有趣？作为回报，它的从业者期望得到什么样的快乐？ 首先是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到愉快一样，成年人喜欢创建事物，特别是自己进行设计。我想这种快乐是上帝创造世界的折射，一种呈现在每片独特、崭新的树叶和雪花上的喜悦。 其次，快乐来自于开发对其他人有用的东西。内心深处，我们期望其他人使用我们的劳动成果，并能对他们有所帮助。从这个方面，这同小孩用粘土为“爸爸办公室”捏制铅笔盒没有本质的区别。 第三是整个过程体现出魔术般的力量——将相互啮合的零部件组装在一起，看到它们精妙地运行，得到预先所希望的结果。比起弹珠游戏或点唱机所具有的迷人魅力，程序化的计算机毫不逊色。 第四是学习的乐趣，来自于这项工作的非重复特性。人们所面临的问题，在某个或其它方面总有些不同。因而解决问题的人可以从中学习新的事物：有时是实践上的，有时是理论上的，或者兼而有之。 最后，乐趣还来自于工作在如此易于驾驭的介质上。程序员，就像诗人一样，几乎仅仅工作在单纯的思考中。程序员凭空地运用自己的想象，来建造自己的“城堡”。很少有这样的介质——创造的方式如此得灵活，如此得易于精炼和重建，如此得容易实现概念上的设想。（不过我们将会看到，容易驾驭的特性也有它自己的问题） 然而程序毕竟同诗歌不同，它是实实在在的东西；可以移动和运行，能独立产生可见的输出；能打印结果，绘制图形，发出声音，移动支架。神话和传说中的魔术在我们的时代已变成了现实。在键盘上键入正确的咒语，屏幕会活动、变幻，显示出前所未有的或是已经存在的事物。 编程非常有趣，在于它不仅满足了我们内心深处进行创造的渴望，而且还愉悦了每个人内在的情感。

  (收起)

  2011-06-30 01:56:58   2人收藏   回应

  收藏

  推荐
• 

  第30页

  言若一不小心 (主动生活)

  Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。 (更多)

  Brooks法则：

  向进度落后的项目中增加人手，只会使进度更加落后。

  (收起)

  2011-09-04 22:06:28   2人收藏   3回应

  收藏

  推荐
• 

  第23页

  言若一不小心 (主动生活)

  作者多年经验总结出来的软件任务进度安排： 1/3计划 1/6编码 1/4构件测试和早期系统测试 1/4系统测试，所有的构件已完成 (更多)

  作者多年经验总结出来的软件任务进度安排：

  1/3计划

  1/6编码

  1/4构件测试和早期系统测试

  1/4系统测试，所有的构件已完成 (收起)

  2011-09-04 22:09:13   1人收藏   回应

  收藏

  推荐

• 

  第1页

  [已注销]

  　　在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢？ 　　首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设——一切都将运作良好。 　　第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。 　　第三，由于对自己的估算缺乏信心，软件经理通常不会有耐.. (更多)

  　　在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢？

  　　首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设——一切都将运作良好。

  　　第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。

  　　第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。

  　　第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动。

  　　第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。

  　　用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。

  　　人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流（图2.1）。这在割小麦或收获棉花的工作中是可行的；而在系统编程中近乎不可能。

  　　对于软件任务的进度安排，以下是我使用了很多年的经验法则：

  　　1/3计划

  　　1/6编码

  　　1/4构件测试和早期系统测试

  　　1/4系统测试，所有的构件已完成

  　　简单、武断地重复一下Brooks法则：

  　　向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later）

  　　概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。

  　　而进度压力却要求很多人员来开发系统。

  　　对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。

  　　如果要得到系统概念上的完整性，那么必须控制这些概念。这实际上是一种无需任何歉意的贵族专制统治。

  　　“没有规矩，不成方圆。巴赫曾被要求每周创作一篇形式严格的歌剧，但这似乎并没有被压制他的创造性。

  　　在开发第一个系统时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地工作。

  　　第二个系统是设计师们所设计的最危险的系统。而当他着手第三个或第四个系统时，先前的经验会相互验证，得到此类系统通用特性的判断，而且系统之间的差异会帮助他识别出经验中不够通用的部分。 一种普遍倾向是过分地设计第二个系统，向系统添加很多修饰功能和想法，它们曾在第一个系统中被小心谨慎地推迟了。

  　　一句古老的格言警告说：“决不要携带两个时钟出海，带一个或三个。”同样的原则也适用于形式化和记叙性定义。如果同时具有两种方式，则必须以一种作为标准，另一种作为辅助描述，并照此明确地进行划分。

  　　随着实现的推进，无论规格说明已经多么精确，还是会出现无数结构理解和解释方面的问题。显然有很多问题需要文字澄清和解释，还有一些仅仅是因为理解不当。

  　　显然，对于存有疑问的实现人员，应鼓励他们打电话询问相应的结构师。

  　　一种有用的机制是由结构师保存电话日志。日志中，他记录了每一个问题和相应的回答。每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。这种机制很不正式，但非常快捷和易于理解。

  　　卡内基－梅隆大学的D.L.Parnas提出了更彻底的解决方法1。他认为，编程人员仅了解自己负责的部分，而不是整个系统的开发细节时，工作效率最高。这种方法的先决条件是精确和完整地定义所有接口。

  　　如果项目有n个工作人员，则有（n2 - n）/ 2个相互交流的接口，有将近2n个必须合作的潜在团队。团队组织的目的是减少不必要交流和合作的数量，因此良好的团队组织是解决上述交流问题的关键措施。

  　　减少交流的方法是人力划分（division of labor）和限定职责范围（specialization of function）。当使用人力划分和职责限定时，树状管理结构所映出对详细交流的需要会相应减少。

  　　有一些技巧。例如，产品责任人可以通过一些微妙状态特征暗示来（如，办公室的大小、地毯、装修、复印机等等）体现技术主管的威信，尽管决策权力的源泉来自管理。

  　　巴比伦塔可能是第一个工程上的彻底失败，但它不是最后一个。交流和交流的结果——组织，是成功的关键。交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。

  　　生产率会根据任务本身复杂度和困难程度表现出显著差异。在复杂程度估计这片“沼泽”上的指导原则是：编译器的复杂度是批处理程序的三倍，操作系统复杂度是编译器的三倍8。

  　　项目经理可以做两件事来帮助他的团队取得良好的空间－时间折衷。一是确保他们在编程技能上得到培训，而不仅仅是依赖他们自己掌握的知识和先前的经验。

  　　另外一种方法是认识到编程需要技术积累，需要开发很多公共单元构件。每个项目要有能用于队列、搜索和排序的例程或者宏库。对于每项功能，库至少应该有两个程序实现：运行速度较快和短小精炼的。上述的公共库开发是一件重要的实现工作，它可以与系统设计工作并行进行。

  　　Cosgrove很有洞察力地指出，开发人员交付的是用户满意程度，而不仅仅是实际的产品。

  　　Cosgrove主张把所有计划、里程碑、日程安排都当作是尝试性的，以方便进行变化。这似乎有些走极端——现在软件编程小组失败的主要原因是管理控制得太少，而不是太多。

  　　不过，他提出了一种卓越的见解。他观察到不愿意为设计书写文档的原因，不仅仅是由于惰性或者时间压力。相反，设计人员通常不愿意提交尝试性的设计决策，再为它们进行辩解。

  　　在大型的项目中，项目经理需要有两个和三个顶级程序员作为技术轻骑兵，当工作繁忙最密集的时候，他们能急驰飞奔，解决各种问题。

  　　麻省理工学院核科学实验室的Betty Campbell指出特定版本的软件发布生命期中一个有趣的循环。如图11.2所示。起初，上一个版本中被发现和修复的bug，在新的版本中仍会出现。新版本中的新功能会产生新的bug。解决了这些问题之后，程序会正常运行几个月。接着，错误率会重新攀升。Campbell认为这是因为用户的使用到达了新的熟练水平，他们开始运用新的功能。这种高强度的考验查出了新功能中很多不易察觉的问题。5

  　　程序维护中的一个基本问题是——缺陷修复总会以（20－50）%的机率引入新的bug。所以整个过程是前进两步，后退一步。

  　　Lehman和Belady研究了大型操作系统的一系列发布版本的历史6。他们发现模块数量随版本号的增加呈线性增长，但是受到影响的模块以版本号指数的级别增长。所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。用在修复原有设计上瑕疵的工作量越来越少，而早期维护活动本身的漏洞所引起修复工作越来越多。随着时间的推移，系统变得越来越无序，修复工作迟早会失去根基。每一步前进都伴随着一步后退。尽管理论上系统一直可用，但实际上，整个系统已经面目全非，无法再成为下一步进展的基础。而且，机器在变化，配置在变化，用户的需求在变化，所以现实系统不可能永远可用。崭新的、基于原有系统的重新设计是完全必要的。

  　　系统软件开发是减少混乱度（减少熵）的过程，所以它本身是处于亚稳态的。软件维护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程。

  　　每个骨干人员都仔细地保管自己工作生涯中搜集的一套工具集，这些工具成为个人技能的直观证明。

  　　这种方法对软件项目来说是愚蠢的。首先，项目的关键问题是沟通，个性化的工具妨碍——而不是促进沟通。其次，当机器和语言发生变化时，技术也会随之变化，所有工具的生命周期是很短的。毫无疑问，开发和维护公共的通用编程工具的效率更高。 不过，仅有通用工具是不够的。专业需要和个人偏好同样需要很多专业工具。

  　　因此，项目经理应该制订一套策略，并为通用工具的开发分配资源。

  　　好的自顶向下设计从几个方面避免了bug。首先，清晰的结构和表达方式更容易对需求和模块功能进行精确的描述。其次，模块分割和模块独立性避免了系统级的bug。另外，细节的隐藏使结构上的缺陷更加容易识别。第四，设计在每个精化步骤的层次上是可以测试的，所以测试可以尽早开始，并且每个步骤的重点可以放在合适的级别上。

  　　一些糟糕的系统往往就是试图挽救一个基础很差的设计，而对它添加了很多表面装饰般的补丁。

  　　一次添加一个构件。在添加了新构件之后，用它们来测试子系统。因为那些原来可以在子系统上成功运行的用例，必须在现有系统上重新运行，对系统进行回归测试。

  　　对于大型开发项目中的估计行为，政府的承包商做了两项有趣的研究。研究结果显示：

  　　1. 如果在某项活动开始之前就着手估计，并且每两周进行一次仔细的修订。这样，随着开始时间的临近，无论最后情况会变得如何的糟糕，它都不会有太大的变化。

  　　2. 活动期间，对时间长短的过高估计，会随着活动的进行持续下降。

  　　3. 过低估计在活动中不会有太大的变化，一直到计划的结束日期之前大约三周左右。

  　　有两种掀开毯子把污垢展现在老板面前的方法，它们必须都被采用。一种是减少角色冲突和鼓励状态共享，另一种是猛地拉开地毯。

  　　减少角色的冲突。首先老板必须区别行动信息和状态信息。他必须规范自己，不对项目经理可以解决的问题做出反应，并且决不在检查状态报告的时候做安排。当项目经理了解到老板收到项目报告之后不会惊慌，或者不会越俎代庖时，他就逐渐会提交真实的评估结果。

  　　猛地拉开地毯。不论协作与否，拥有能了解状态真相的评审机制是必要的。PERT图以及频繁的里程碑是这种评审的基础。大型项目中，可能需要每周对某些部分进行评审，大约一个月左右进行整体评审。

  　　每一份发布的程序拷贝应该包括一些可以例行运行的小测试用例，为用户提供信心——他拥有了一份可信赖的拷贝，并且正确地安装到了机器上。

  　　Parnas澄清了术语上的混乱： 现在有两种差异非常大的AI定义被广泛使用。AI-1：使用计算机来解决以前只能通过人类智慧解决的问题。AI-2：使用启发式和基于规则的特定编程技术。在这种方法中，对人类专家进行研究，判断他们解决方法的启发性思维或者经验法则。 (收起)

  2011-05-15 13:16:11   回应

  收藏

  推荐
• 

  第1页

  edwin.z.w (吉他 摄影 程序)

  tp311.52 (更多)

  tp311.52 (收起)

  2011-05-28 14:25:03   回应

  收藏

  推荐
• 

  第1页

  edwin.z.w (吉他 摄影 程序)

  tp311.52 这里 (更多)

  tp311.52 这里 (收起)

  2011-06-26 11:13:11   回应

  收藏

  推荐

• 

  第63页

  言若一不小心 (主动生活)

  <原文开始></原文结束>当正在实现产品时，某些次要特性的修改会造成意料不到的成本开销 (更多)

  <原文开始></原文结束>当正在实现产品时，某些次要特性的修改会造成意料不到的成本开销 (收起)

  2011-10-19 10:56:03   回应

  收藏

  推荐
• 

  第53页

  爱咋地咋帝

  系统的概念完整性决定了其使用的容易程度。不能与系统基本概念进行整合的良好想法和特色，最好放到一边，不予考虑。如果出现了很多非常重要但不兼容的构想，就应该抛弃原来的设计，对不同基本概念进行合并，在合并后的系统上重新开始。 (更多)

  系统的概念完整性决定了其使用的容易程度。不能与系统基本概念进行整合的良好想法和特色，最好放到一边，不予考虑。如果出现了很多非常重要但不兼容的构想，就应该抛弃原来的设计，对不同基本概念进行合并，在合并后的系统上重新开始。

  (收起)

  2011-09-16 10:25:04   回应

  收藏

  推荐
• 

  第43页

  言若一不小心 (主动生活)

  整个系统必须具备概念上的完整性，要有一个系统结构师从上至下地进行所有的设计，要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界限，系统结构师必须一丝不苟地专注于体系结构。 概念的异质性、原则及主要功能上的整体设计至关重要，但是设计与具体实现之间会有差距，这个差距如何解决？尤其是遇到可A可B的情况，是严格按照设计还是遵从于资源及其他限制？ (更多)

  整个系统必须具备概念上的完整性，要有一个系统结构师从上至下地进行所有的设计，要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界限，系统结构师必须一丝不苟地专注于体系结构。

  概念的异质性、原则及主要功能上的整体设计至关重要，但是设计与具体实现之间会有差距，这个差距如何解决？尤其是遇到可A可B的情况，是严格按照设计还是遵从于资源及其他限制？ (收起)

  2011-09-08 23:09:01   1回应

  收藏

  推荐