阅读《构建之法》的几点思考
阅读《构建之法》的几点思考
一、前言
最近这两天，我认真阅读了邹欣老师编著的《构建之法》的第1章，第2章与第16章，在获得了许多知识的同时，对于文中的一些知识与观点，我也依然还存在着不少的疑惑。以下就是我在阅读过程中的疑惑与不解，对此，我也做出了一些思考。
二、第1章
1.文中说到这样一个例子：
我上班后，发现以前同事写的程序真是垃圾，根本看不懂，无法维护。我要推翻重写！后来一个老员工笑嘻嘻的告诉我，我们现在看到的程序，就是去年的新员工愤怒地推翻重写之后的结果，大家反应还没有以前的版本好用呢。
我的疑惑：
随着科技的飞速发展，技术水平的不断提高，编写程序的语言也更加先进，更加精简。因此，编写出来的程序应当是更加的言简意赅，为什么却说是还没有以前的版本好用呢?对此，我是深感疑惑。
我的思考：
通过上网查阅相关资料，我了解到，即便是一个很简单的程序，随着开发的深入，时间的延伸，都会变得慢慢的臃肿与庞大。程序在逐渐衍生的时候，前期的设计会变得越来越模糊，系统会逐渐脆弱，对变化也越来越敏感。到了后期，一般只能在合适的地方增加程序，而不能修改。因为即使是一个小小的修改，都会导致一系列新的问题，并可能产生一些莫名其妙的bug。于是程序会逐渐变得臃肿，重复代码逐渐增加，莫名其妙的问题逐渐增多。写这样的程序完全是种折磨。做好前期的工作会使这种感觉得到改善：
（1）完善的需求：应该包括目前所有的需求，以及潜在的需求。
（2）良好的设计：设计容易走两个极端：一个是完全没有设计。你要什么功能，一个一个给你实现，就得了；第二个是完全彻底的解耦。即使很紧密的关系，也会被完全的分离。好的设计应该能够预测可能发现变化的需求点。并预留可能修改的接口。
虽然，经过这个介绍，我知道了是因为程序在深入开发的过程中变得越来越庞大，所以才导致了程序越改越乱的问题，但是，文中的这个例子说的，好像并没有说是后来改的程序增加了什么新的内容，所以，对于这版本越改越坏的问题我还是存有疑虑。
2.文章内容：
IT专业的大学毕业生找工作时声称：我精通Java，会用c++写“Hello World”程序，我懂软件工程，我画了很多图，写了很多文档，最后得了很高的分数......这些同学是真的懂软件工程，是一个合格的软件工程师么？
我的疑惑：一个合格的软件工程师应当具备哪些素质？
我的思考：
首先，我肯定是不认为文中说到的这些大学生是真正懂软件工程的。我认为，一个合格的软件工程师是应该具备好多基本素质的，而文章中说到的这些，都还是太片面了。我认为，一个合格的软件工程师，起码应该既具备以下素质：
（1）有良好的数学基础，保证基本的逻辑没有问题；
（2）有程序语言有一定的敏感性，并不一定针对某种特定的语言，一旦有一种比较熟悉的语言，一通百通，其它的语言应该能快速阅读，并在短时间内基本掌握其中的要素，最好能有系统的学习过一门语言，这里的学习和老师上课的那种学习没有太大的关系(上大学如果只是要应付上课和考试不补考，应该算是比较轻松的事)，而是要看一些和这门语言相关的一些中大部头的专著，如Java的Java编程思想，C++的C++premier,Javascript的javascipt权威指南等等；
（3）对程序的整个框架有一定的了解，能独立把整套程序的流程建立起来；
（4）有比较好的面向对象的思想，其中具体表现在能不间断的抽象出一些类来，以备在不同的项目间能够起到代码复用的作用，这样做项目才会越来越轻松；
（5）对系统设计要有一定的基础，并且对系统设计时对系统的可扩展要有一定的考虑。
三、第2章
1.文章说到：
为了使模块的质量能得到稳定的、量化的保证，单元测试就是一个很有效的解决方案。
我的疑惑：
什么是单元测试？单元测试能够解决哪些问题？有没有什么问题是单元测试解决不了的？
我的思考：
通过查阅资料，我了解到：单元测试（unittesting），是在计算机编程中，针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。通常来说，程序员每修改一次程序就会进行最少一次单元测试，在编写程序的过程中前后很可能要进行多次单元测试，以证实程序达到软件规格书要求的工作目标，没有程序错误。单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list中去，然后确认该值出现在list的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。确实，它可以帮助我们解决好多问题，尽可能多的减少程序中的错误，但是，对于它不能解决哪些问题，我还是不懂。
2.文中小飞和阿超的对话说到：
小飞：现在我知道为什么有些软件写了好几年都没有发布了，敢情他们都忙着写单元测试了。
阿超：也许因为他们没有在一开始就写单元测试，所以后来有很多问题要解决。
我的疑惑：
写软件与写单元测试有什么先后顺序之分吗？
我的思考：
软件的开发是从小的模块开始，不可能没有模块就开始集成，后来才打包成一个软件，形成一个系统。单元测试是测试各个小的模块，通过对他们的测试，才能找出基本的bug，然后为各个模块搭建接口，也就是把模块组装起来，之后进行集成测试，看各个模块的接口是否正常稳定，打包成软件后，再由开发和测试一起进行系统测试。所以说，是先对一个个的小模块进行了单元测试之后，才有了软件；可是，那一个个的小模块，其实也属于软件的一部分，是有了这些小模块之后，才能进行单元测试，所以，这样看来，似乎是矛盾的。或许，写软件与写单元测试，是同时进行的吧！
3.文中说到：
单元测试必须由最熟悉代码的人（程序的作者）来写。
我的疑惑：
单元测试由专人来写的话，是否会由于作者的定式思维而考虑不周，使得不能达到测试的作用？
我的思考：
作为程序的作者，确实是最熟悉，最了解代码的人。可是，就是因为作者自己最了解自己的代码，知道自己代码的目的，特点和优缺点，那么，在做测试的时候，难免就会朝着自己预期的方向去做测试，难免会有考虑不周的地方。即便是由于作者很忙，不能及时的去做单元测试，可以由他人代劳来写单元测试，但是，程序的作者依旧还是这个单元测试的负责人，对于测试，他也依旧还是会以自己的思维作为指导。对此，单元测试由程序的作者来写，我还是很不理解这是为什么。我始终觉得，单元测试不应该由作者来做，而应该由同领域的资深专家来进行。
四、第16章
1.文中有这两条迷思：
迷思之一：灵光一闪现，伟大的创新就紧随其后。
迷思之五：要成为领域的专家，才能创新。
我的疑惑：
既然说，像阿基米德，牛顿这样的伟人，他们是在顿悟之前就已经在相关学科打下了深厚的基础，同时他们也对这些问题进行了长时间的思考，所以，那些神奇的时刻才会光顾他们，让他们有了创新。可是，为什么又说，并不是要成为领域的专家才能创新，往往那些创新者最成功的创新，却是在他们的拿手领域之外发现的。我觉得，这两种说法是否有什么矛盾的地方？我很是不懂。
我的思考：
确实，创新并不是那么轻易就能得来的。“灵光一闪现，伟大的创新就紧随其后”，这未免也太简单了，世界上哪会有这么轻松的事。那些创新之所以是创新，那些伟人之所以是伟人，就是因为他们已经在私下里做了无数的研究，他们已经积累了深厚的基础，恰巧，他们遇上了一个对的时机，于是，这伟大的创新便应运而生了。所以，不可否认，他们确实是这个领域的顶尖人物，称他们为专家也无可厚非。但是，“那些创新者们成功的创新，却更多的是来自于他们的拿手领域之外”，对此，我并不认同这一观点，既然是在他们的拿手领域之外，那么，他们对此花费的研究时间，势必会比自己的专业领域少了好多，那么他们这伟大的创新，又是从何而来呢？
五、结语
以上内容就是我在阅读了《构建之法》一书中第1章，第2章，以及第16章之后的疑惑与思考，或许，上文中的一些观点，并不一定正确，不过，这也仅仅只是我一人的想法，如有不妥之处，还望老师与读者指正，谢谢！
