Reaction to 构造之法 of Software Engineering From The First Chapter toThe Fifth Chapter（补充版）

几个星期前，我阅读过一篇文章，一位老师教导自己的学生要积极地去阅读文学文献，其中，我很欣赏他的一句话：“Just think of liturature as if you're reading a long text-message”。引申到这里，对比后才发现自己在现实生活中真的很少在课后花时间来细看自己的专业书籍，说来惭愧，这种情况出现的频率最多的就是在学期末备战考试了。因为这次的作业，我似乎告诉自己这是一个非常“恰当”的理由去让自己提前去完成未完的“任务”。阅读一本书，就要认真，要对得起自己，还要对得起作者。这次阅读邹欣老师著作的《现代软件工程——构造之法 》的第一到第五章，我在课堂上用了3节课的时间，在课下用了一个半小时，受益匪浅！

• 第一章（概论）1-19

这一章主要是把“软件工程”这四个字剖析了。从一开始的介绍，就让我们了解到 软件=程序+软件工程，程序=数据结构+算法 。

软件工程是把系统的、有效的、可量化的方法应用到软件的开发、运营和维护上的过程。一个复杂的软件不但要有合理的软件架构、软件设计与实现，还要有各种文件和数据来描述各个程序文件之间的依赖关系、编译参数等等。“软件工程”是一个大项目，里面有很多的概念需要我们理解：源代码管理（配置管理）、质量保障、软件测试、需求分析、程序理解、软件维护（服务运营）、软件生命周期、项目管理、用户体验等等。

“软件工程”的概念是在1968年第一次被提出来的，为了更好的了解它的历史及影响，我们拿软件业和航空业来做对比，可以得出好多相似的地方：

软件它是属于逻辑产品，生产的团队很大，虽然维护比较复杂且易退化，但是它不会磨损老化。在1.2.5节中，谈到了什么是好的软件？同时，我也很疑惑，因为Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性，那么是不是软件没有Bug就是好软件呢？我觉得不然，因为有实际用处的同时又是完美的软件，在这个世界上是不存在的。就算微软很自豪的window8系统也会有偶尔出现蓝屏的现象，但是这并不会直接影响到微软公司的能力，也不会直接影响到window8系统的可用性，因为你的RP是由你的程序质量决定的，所以我个人觉得软件不存在完美，总会有顾客的客观或主观因素而感到不满意，我们不能迎合所有的市场需求，最重要的还是考核市场的主流需求而不断完善自己跟团队研发的作品。

• 第二章（个人技术和流程）20-41

这一章主要是介绍 PSP（Personal Software Process），也就是指个人软件开发的流程，主要由单元测试和效能分析工具组成。

单元测试可以准确、快速地保证程序程序基本模块的正确性，创建单元测试函数的主要步骤是：设置数据、使用被测试类型的功能、比较实际结果和预期的结果。在2.1.2节中谈到了怎样才算一个好的单元测试，经总结后应该是：单元测试应该在最低的功能/参数上验证程序的正确性；单元测试必须由最熟悉代码的人（程序的作者）来写；单元测试过后，机器状态保持不变；单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）；单元测试应该产生可重复、一致的结果；单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据以保持单元测试的独立性；单元测试应该覆盖所有代码路径；单元测试应该集成到自动测试的框架中；单元测试必须和产品代码一起保存和维护。

效能分析主要有抽样和代码注入这两种分析方法。抽样方法不需要改动程序，运行较快，可以很快找到瓶颈，但是不能得出精确的数据，也不能准确表示代码中的调用关系树。而代码注入可以使程序的各个数据都可以被精确地测量，但运行的时间会大大加长，还会产生很大的数据文件，同时也增加了数据分析的时间，这会影响程序的运行情况。如果我们不经分析就盲目优化分析，也许会事倍功半，所以我们要根据实际情况来选择适合自己程序的分析方法。

在2.3节中，对比了大学四年级的学生和工作三年的软件工程师的个人项目耗时，表中可以明显的发现在需求分析和测试这两组数据上，工程师会比大四的学生用时多，而在具体编码上大四学生是比工程师花费的时间多。那这样是不是就一定说明大四的学生比软件工程师弱？我觉得不然，软件工程师是比大四学生多读了3年书，多工作了3年，两类人所处的环境跟所经历的东西不同，所以两个人任务完成的质量要求也就不一样，我觉得，按照目前来说，大四学生在对软件工程运用的熟悉程度上或许还不及工程师，但只要经过刻苦的锻炼，丑小鸭也会变成漂亮的天鹅的！

• 第三章（软件工程师的成长）40-54

    这一章主要讲述了软件工程师中，高级工程师为何会比刚入职的工程师优秀。

初级软件工程师要让自己成长并强大起来，就需要做到：积累软件开发的相关知识，提升技术能力（如对具体技术的掌握，动手能力）；积累问题领域的知识和经验；对通用的软件设计思想和软件工程思想的理解深入；提升职业技能（区别与技术技能）；有实际成果。高级软件工程师，对于我们现在的水平来说，是不是就触不可及了呢？其实不然，我们现在还年轻，还有很多时间去学习、去实践，在通往高级软件工程师的路途上，我们可以考相关的证书来获取理论上的技能，然后去各相关的单位上实习来获取经验，最后通过自主研究或团队开发来进行实践，进而开发大脑智力和提升自己的动手能力。

同时，我们要时刻对自己进行自我评估。绝大部分的软件工程师都不是技术天才，很多都是后天形成的，我们要多对自己的能力进行评估并作出及时的改进，然后通过不断的学习，把那些低层次的问题都解决了，变成不用经大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。

• 第四章（两人合作）56-82

    这一章主要讲述了两人合作的不同阶段和影响他人的技巧。

软件都是在相互合作中完成的，翅膀只剩一边是飞翔不起来的，尽管很努力的飞到半空，也不够双翅滑翔的轻松自如，所以合作真的很重要。在合作中，只有互相交流、交换思想，才会发现自己的优势和不足之处在哪里。有了同伴的监督，可以让自己不敢偷懒，让自己更认真的去查看和更正程序的不足，有了一个方向和目标，让大家更有追求。

在4.4节中，强调了代码复审的重要性。那我们应该以怎样的情况和环境下进行复审呢？代码复审有自我复审、同伴复审和团队复审，在软件工程中最基本的复审手段就是同伴复审。复审者是要通过发现问题来确保软件质量的，我们做代码复审的目的是为了减少错误的发生，而不是找一个人来对着自己点头，所以，找到一个适合自己的同伴来一起工作是很重要的，让两个人在驾驶员和领航员的角色中互换，进而提高双方的能力水平。两个人能够成功的脱颖而出就能够在合作的阶段从萌芽到磨合，进而到规范，不成功的合作伙伴如果不能体谅对方，或许就会输在磨合阶段，因此，换位思考在这里起着至关重要的作用。

两个人的合作即为结对子合作，结对编程其实对结对的我们都会有很多好处：在开发层次，结对编程能提供更好的设计质量和代码质量，两个人合作解决问题的能力更强；对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感；在企业管理层次上，结对能更有效地交流，相互学习和传递经验，分享知识，能更好地应对人员流动。

总之，两只手能抬，两条腿能跑，两个人才能交流合作。

• 第五章（团队和流程）83-99

   这一章主要介绍的是团队精神

那是不是说只要能组合在一起的就是组成了一个团队了呢？其实不然，软件团队有各种形式，适用于不同的人员和需求。适合自己的团队才能共赢！

一个好的团队流程能把冲突的积极方面（各自尽力把自己的工作做好，说服别人）释放出来，而避免消极方面（因为冲突而产生的消极、抵触情绪等）。我们不能因为说有了团队的队友就放松对自己的要求，因为每一个人的工作质量会直接影响到最终软件的质量，当所有的个人高质量工作加起来才可以达到一个优秀的团队高质量工作项目。

软件团队的模式有好多种：主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队模式、特工团队模式、交响乐团模式、爵士乐模式、功能团队模式和官僚模式。每一个团队不能够冲着利益最高的而自创模式或乱串模式，适合自己团队和项目要求的才是最重要的。那么怎样加强与别人的合作呢？在一个组织之中，很多时候，合作的成员不是我们能够选择得了的，所以很可能出现组内成员各方面能力参差不齐的情况，如果作为一个领导者，此时就需要很好的凝聚能力，能够把大多数组员各方面的特性凝聚起来，同时也要求领导者要有很好地与不同的人相处与沟通的能力。如果领导者在开始时没有以身作则做好各方面的工作，就会产生许多不良的后果。

所以，学会与他人合作，发挥团队精神在具体生活中的运用，可以使我们收到事半功倍的效果，可以使我们的工作更加良好地向前发展。