人月神话读后感

[《希腊神话》读后感]《希腊神话故事》是一部沉重的书。人物的繁多和关系之复杂使人烦闷，叫人不忍卒读；而许许多多触目惊心的事情又使人感到压抑、沉闷，甚至是窒息。希腊神话中，无论是神袛还是神化...+阅读

[人月神话读后感]人月神话读后感、《人月神话》是预言了未来还是扼制了未来？事实是：我们目前的许多工程知识，——无论是从书上看到的，还是从实践中经验到的——大多未曾脱离《人月神话》之所言，人月神话读后感。我在开篇中说《人月神话》“是一本可怕的书”。然而我感受恳挚的可怕之处在于：现今凡是论及工程（且不要让人感受是离经叛道），那么所解说的定然是Brooks的这么的经验以及由此推出的见解，可能在不违拗这些经验和见解上的一些翔实的实作措施！我们全然不顾书中所言是假象，还是性质的推论，可能只是假象归纳的一个（未必准确的）答案。尽管这些答案大多数时候都好像预期地展目前你的切实工程中：原文中还有众多相仿的见解、假象和答案，都成为了切实工程中的既存假象。

先民们所说的圣人以及通神者，皆因他们多数时候在准确地预言自己的切实。只有当这个“多数时候”变成半点的时候，先民们才会置疑圣人和通神者的力气。其实我们懂得并未曾预言未来的人，大多数时候是两种情形导致的假象：他做出了准确的推断；你主观地跟随了他对未来的设定。后者是风险的。大师们预言了未来也就改换了未来，即便未来未必“该当”好像他所预言的那样。但万一这种预言的前提不准确，那么未来定然脱离这种波及而回到它该当的事态上去。好像我们看到的另一些事实一样，有许多假象阐明，我们正在归来工程***的道路上摸索前进。我们也觉察，在大多数情形下，先哲们的预言在实践中被检讨着，只是偶尔“不太灵光”。下表则列出一些不同的例子：注1：我例举了爽利的一些见解，并不阐明我是AP/XP的fans。

AP/XP的问题另论，在这里，我只是解释存在一种不同的信念。注2:Brooks尔后确认“定然丢弃原型”是一个不太准确的见解。注3:Brooks在这里未曾犯讹谬，只是他所谈论的是狭义的流程图，而我们例举的时序图则更广义。我们追忆上一细节，在《人月神话》中的那“31%的答案”的前提——也即便那7%的性质中，如下两项是显明猜忌的（也是重要置疑）：目标的性质：是大型工程，是系统项目，而不是过程个体的性质：是私利性的其实早就有人意识到个体的性质“未必全是私利的”，尊重这些个体就会带来一些收获。例如AP正是因为更尊重开发人员的禀性与力气，以及互相间的配合而获得了效率的晋级。再进一步地说，既然Brooks设定了“大型工程或系统项目”这么的目标，并给出了一些答案。

那么在“小那么一点点的”工程项目中，是不是这些答案就无须定了呢？例如Brooks的众多提倡，对于某些目标——例如你要用为期三个月的工夫开发一个的产品——就并不是很管用；可能大约无法厉行——例如你的群体总共只有6个人，连“外科手术式的群体”都组织不起来，读后感《人月神话读后感》。 Brooks的答案对于同样的目标，以及在他所述的“性质”未能发生改换时，还是比拟管用（或有厉行的可能性）。因而上述一些例外，总是在上述的“7%的性质”被抵赖或被改换的情形下获得的。因而我们提出的问题是“如何抵赖或改换”这些难以撼动的性质。然而在我看来，Brooks早曾经在最佳位置上，给出了撬动它们的一个支点： Brooks感受发生“自力更生小型过程”与“编程系统产品”是不同的问题。

Brooks谈论的编程系统产品的规模究竟有多大呢？我想起码该当是以IBM 360为参看的。不过书中在引用Joel Aron(IBM在马里兰州盖兹堡的系统技巧主管)的例子时说，“大型意味着过程员的数目超过25人，将近30,000行的号召”。而按照《人月神话》的数据：人均效率800号召/人年，则这个“大型项目”该当必需1.5年能力告终。另外，还必需大约一倍的人工，来负责除开代码之外的测验、管教、文档和沟通等工作。好的，万一你有一个“（起码）50人，开发一年半”的项目，那么你能够先接受Brooks的答案去实践一下：起码你能够有工夫来谈论工程问题，也能够组建那样规模的群体。然而，难道只有这么的“大型工程”才算得工程，而“小那么一点点”的就不算吗？切实是，我们一方面在做着“小那么一点点的”工程项目，另一方面在听着全副业界嘈杂着“为更大规模的工程”而准备的工程理论。

我们总在实践Brooks的“答案”可能“预言”，而淡忘这些答案的前提： Brooks的经验源自对IBM 360等大型项目标实践与分析； Brooks所述的工程是要获得编程系统产品； Brooks感受编程系统产品的工作量可能是自力更生小型过程的9倍（在告终大约雷同功能的情形下）。事实上我们目前的软件工程的进展是被驾驶了，而不是被预言了。从性质上来说，Brooks在《人月神话》中只是谈论了大型工程的厉行，以及相应规模下的群体创立。而我们，便按照这么的设定来摆开了全副软件工作的工程化厉行。促成这种现状的，并不但仅是一本书的能力，还在于商业的能力。因为只有在这么扩展开来的工作环境中，才可能有商业时机。——即便那些工程顾问与厉行专家历来未曾厉行过“50人，开发一年半”这么的项目，凡是他们能报出Brooks的名字，能谈及某些工具在应付“大型项目”中的获胜经验，他们就曾...

转人月神话读后感2

[【转】人月神话读后感2]

堵哥哥要我写人月神话的读后感，再找一篇膜拜一下~~~

————————————————————我是分割线————————————————————————

这本300多页（中文新版）的神书，在经过了20多年的历史之后，仍然畅销不衰，究竟是什么让它有如此的魅力？过去的一个月，一点一滴的阅读之中算是初步的了解到了它的一部分吧，【转】人月神话读后感2。

人月神话的核心观点：概念完整性和架构师

Brooks认为，一个整洁、优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型，这个模型描述了应用，实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。概念的完整性是易用性中最重要的因素。而架构师，则是负责保证产品所有方面的概念完整性的，架构师设计的是能够让用户理解产品概念的模型，这包括所有的功能的详细说明以及调用和控制的方法。它就像电影的导演一样。

我的理解：这里的概念完整性其实应该说的是这个软件理念上的业务流程的前后连贯，也就是用户在使用产品的过程中，能够按照唯一的一个的最高抽象的思路来使用这整个系统。

开发第二个系统的后果——盲目的功能和频率猜测

所谓第二个系统，指的是产品的第二个实际发布。开发第一个发布的时候会因为各种原因去消减不必须的功能，所以会简化问题，而在第二个版本的时候则常常想其中添加各种各样的功能（也许源于用户的功能建议）但是，却导致了灾难性的后果。

所以，在这种情况下，用户群越大，越不稳定，我们就更加应该明确的定义用户群，以获得概念的完整性。我们必须为整个设计团队定义一个共同的用户图像，记录下用户群的属性：

1.他们是谁

2.他们need什么

3.他们认为自己need什么

4.他们want什么

而另一方面，对于任何产品，任何用户群属性都是一种概率上的分布的，也就是每个属性都有各种可能的值，所以我们能做的是，架构师去猜测（guess）或者假设（postulate）一系列完整的属性和频率值。这里，清晰和错误都将比模糊不清好得多。

不同的社会经验，不同的思想状态，对读后的心得也会不一样.比如：

1.外科手术队伍TheSurgicalTeam项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任，读后感《【转】人月神话读后感2》。

2.如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确地理解，并精确地整合到产品中。

3.贯彻执行Passingtheword印象比较深刻的是”体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但他不应该支配具体的实现过程。”

4.胸有成竹CallingtheShot主要讲述如何计算编程时间，以及提出几个人的经验算法。讲述的各种算法可能都不太适合与现在的高级语言，但Portman的观点仍然适合现在，即编程人员实际的编程时间只有50%，其他的时间都花在了无关的琐碎事情上。

5.整体部分TheWholeandtheParts一读这一章，就让我感触颇深，特别是这句话”BELL实验室监控系统项目的V.A.Vyssotsky提出，'关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方'，细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的BUG数量”。虽然这句话的意思只是说明精确定义产品将减少BUG的数量，但我看到了系统分析的最重要的工作——产品定义。现在，许多开发人员嘴里口口声声说也做过需求调研、系统分析、系统设计，但大多数没有涉及到产品定义的深度，严格意义上不能叫做系统分析。这句话对我的以后想从事系统分析工作有很大的帮助。这一章余下的内容，也值得一看，虽然有些地方有些过时，但剔除BUG的设计以及部分测试/调试方法仍值得一看。

〔【转】人月神话读后感2〕随文赠言：【这世上的一切都借希望而完成，农夫不会剥下一粒玉米，如果他不曾希望它长成种粒；单身汉不会娶妻，如果他不曾希望有孩子；商人也不会去工作，如果他不曾希望因此而有收益。】

转人月神话读后感

[【转】人月神话读后感2] 堵哥哥要我写人月神话的读后感，再找一篇膜拜一下~~~ ————————————————————我是分割线———————————————————————— 这本300多页（中文新版）的神书，在经过了20多年的历史之后，仍然畅销不衰，究竟是什么让它有如此的魅力？过去的一个月，一点一滴的阅读之中算是初步的了解到了它的一部分吧，【转】人月神话读后感2。人月神话的核心观点：概念完整性和架构师 brooks认为，一个整洁、优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型，这个模型描述了应用，实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。概念的完整性是易用性中最重要的因素。而架构师，则是负责保证产品所有方面的概念完整性的，架构师设计的是能够让用户理解产品概念的模型，这包括所有的功能的详细说明以及调用和控制的方法。

它就像电影的导演一样。我的理解：这里的概念完整性其实应该说的是这个软件理念上的业务流程的前后连贯，也就是用户在使用产品的过程中，能够按照唯一的一个的最高抽象的思路来使用这整个系统。开发第二个系统的后果——盲目的功能和频率猜测所谓第二个系统，指的是产品的第二个实际发布。开发第一个发布的时候会因为各种原因去消减不必须的功能，所以会简化问题，而在第二个版本的时候则常常想其中添加各种各样的功能（也许源于用户的功能建议）但是，却导致了灾难性的后果。所以，在这种情况下，用户群越大，越不稳定，我们就更加应该明确的定义用户群，以获得概念的完整性。我们必须为整个设计团队定义一个共同的用户图像，记录下用户群的属性： 1.他们是谁 2.他们need什么 3.他们认为自己need什么 4.他们want什么而另一方面，对于任何产品，任何用户群属性都是一种概率上的分布的，也就是每个属性都有各种可能的值，所以我们能做的是，架构师去猜测（guess）或者假设（postulate）一系列完整的属性和频率值。

这里，清晰和错误都将比模糊不清好得多。不同的社会经验，不同的思想状态，对读后的心得也会不一样.比如： 1.外科手术队伍thesurgicalteam项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任，读后感《【转】人月神话读后感2》。 2.如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确地理解，并精确地整合到产品中。 3.贯彻执行passingtheword印象比较深刻的是”体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但他不应该支配具体的实现过程。” 4.胸有成竹callingtheshot主要讲述如何计算编程时间，以及提出几个人的经验算法。

讲述的各种算法可能都不太适合与现在的高级语言，但portman的观点仍然适合现在，即编程人员实际的编程时间只有50%，其他的时间都花在了无关的琐碎事情上。 5.整体部分thewholeandtheparts一读这一章，就让我感触颇深，特别是这句话”bell实验室监控系统项目的v.a.vyssotsky提出，'关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方'，细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的bug数量”。虽然这句话的意思只是说明精确定义产品将减少bug的数量，但我看到了系统分析的最重要的工作——产品定义。现在，许多开发人员嘴里口口声声说也做过需求调研、系统分析、系统设计，但大多数没有涉及到产品定义的深度，严格意义上不能叫做系统分析。

这句话对我的以后想从事系统分析工作有很大的帮助。这一章余下的内容，也值得一看，虽然有些地方有些过时，但剔除bug的设计以及部分测试/调试方法仍值得一看。〔【转】人月神话读后感2〕随文赠言：【这世上的一切都借希望而完成，农夫不会剥下一粒玉米，如果他不曾希望它长成种粒；单身汉不会娶妻，如果他不曾希望有孩子；商人也不会去工作，如果他不曾希望因此而有收益。】