软工读书笔记 week 5 ——《构建之法》

本周主要对《构建之法》中的一部分进行阅读。

一、软件与软件工程究竟是什么？

本书的概论部分就指出“软件 = 程序 + 软件工程”。而我们这门课的名字就叫“现代软件工程”。其实在上课之前，我对这门课存在一定的误解，我更多地把这门课归入“程序”部分。在我原来的理解中，像电设二一样，自己学新知识（当然很多在电设一已经学过），然好以团队的形式独立去完成一个项目，只不过电设属于硬件（也包含一部分软件），而软工则纯粹是软件了。

而上课之后却和我预想的不一样。首先每周读书笔记这个就让我非常不解，有些推荐书籍里面在我看来更像是鸡汤。后来，我才慢慢发现软件工程绝不只局限于就某一功能写代码去写代码实现，它的范围很广，正如书中所说，它包括软件需求分析、软件设计、软件构建、软件测试和软件维护，而我原来的理解只能算作是程序。比如书中开篇的那个例子，一段能完成出加减法题目的代码只能称为程序，而如果再根据用户的需求，给这个程序再加更多功能，甚至发布到网站上，并希望有人来维护，则这时程序已经升级成为了软件，因为要考虑的不仅仅是实现功能那么简单了。

再就是软件工程与计算机科学之间的关系，这一点我之前一直也搞不清楚。根据托尼·霍尔的比较，我们可以看到，计算机科学更强调理论的统一、确定性、正确性、原创性，它是一种长期的真理，而软件工程更强调更好的实践方法、能解决问题、处理风险以及可靠性，它是一种短期的结果。不过由于现在很多学校计算机学院也偏向工程，这有时模糊了二者的界限，但这并不代表二者是等同的。

 二、测试与性能分析

第二章强调了单元测试的重要性，不过上次个人作业由于时间等原因没有用起来，后面有机会要学会使用。而后面提到的性能分析上次个人也是第一次用起来了，以前都只是对自己程序的运行时间有一个大概印象，而具体哪个函数耗时大都没有详细说明。而通过性能分析能更有针对地去优化。然后通过第一次大作业对这方面也有所了解，这里就不赘述了。

三、结对编程

由于接下来要进行结对编程作业，我也重点阅读了一下“两人编程”这一部分。

首先，既然是合作项目，就要有一些约定，包括代码规范之类的，具体的也不赘述。还有几点特别的，一是提到了函数有个重要原则：“只做一件事，并且要做好”，这也是一直强调的模块化，模块化的好处不仅能让程序看起来更清晰，而且可以在代码移植时更简单；二就是代码复审，这个我之前编程的时候都没怎么考虑这个过程，我之前一般的流程就大概是“编码——测试——发现有错——复查”，这样的话虽然也行，不过一些小错误或者说可以改进的地方好好看一下其实很容易发现。复审可以是自我复审、同伴复审、团队复审，在结对项目中，同伴复审就非常重要。

而结对编程可以让代码处于不间断的“复审”过程中，一个驾驶员，一个领航员，互相督促，共同决策。现在还没开始结对编程，以前也没有尝试过，我相信还是能学到很多东西的。

        四、关于创新

因为本周作业里有创新的部分，我也选读了一下第十六章关于创新的内容。对于创新，我们往往认为只要想法是好的，那我们就能赢。但其实从书中举键盘布局和美国度量制可以看出，事实有时并不如此。书中还提到了很有意思的一个“黄金点”游戏，每个人选个数，所有数求平均，再乘0.618，最后离这个结果最近的同学就是赢家。作者提到了“赢者通吃”、“螳臂当车”、“只先一步”这三点，而就我自己而言，我觉得这就是一个个人决策的问题，每个人都想赢，都会思考选哪个数会让自己最可能赢，但如果大家都选这个数的话，这个数又不可能是最后答案，所以说这就考虑一个人的决断力。

魔方的创新这篇文章，则通过一个看似简单的小故事，却映射了软件开发行业的一种常态。“果冻”同学就是一个产品最先的创造者，为了保护自己的创新，他选择了对所谓的“口诀”进行保护，这个时候这个产品还只是一枝独秀。而很快，竞争——“小飞”——马上出现了，类似的技术出现，当时的产品已经成了大路货，大家对其的热情也减少了。竞争者们想要胜利，要么选择一个产品从未到达过的地方进行宣传，要么将产品与其他捆绑，而这两者终究不是长久之计，还有就是再次创新，开发属于自己更独特的地方。在百舸争流的时代，总有一两个出众者再次出现，“大牛”的新花样一时吸引了不少人，但若只是因为一点点小花样，一个产品注定不会就这么长久地火下去，而又在此时，“二柱”却能准确地把握住用户真正的需求，虽然技术上不及前面的各位，却更能抓住用户。

总结一下，一个产品要想胜利，不在于你是不是开创者，也不在于你能想出什么新花样，还是在于你能不能真正把握住用户的需求。