软件工程——阅读《构建之法》1-5章后的感想

这个作业的要求来自于：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178

第一章概论

在阅读完这一章以后，我明白了这一章主要讲述的内容为软件工程这门学科的实质内涵、软件开发所不可缺少的各种阶段、软件工程与计算机科学领域的关系。

我读至1.1.5节时看见了这样一句话“IT专业的大学毕业生找工作时声称：我精通java，会用C++写“Hello World”程序，我懂软件工程，我画了很多图，写了很多文档，最后得了很高的分数”，在看见这句话后，我仿佛被人窥探了内心一般的无比同意这句话，但是后面接着的句子“这些同学是真的懂软件工程，是一个合格的软件工程师吗？”让我开始对自己的想法是否正确产生了困惑。在我的观点里，对于合格优秀的软件工程师的定义便是如同上述句子描述一般，但看来是我眼界太窄，所以查询了资料，究竟怎么样才能被称为合格的软件工程师？查询了资料过后，CSDN博主hfutsqliang在文章《如何成为稍微杰出的程序员和软件工程师》中简述了五点观点：学会看代码、时常复习、多去相关专业平台上回答和提出问题、多做一些个人项目、加入一个好的团队。让我对一个合格的软件工程师有了新的认识，但文章中还提到的“面对这个问题，答案绝对不只是“只要写很多年代码就好了”，这就像下棋一样，只有用心研究，不断挑战，复习，才可以成为优秀的coder。”【1】让我有了困惑。众所周知，经验对于一个行业领域无疑是非常重要的，那么对于一个新手软件工程师来说，想要更快更好地成为一个合格的软件工程师，除了通过写代码的年份来积累经验，还有什么更加有效可行的积累经验的方式吗？

第二章个人技术和流程

在阅读完这一章以后，我懂得了单元测试、回归测试、效能分析的重要性。还介绍了psp也即为个人软件开发流程。

在读至2.1的单元测试的时候，文中虽然反复强调对于一个程序开发者而言，单元测试的重要性。但只针对C#语言进行了单元测试流程的举例，想了解其他语言中的单元测试流程，在查询了资料过后，找到了博客园中博主小白说我是狗所写的一个较为详细的java语言的单元测试的流程【2】，博主在文中提到的单元测试的概念更加的通俗易懂“单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。”在对单元测试有了进一步的了解之后，我产生了一个新的疑问：本章中提及的单元测试的原则对于所有的语言来说都是同样的标准吗？不同的语言是否有着不同的原则呢？

第三章软件工程师的成长

在阅读完这一章以后，我理解了对软件工程师水平的主要评价方法和技能的反面。还有便是大部分软件工程师很容易陷入的思维误区。

在阅读3.2章节的时候，我看见了这样一段文字“过早优化是一切罪恶的根源”，简单来说就是当我们在编写代码的时候，有时我们会自作聪明地对某些代码过于注重细节过于精益求精，虽然看上去这些“明智”的代码比原先写的那些提高了速度，但是你忽略了一个事实，这些“明智”的代码往往是难以阅读难以理解的——而且真正节省的时间往往只有几毫秒。这就是所谓的过早的优化。既然不要过早的优化，那么我们应该选择怎样的时机来进行优化呢？在进行了查阅资料后，CSDN中有一位博主在文章中提到的：“在优化工作开始的时候，你还尚未明确优化内容和目的，那么你很容易陷入误区。在一开始，你就应该清楚地了解你要达到的效果，以及其他优化相关的各种问题。这些目标需要明确指出（至少精通技术的项目经理可以理解和表达它），接下来，在整个优化过程中，你需要坚持这些目标。”【3】通俗来讲，也就是在有了清晰的需要优化的内容和目标了以后再开始考虑进行优化。

在阅读至3.3章节时，由于利益相关，这是我最感兴趣的一个章节，其中提及到的考级之路更是与我的学习过程息息相关，其中我参与过的考试有全国计算机等级考试，在考试的过程中，我对此的感受便是能在一定程度上检验对于所考领域的水平，但对于对于项目的开发好像并未太大帮助，所以我产生了困惑：计算机专业或者说是软件工程专业要想就业更看重的是相关计算机领域的证书还是实际的开发实践能力？或者说考取了证书是否在就业竞争中更具备竞争力？究竟哪种证书对于软件工程专业的学生就业来说更有含金量？

第四章两人合作

在阅读完这一章以后，我了解了本章的内容主要讲述的是代码规范的重要性、结对编程的方式的运用与重要性，以及两人合作过程中的不同阶段和技巧。

在阅读到4.1的代码规范时，我觉得非常有必要仔细阅读，虽然平时我已经比较注重代码风格的规范，也注意注释的编写。但在阅读完本章节以后，我还是发现了我的一些日常习惯非常不良好，比如不习惯规范变量的使用，两种变量运用的场地不同，但是变量名称则极为相似，在别人观看我的代码的时候时常产生误解。正如文中所说我们的代码要让“旁观者”看得清清楚楚，这样与你合作的人在观看你的代码的时候也不需要多花精力去理解你的意图，提高整个团队的效率。

在阅读至4.5时，了解了“结对编程”的方法，所谓结对编程，也就是两个人写一个程序，其中，一个人叫A，另一个人叫B，A在编程代码，而B在旁边实时查看A的代码，并帮助A编程。看起来非常美好，A和B在一起时可以相互讨论，有效地避免了闭门造车，并可以减少后期的code review时间，以及代码的学习成本。有实验证明，平均下来，结对编程时间花销比单人编程增加不少时间，但也会比单人编程减少不少的代码BUG。如果再算上后期代码的维护和学习成本，结对编程比单人编程更有效率，还更为节省成本。无论是对开发团队还是对于个人，结对编程都会是非常不错的主意。那么结对编程会不会产生消极的影响呢？答案是肯定的。CSDN有位博主在文章中提到了主要的四点：1、与合不来的人一起编程容易发生争执，不利于团队和谐。2、经验丰富的老手可能会对新手产生不满的情绪。3、一山不容二虎，开发者之间可能就某一问题发生分歧，产生矛盾，造成不必要的内耗。4、开发人员可能会在工作时交谈一些与工作无关的事，分散注意力，造成效率低下。【4】

在阅读至4.6讲述两人合作的不同阶段和技巧时，我有着切身体会，因为在我们的课程作业中必定会涉及到团队合作，今天的社会无论什么行业想要做出一番成就，靠一个人打拼天下已经不现实了。所谓人多力量大，三个臭皮匠顶个诸葛亮... ...同样，软件开发也是一样。不可否认，有相当部分牛人确实可以独自扛起大梁，独自完成一项任务。但是，一个人的精力毕竟有限，很难面面俱到，而且软件开发有许多突发事件和难以预料的情况发生。对需求的理解稍微偏差就可能导致项目的失败，团队合作的重要性不言而喻。但是一千个人眼中有一千个哈姆雷特，在合作的过程中必定会出现分歧，在争论的过程中，自己的方案被对方否决过多的话就有一种不服气的念头出现，也就因此滋生矛盾，导致整个作业的进度缓慢。而且在争论的过程中，一时口快有可能说出一些很伤人的话语，这也就是此章节中所提及的最内层反馈：本质和固有属性。那么我也就有了困惑，在团队合作进行软件开发的过程中，什么样才是一个健康有效的团队？或者说怎样的团队合作才有利于提高软件开发的效率？

第五章团队和流程

在阅读完这一章以后，本章为我们详细介绍了典型的软件团队模式和开发流程的种类以及优点和缺点。还介绍了TSP（软件团队过程）、MVP（最小可行产品）、MBP（最强最美产品）、RUP（统一流程）的内涵。

在本章内容里作者列举了非常多的团队模式，比如“一窝蜂模式”、“主治医师模式”、“明星模式”、“社区模式”、“业余剧团模式”、“秘密团队”、“特工团队”、“交响乐团模式”、“爵士乐模式”、“功能团队模式”、“官僚模式”，各种模式都各有特点，但都有一个共通点，那就是每个人在团队中都有自己的任务。那么哪种团队模式对于我们学习中的人比较好呢？在CSDN中有一位博主在他的文章中提到“我觉得对于我们学生现如今而言，比较好的还是交响乐团模式以及功能团队模式。交响乐团门类齐全，各司其职，演奏都靠谱，同时看指挥；而功能团队模式是指具备不同能力的同事们平等协作，共同完成一个功能，在这个功能完成以后，这些人又重新组织，和别的角色一起去完成下一个功能。”【5】当然有效团队模式固然有利于我们的软件开发，但我觉得最终还是需要需要团队中的成员都能意识到自己的任务，不要出现个人的失职影响了整个团队，这才是最重要的。

阅读至5.3.2章节的“瀑布模型”时感觉到非常的熟悉，在原先对软件工程的学习中已经初步了解过了瀑布模型，从“瀑布模型”开始的模型都有一个共同点：重计划，重事先设计，重文档表达，而Rational统一流程（RUP）就是该方法实践的翘楚。RUP要求团队的各种成员在不同阶段做不同事情，将一个周期的开发过程分为四个阶段：初始阶段（为项目建立一个业务案例）、细化阶段（建立工程计划和合理的体系）、构造阶段（建造系统）、交付阶段（把系统提供给用户）。在开发过程中用到了迭代，可以降低风险，得到用户早期的反馈，基于用户反馈，团队可以对系统进行修改，对功能进行调整，交付阶段的终点便是产品发布。

除此之外，还有渐进交互的流程，当系统的主要需求和构架明确之后，团队进入“开发-发布-听取反馈-改进”的不断循环之中，直至时间金钱用完，用户很满意或很不满意方才停止。为了让用户尽早地给团队提供反馈，提出了一种新的方法：MVP，即把产品最核心的功能用最小的成本实现出来，然后快速征求用户意见，既避免了浪费也降低了成本。当然如果对用户需求了然于心，或者产品团队比用户更了解用户的需求，也可以直接把产品最美、最全的形态呈现出来，即MBP。那么我的疑问是：在软件开发的过程中，究竟如何判断哪种流程最适用于当前需要进行的软件开发呢？有没有比较直观的解释？

总结

在阅读完《构建之法》的1-5章的内容过后，我了解了许多之前没有深入了解的内容，其中印象比较深刻的有比如软件工程师常见的思维误区和软件开发的基本流程，也改变了我对软件工程这门学科的一些看法。整本书给人感觉通俗易懂，真正的做到了用简单的语言阐述深奥的道理，还有便是文中的小对话和小故事也能让人眼前一亮，非常的有代入感，能明显的体会到想要表达的内容。但由于学习眼界的狭隘，任然有着许多的专业名词无法理解，希望在接下来对软件工程的学习过程里，能够对软件工程这门学科了解的更为完善，也为以后的项目开发与个人的作业打下基础。

【1】CSDN《如何成为稍微杰出的程序员和软件工程师》https://blog.csdn.net/liangshiquan1/article/details/44003371

【2】博客园《单元测试工具》https://www.cnblogs.com/xiaobaishuowoshigou/articles/5244506.html

【3】CSDN《为什么过早的优化是万恶之源》https://blog.csdn.net/jinzhencs/article/details/50580650

【4】CSDN《结对编程的好处与坏处》https://blog.csdn.net/MOY37RQW1JarN33BgZk/article/details/78879719

【5】CSDN《团队模式及软件开发流程》https://blog.csdn.net/leslieyz/article/details/79585331