神话5.6

过去是怎么做的： 我总是写完全部的代码再进行测试。 为什么这样不好： 如果bug很多，就会导致最后的提交时刻，要一次次的重复查找bug并解决，甚至推翻重写代码，这是致命且让人感到十分枯燥的。 解决办法： 最好按照书中的编程习惯，制定一个恰当的解决测试办法和时间进度安排，避免出现最后时刻才测试的状况， ......

过去是怎么做的： 我认为编程的乐趣小于苦恼，似乎痛苦的事情更多。而且编程中找bug是更令人烦恼的事情。 为什么这样不好： 会使我丧失掉编程的兴趣，让我失去动力。 解决办法： 更仔细写代码，不要写太多bug，并且一开始就注重代码的规范性，避免日后看不懂，从而丧失编程动力与乐趣。 具体读后感： 焦油坑： ......

焦油坑： 过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题 ......

对于软件本身的复杂性，作者得出的结论是，当前没有任何方法能使软件的生产率提高一个数量级。但作者并没有消极的接受这个结论。而是深入分析了软件复杂性到底是如何导致软件项目最终的失败。并且提出了很多很有建设性的方法来予以应对。 在巴比伦塔一章中，作者阐述了不能有效的交流是导致项目失败的主要原因。每个人都是 ......

终于有幸拜读了《人月神话》这部业内经典著作。整体来说，本书的主线——人月神话、没有银弹在现今的软件工程管理领域依然属于有效的基础理论。不过有些东西确实过时了，比方说文档的管理，现在已经有了svn或者在线文档。提到调试的复杂性，现在的集成环境把调试变得非常容易。读完之后才感觉不是给编程的人看的，更应该 ......

《人月神话》--这个月，我在读《人月神话》这本书。 何为人月神话？不是人和月亮，而是指一种计量单位-人月，即为人*月，用于计算软件工程中的工作量的单位。 软件工程，固然它不仅仅是一个软件开发，而是一项工程。它又不仅仅是一项传统生产关系下的工程，它是一项复杂性工程。这里的“复杂性”不是通常生活中说的复 ......

人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。现在终于找到读他的理由了，可以感受一下大师的杰作。在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢?主要是因为我觉得一本能够流传30年还被人们津津乐道的书， ......

作为开章第一篇，就先来说说为什么“人月”是“神话”。 小学的时候我们都做过这样的应用题：“工厂需要加工一批零件，安排5名工人的话需要10小时完成，那么安排25名工人加工，多少小时可以完成”之类的。对于这类题目，小学一二年级的学生都可以轻松得到答案。也正是如此，如今的工作中，仍有不少同仁秉持这样的小学 ......