读构建之法有感

 

第一章：

   第七页的那个飞机的例子我个人觉得有些太过于理想化了。如果那百万分之一是为了安全，那当然一定会考虑的。但如果不是安全性而是别的呢？客机不会为了百万分之一甚至千万分之一的可能性在飞机上配跑步机。软件工程也应该是这样的。我认为软件都应该是小而精的，该是视频播放软件就只做视频，不会让你下一些莫名其妙的游戏。而不应该是那种繁而杂的东西。

   第九页的“软件开发中有什么特别的难题”这个板块中，第五条“非连续性”这个我没有理解。“有时输入上很小的变化，会引起输出上极大的变化”这个不应该是数学问题吗？我查了一些资料，大致上说非连续性的意思就是一个软件与另一个软件之间是不连续的。这跟我平日的学习中是一样的。每天敲出来的代码都不一样，都不连续。但我还是不懂，这个非连续性为什么是“软件开发中特别的难题”呢？

   第十页的“没有银弹”这个论断很新颖(对我来说)。我去阅读了原文：

        人狼在所有恐怖民间传说的妖怪中，最可怕的是人狼，因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物。为了对付人狼，我们在寻找可以消灭它们的银弹。软件项目具有一些人狼的特性，常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。因此，我们听到了近乎绝望的寻求银弹的呼唤，寻求一种可以使软件成本像计算机硬件成本一样迅速降低的尚方宝剑。（摘录）读完后对一些专业术语没有完全理解，带还是对软件的特殊性有了更深层次的理解。

 

 

第二章：

 

   在这一章中我了解到了单元测试的重要性。单元测试我之前从来没有听说过。单元测试甚至比程序设计本身更加繁琐更加重要。单元测试在一定程度上直接决定了一个软件的寿命与后期修复难度。在我平日的学习生活中，只想着怎样设计出一个软件以为我设计出来一个软件，我就得到了“银弹”，从来没有想过去测试。常常是一个main函数就做完了所有的工作，从没有考虑过什么srp，ocp。。

   单元测试，回归测试，效能分析，，，，让我知道了一个软件不只是算法，还有大量的测试。。。。“效能测试，分析，改进，再效能测试”的流程，让我对编程有了更深刻的认识。优化固然重要，但是“如果我们不经分析就盲目优化，也许会事倍功半”。做软件不能急功近利。要一步一个脚印。

   第25页“单元测试必须由程序的作者来写”，对于这个观点我有一些疑问。我认为这个定论有点太局限了。单元测试应该由专门做单元测试的人做，术业有专攻嘛。但当我查阅了一些资料：http://blog.csdn.net/bingyelee/article/details/8962292(单元测试应该由谁编写)作者从一个帮别人写单元测试的角度阐述了这个问题。行文有点偏激，但也表达了这种做法的不足之处。不仅浪费时间，而且容易出错。自己写的软件，就要自己测试。如果不行，那这个软件就不完整。

 

 

第十六章：

 

   这一章主要讲述了创新。读完这一章，我对创新有了不一样的看法。创新不仅仅是与别人不一样，还要让别人接受。创新并不一定都是最早的，最早的创新并不一定都是好的，而好的创新也不一定是成功的。

   但是对于迷思之五“要成为领域的专家，才能创新”我有一点不能理解。虽然书中列举说70%的创新者的最成功的创新死在他们拿手的领域之外发现的。但是如果这样的话，那不是和迷思之一，迷思之二矛盾了吗？没有前辈的积累，何来一时的突破？不在相关领域有所建树，你的创新如何受人待见？我还记得那位被华为辞退的北大高材生，刚入华为，就提出了万字关于管理方面的创新理论，结果直接被辞退。虽然此人有狂妄自大之嫌，但在一个领域毫无成就就要创新创新，这样成功的可能也太小了。初中的数学老师经常跟我们说，在你没有学会一道题的常规解法前，不要去创新，投机取巧。你那不叫创新，叫空想。所以我觉得，至少要在一个领域有所建树，才能创新。