人月神话

1. 《代码大全》 史蒂夫·迈克康奈尔 推荐数：1684 code complete 代码大全 “优秀的编程实践的百科全书，《代码大全》注重个人技术，其中所有东西加起来，就是我们本能所说的“编写整洁的代码”。这本书有50页在谈论代码布局。” —— Joel Spolsky 对于新手来说，这本书中的观念有点高阶了。到你准备阅读此书时，你应该已经知道并实践过书中99%的观念。– esac 2. 《程序员修炼之道》 推荐数：1504 Pragmatic Programmer 程序员修炼之道 对于那些已经学习过编程机制的程序员来说，这是一本卓越的书。或许他们还是在校生，但对要自己做什么，还感觉不是很安全。就像草图和架构之间的差别。虽然你在学校课堂上学到的是画图，你也可以画的很漂亮，但如果你觉得你不太知道从哪儿下手，如果某人要你独自画一个P2P的音乐交换网络图，那这本书就适合你了。—— Joel 3. 《计算机程序的构造和解释》 推荐数：916 Structure and Interpretation of Computer Programs 计算机程序的构造和解释 就个人而言，这本书目前为止对我影响醉倒的一本编程书。 《代码大全》、《重构》和《设计模式》这些经典书会教给你高效的工作习惯和交易细节。其他像《人件集》、《计算机编程心理学》和《人月神话》这些书会深入软件开发的心理层面

人月神话 02 今天这篇阅读笔记主要讨论一下《人月神话》中巴比伦塔失败的原因，以及如何组织一个队伍才能保证一个项目或系统能够正常的运行。 古巴比伦塔是《创世纪》中记载的一个建筑。他是人类继诺亚方舟之后的第二大工程壮举，但是它失败了。那么他为什么会失败呢？在这项工程中，它具有所有资源：清晰的目标、人力、材料、足够的时间、足够的技术。所有的这些足以支持他完成这一人类工程上的壮举，但是他失败了，因为在这项工程中没有很好的交流！这样导致了每个人都在干自己的事情，他们无法合作，这样他们当然不可能完成这样一项巨大的工程。 根据上述工程的分析和总结，我们可以推断出在软件工程领域存在同样的问题：当人们面临一个巨大的系统工程时，很可能由于因为没有足够的的交流导致这项工程的失败。那么我们应该如何避免这种失败情况的发生呢？这就需要我们首先得有充分的交流，这也就导致我们必须有一个好的组织管理模式。 首先我们先来谈一下关于交流的问题。交流的方式有很多种：会议、工作手册、非正式途径（电话交流沟通）。其中的工作手册是一个非常好的方式。项目工作手册是对项目必须产出的一系列文档进行组织的一种结构。项目工作手册中的备忘录对产品提出建议或者进行解释。未来产品的质量手册也是出自于现如今的项目工作手册。同时他还能够控制信息发布，确保信息能够达到所有需要他的人的手中。 项目工作手册的目的是加强团队之间的交流沟通

今天我要分享的是在画蛇添足那里得到的体会： 　　 第二个系统是设计师们所设计的最危险的系统。而当他着手第三个或第四个系统时，先前的经验会相互验证，得到此类系统通用特性的判断，而且系统之间的差异会帮助他识别出经验中不够通用的部分。 　　 我一开始的想法是不应该是设计的第一个系统最为危险呀！！因为初次设计肯定会有更多的不足与缺陷，事实证明却并非如此，一般第一次的设计都比较谨慎，不会去过多的要求一些特殊功能的实现，而是要求简单；而当你有能力去开发第二个系统时，这时的你感觉自己已经很厉害了，可以将自己在第一个系统上为实现的功能进行完善，恰恰相反由于过分的设计第二个系统，向该系统中添加过多的功能和未实现的想法，会使整个系统变的糟糕起来。这就是第二系统效应。 巴比伦塔的失败 　　 让我比较清晰的认识到，在一切外界条件充足的情况下，如果团队之间没有良好的沟通与交流，没有良好的组织，那么这个项目就会向巴比伦塔一样，因为他们之间无法交流，从而无法合作，当合作不能再进行下去，工作就会陷入停顿，之后就会出现一系列的矛盾。希望这次我的小队不要出现这样子的状况，为避免这样的状况出现，我会采取一些方式： 进行电话会议，每个人都谈谈自己的想法与思路，或者遇到的困难，然后分配今天的任务，不清晰或者有疑问的可以随时进行交流，然后再投入到工作中。 来源： https://www.cnblogs.com

在所有恐怖民间传说的妖怪中，最可怕的是人狼，因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物。为了对付人狼，我们在寻找可以消灭它们的银弹。 软件项目就像一头人狼，常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。因此，我们听到了近乎绝望的寻求银弹的呼唤，寻求一种可以使软件成本像计算机硬件成本一样迅速降低的尚方宝剑。 但是IBM大型机之父佛瑞德·布鲁克斯所发表一篇关于软件工程的经典论文，原先是在1986年都柏林IFIP研讨会的一篇受邀论文，该论述中强调由于软件的复杂性本质，而且真正的银弹并不存在；所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。 接下来，我会花多个章节，详细描述软件开发里的各种人狼现象，以及解决之道。 来源： CSDN 作者： 猿开开 链接： https://blog.csdn.net/zhangxr88/article/details/104617672

今天看了这本书的一部分，作者以“人月”为单位，刻画了开发过程，印象深刻的是作者在结构师的角度进行关于项目进度的刻画，突出了按时完成任务的重要性，否则只能一步慢步步慢，如果为了项目的如期交付，可能需要更多的人参与进来，这是建立在浪费一部分时间上的，由此得出了“向进度落后的项目中增加人手，只会使进度更加落后”。 还有笔者发现效率高，能力强的工作者对开发成本的控制使非常有利的，所以 实力才是硬道理。 产品设计人员尽量少，得到概念的完整性，整个系统将会开发的更快，易用性实际上需要设计的一致性和概念上的完整性。 来源： https://www.cnblogs.com/ywqtro/p/12346774.html

人月神话 焦油坑 编程系统产品（Programming Systems Product）开发的工作量是供个人使用的、独立开发的构件程序的九倍。我估计软件构件产品化引起了3倍工作量，将软件构件整合成完整系统所需要的设计、集成和测试又强加了3倍的工作量，这些高成本的构件在根本上是相互独立的。 编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”，提供了五种乐趣： 创建事物的快乐 开发对其他人有用的东西的乐趣 将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力 面对不重复的任务，不间断学习的乐趣 工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动，其存在、移动和运转方式完全不同于实际物体 这个行业具有一些内在固有的苦恼： 将做事方式调整到追求完美，是学习编程的最困难部分 由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）；权威不等同于责任 实际情况看起来要比这一点好一些：真正的权威来自于每次任务的完成 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外 人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢 产品在即将完成时总面临着陈旧过时的威胁 人月神话 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。 良好的烹饪需要时间

人月神话摈弃神话色彩后，其本质上便是人与时间的关系，而引申到编程上是对于时间这一概念的有效利用度，因为编程注重结果，所以完成工程项目的必要时间是必须的，而在一个问题上花费合理的时间解决，预示着这个项目的效率与寿命， 过长会使其效益下滑，过短会让它稳定性受怀疑，Brooks教会了我们如何从枯燥烦闷的长时编程中寻找乐趣，想着我们最终完成的项目成果，一切也便有了坚持的信念。 然而这个过程并不全都是喜悦。我们只有事先了解一些编程固有的烦恼，这样，当它 们真的出现时，才能更加坦然地面对。 首先，必须追求完美。因为计算机也是以这样的方式来变戏法：如果咒语中的一个字 符、一个停顿，没有与正确的形式一致，魔术就不会出现。 （现实中，很少的人类活动要求 完美，所以人类对它本来就不习惯。 ）实际上，我认为学习编程的最困难部分，是将做事的 方式往追求完美的方向调整。 其次，是由他人来设定目标，供给资源，提供信息。编程人员很少能控制工作环境和 工作目标。用管理的术语来说，个人的权威和他所承担的责任是不相配的。不过，似乎在所 有的领域中，对要完成的工作，很少能提供与责任相一致的正式权威。而现实情况中，实际 （相对于正式）的权威来自于每次任务的完成。 对于系统编程人员而言，对其他人的依赖是一件非常痛苦的事情。他依靠其他人的程 序，而往往这些程序设计得并不合理，实现拙劣，发布不完整（没有源代码或测试用例） ，

寒假放假前老师推荐了几本书，还说有兴趣的可以看看，不强制（在博客园看不到读后感他就要酌情扣分了）。呸，大猪蹄子。 　　《人月神话》中有说到“焦油坑”，大概就是说编程就像身陷焦油坑，要想存活下来就必须得有技巧，看清楚问题本质。 　　编程是很有趣的，前提是你得对它感兴趣（完了，我没戏了）。编程的乐趣在于创造事物的快乐以及解决问题的快乐，会从中获取成就感。编程能用简单（对于某些大佬来说。。。）的语言解决人类懒得一步一步解决或者运算量太大无法解决的问题。老师说过一句话我记得很清楚，“懒人创造技术”。 　　然而，编程也是有苦恼的，编程不光是为了完成自己的目标，当我们进入职场之后，大多都是用户提要求，我们实现要求。可能我们编写的程序不能使用户满意，还要多次的与用户反复交流。最最最麻（lai）烦（qi）的事就是找bug。假如写程序需要10分钟，那找bug可能就需要1小时。很可能在测试bug的时候没有发现bug，但是用户在使用的时候出了问题，这才最是令人苦恼的方面 来源： https://www.cnblogs.com/wsq666/p/12274168.html

形式化定义：实际上，对这一点有较深的理解，我们的自然语言往往存在着一些歧义，特别又是以灵活见长的中文，在不同的语言环境中可以有这不一样的含义。这里原没有一些形式化定义的严谨，比如公式之类。不过往往很多需求不太可能完全使用公式或者严谨的形式化定义。个人觉得一种折中的方式，是对自然语言在团队内做内部的统一，也就是术语库。保证团队内部对关键的术语和概念无歧义。 会议：会议是必要的。一般来说，技术人员往往对会议比较排斥，认为是浪费时间。实际上是项目经理或者管理层必须严格的控制会议数量，会议范围和时长。做到高效的会议。 来源： https://www.cnblogs.com/jiaoaoshirenjinbu/p/12271952.html

系统开发的时间安排 1／3 计划 1／6 编码 1／4 构件测试和早期系统测试 1／4 系统测试，所有构件已完成 需要特别指出的是，不为系统测试安排足够的时间简直就是一场灾难。 这句话我深有体会，在考试的之前，总是把大概的模版写出来了，以为就完成了工作，然而到真正要用的时候发现，漏洞百出，在很多细节上的地方花费太对时间，从而严重拖慢了进度。 故我认为应该在考试之前将自己的模版再三调试，这样才能尽可能的避免细节上的失误。 来源： https://www.cnblogs.com/jiaoaoshirenjinbu/p/12258812.html