读《构建之法》1、2、16章问题及理解

读了第一章之后，在作者对于航空业和软件业的类比里，有一段内容引起了我的疑问:“如果一架民用飞机上有一个功能，用户使用它的几率是万分之一，你还要做这个功能么?你会选择1.根本不考虑2.如果没时间实现功能就算了3.做了但是不用告诉用户4.做了，而且不厌其烦地告诉用户如何使用”，我的问题是如何才算是一个合格的软件呢？而一名合格的软件工作者是在书中所说的四个层次中的哪一个层次上谈论软件呢?而我去查找了一下如何才算是一个好软件，我从百度知道上得到的回答是“要衡量一款软件是不是好软件，可以从以下几个方面来判断：首先是使用方法要简单，一款性能优越的软件，在使用方法上是很简单的，初次使用也能够在短期内就可以上手使用。其次就是功能全面，这也是软件的灵魂所在。一款好的软件要满足使用者的各方面的个性需求。还有就是对软件后期维护，软件升级换代比较及时，省心。”而以我现在的技术水平是极难做出严格意义上的好软件的，因为这不仅仅是自身的水平问题，还有对于用户需求的方面考虑，真正的合格的软件有苛刻的要求，而不仅仅是你把它做出来就ok了，万事大吉了，而这方面的经验我觉得我还是太缺乏了。而我也认为，至少要到达书中所说的第三个层次:不断创新的层次才有可能做出真正的好软件，因为有不断创新才有软件的不断完善。
而第二章内容“对于单元测试的功能、标准以及几个失败例子的举例”，这里面对于单元测试的几个介绍，让我不禁想问单元测试是很重要吗？必须自己来吗？之后去查找了一下，我引用的是这段“单元测试，对提高软件质量是有很大帮助的。通过一系列预先设计的规则，就可以覆盖大量的测试点。尤其是对重构一类的任务，确保修改前后系统行为不变很重要，而修改后的回归测试工作量又极其繁重，此时单元测试就能体现出无以伦比的效率。”由此我体会到了单元测试对于软件的重要性，而从我自己的实践经验来看，还没有涉及到这一方面，但也了解到单元测试绝对是比较重要的一环，绝不能随便敷衍，而尽量要写的细一些，不要有错漏。而我觉得单元测试自己来要更好，为什么呢？因为自己所负责的方面自己上手会比较熟悉，更加容易写出更不易出错的单元测试，而交给其它人，不仅自己不放心，还有更大可能出错。
第十六章讲的主要是IT行业的创新，一开始讲的创新的迷思对我触动很大，作者的观点是，创新并不仅仅是灵光一闪或者突发奇想就能够造就的，他举了很多伟大的人灵光闪现有了创新的例子，并指出那是因为他们在之前就打下了深厚的基础，灵光一闪之后才能创新，而许多人有了灵光一闪，却最后只能是空的构想。没有自身扎实的功力 前人的不懈努力，灵光一闪永远成为不了创新。而我的困惑是像我这样的技术水平不够的人，哪怕有了灵光，也只能是空的构想吗？没有办法实现创新吗？之后去查找了一下，发现了自己可以做到的，那就是尽量向自己的想法靠拢，可以先做一些简单的，类似的东西，之后慢慢增长经验，等自己有了足够自信和能力去完成的时候再去完成。创新不是一蹴而就的，一步步积累也是创新所必需得，软件的创新也是这样。