阅读是获取知识的重要来源，这次寒假我购买了《构建之法》，已经阅读了前三章的内容，在此写下自己的阅读笔记。
大二开始我也是正式分入了软件工程专业，跟大一时的计算机类不同，编程实现又快又简练的算法看上去确实很cool，但放在一个工程里就要考虑是否适用了。回顾大二上学期的测试情况，在完成大部分功能时，我并没有过多地使用大一时学来的“技巧”，老师也一再强调软件上最重要的是稳定性。书中给了更加系统的定义，结合上本书《从小工到专家》来看，二者都重点强调了“需求分析”，这里软件工程更像是一个服务行业，我们要按照顾客的需求去办事，因此，软件工程给我的印象是：用户需求的框架+朴实代码的填充。
那么在写软件的时候一定要用傻瓜式的代码了么？显然不是，高级算法能极大地减少时间复杂度与空间复杂度，只是放在大型工程里，需要注意数据与其他模块的关联性。现在我们先讨论什么是“好软件”。一般情况下我们认为没有BUG的软件就是一个好软件，但显然一个没有任何bug的软件极难，甚至是不可能写出来，那么退而求其次，我们可以从多个方面去评估软件，书中列出了4个方面：用户满意度，可靠性，软件流程质量，可维护性。由于我们是按用户的需求去设计，因此有很多地方需要开发人员和用户去沟通协商，因此，我认为：好软件=技术+沟通。
目前我们在学校完成的测试之类的，都是个人单独完成。确实，软件工程项目通常是一个开发团队去做，但不可因此忽略个人技术，这里就提到了一个重要的流程：单元测试。我个人对自己写的代码从来都是写完一个功能，随便写几个样例扔上去简单测试一下，至少书中那样详细的单元测试流程，我没有做到。但不可否认，这样的测试十分重要。闷头写完所有代码，测试最终结果时报错，当你回顾所有代码时你会感到非常头疼，倒不如一步一脚印慢慢走。这只是个人项目，如果放在开发团队上，每个人负责一个模块，自己的模块出了问题，也是很没面子的事情。此外，在开发项目上，还有一个回归测试，这个在我的理解看来，大概就是更新软件后出了bug，倒退到原来没出bug的情况。最后在流程上的重点，注释是关键，毫不夸张地说，现在让我去看之前写过的，没有注释的项目，若非时间短还有些印象，我要看懂也有些麻烦。注意一点，注释是写给别人看的，尽量写得简练一些。
怎样成为一个合格软件工程师，最基础的技术功底一定要过硬，在通过阅读书籍和老师传授的经验之后，软件工程师要有一定的思想基础，我们是工程师，要讲究分析设计，而不是单纯的“码农”。先谈谈技术功底，衡量技术总归需要项目来看，一个软件开发的工作量和质量的衡量标准有4点：项目/任务大小；花费时间；质量如何；是否按时交付。分摊在个人身上的话，最直观的也就是完成时间了。以前我一直觉得，只要在最短时间内完成，就是最好的，但显然我考虑得少了，首先你要保证缺陷不要太多，“re-work”的时间是记入完成时间内的，同时“re-work”过多也从侧面上反应了开发者的技术不严谨，还有就是时间的测量方式，之前提到过软件上讲究稳定性，一个程序员是否有稳定且扎实的技术功底，要根据他完成工程时的时间方差来看。是的，除了直观的时间结果之外，还要通过方差来看看这个程序员是否“稳重”。
在第三章的最后，书里提了一些很现实的东西，考级啊职业啊什么的。让我印象较深的还是“技术的反面”，想成为一个专业的程序员，我们不能一直犯低级错误，目前实现一些工程，作为大学生的我们尚且需要上网查资料，问题就在于是否产生了依赖性，要知道，我们最终的目的不是应付了事，而是把技术变成自己的。