构建之法——现代软件工程有感

作者：@kuaiquxie
作者的github：https://github.com/bitebita
本文为作者原创，如需转载，请注明出处：https://www.cnblogs.com/dzwj/p/16322668.html

　　这本书有文字，有代码。并且解释的很清楚。值得一提的是作者十分诙谐幽默，读这本书完全是因为书中的内容吸引了自己。所以想把自己读过之后的感悟分享给大家。

　　第一章讲了综述，即什么是软件，什么是软件工程，对于这部分作者不仅提到了基本的定义，还就提出这些定义的理由进行了解释。我们大家都知道，程序=算法+数据结构，在学数据结构的时候我就在想，我学了数据结构，这东西到底有什么用呢？我在C语言中实现了二叉树的各个算法，但是java中又不使用指针，那么我学习二叉树又有什么用呢？作者应该是体会到这一些东西，并解释了这些内容干嘛干嘛的，软件=程序+软件工程。一个软件的实现必然会用到算法和数据结构等设计，但软件是给人用的，人们必然有各种要求，软件公司又要赚钱，那么又是怎么个商业模式呢？这些都是软件工程来考虑的问题范畴。软件工程是什么呢？其实软件工程就是把各种实际的方法用到软件的开发运营和维护上。注重实践。软件工程是注重实践的，比起创新，稳定来的更为重要。基于软件的各种特殊性，人们总结了一系列对于软件的方法，这些方法实用起来就是所谓的软件工程了。

　　第二章，介绍一个人开发软件的流程和技术。为了保证各个软件中各个模块的稳定性和质量，需要进行单元测试，在这个章节中，作者首先介绍了用VSTS（Visual Studio Team System 由微软开发的一套生命周期管理工具）进行单元测试。这部分由于我自己没有开发的经验，看的迷迷糊糊的。也就不再班门弄斧了。在介绍完后，作者提出了对于单元测试好坏的判定标准。毕竟单元测试也分做的好的和做的不行的。并针对这些提出了一系列的要求。单元测试后，作者又提出了一种回归测试。这种测试是基于单元测试的。所谓的回归（Regress）即倒退，退化的意思。在项目中，如果一个模块以前是正常的，新的构建中却出了问题，就说这个模块发生了一个退步，我们要做的就是修复这个退步，并且继续开发下去。这也就是所谓的回归测试。在这之后，作者介绍了效能分析工具。这种工具可以用来分析算法的复杂度，并帮助人们改善情况。基于以上的单元测试和效能分析工具这两种工具，作者提出了PSP，个人开发的具体流程。并详细介绍了PSP的特点。在这之后，作者提出，每个人要开始管理自己的源代码，并且对软件工程课程的开设提出了自己的一些要求。

　　第三章，评价一个软件工程师的主要方法。个人能力的提高，作者认为有五种方式：

　　　　1.积累软件开发的相关知识，提升技术技能，比如对于编程语言的掌握，等等。

　　　　2.积累问题领域的知识和经验。

　　　　3.对通用的软件设计思想和软件工程思想的理解。

　　　　4.提升职业技能，包括自我管理的能力，表达和交流的能力，与人合作的能力等等。

　　　　5.实际成果，即实际的项目等。那么如何衡量软件开发的工作量和质量？

　　PSP认为有四个因素：

　　　　a 项目/任务有多大，

　　　　b 花了多少时间

　　　　c 质量如何

　　　　d 是否按时交付。

　　除此之外，在团队中，对个人也是需要一些要求的。相对于PSP，TSP对团队成员也有着很多要求，如交流，说到做到，全力投入等等。在结束了这部分的讲解后，作者指出了软件工程师的一些思维误区：分析麻痹、不分主次，想解决所有依赖问题、过早优化、过早泛化。最后，作者提出了对于软件工程师的职业发展方向。对于我个人的发展有了很大进步。最后的最后，作者通过技能的反面这一概念讲了如何提升自己的技能。

　　第四章，两人合作。一个项目，大部分情况下都是由很多人一起写的。那么在这种情况下，就对代码的规范，有了一定要求。作者提出了对于代码的规范的两个分类——代码风格规范和代码设计规范。这部分内容很明显与我自己的开发也息息相关。我尽量做到在以后的编程中按照这些规范来写程序，这样才能让程序被别人看懂，进而改进。同时也方便自己日后看懂。在代码的最后，要进行代码复审。代码复审就是找出代码的错误，并且优化代码的算法。在这样的情况下，作者提出了结对编程的概念：结对编程，即两人一起在一起关在一个小黑屋里进行同时同进度的编程，随时进行代码复审。这种方法有好处但也有坏处。最后作者提出了两人合作的不同阶段和技巧。指出在合作中要学会正确的交流，不仅能把自己的想法传递给对方，还要说的好听。

　　第五章，团队之间协同合作。在两人合作的基础上，就发展到了一个团队。软件团队有着各种各样的模式。作者从一窝蜂模式（Chaos Team） Chaos其实就是英语里混乱的意思，其最起初的混乱模式，到逐渐形成有分工，分工明确，每个人有任务的功能团队模式（Feature Team）在这样的团队里，每个人都有着各自固定的职能，这样的模式也是被大多数现代公司所采用的一种模式。同时也介绍了一种走偏的模式——官僚模式，这种模式中各个老板都为了利益而争夺，十分不平衡。一个好的团队模式对于开发的好处是难以言表的。在好的团队模式中，设计效率和质量都会有着极大的提升。在开发中，也有一些开发流程。从写了再改模式到RUP（Rational Unified Process 统一流程），这一方法集大成的吸收了瀑布模型的特点，对于复杂的软件项目有着很好的解决方案。最后提出了一种最接近迭代式开发流程的渐进交付的流程，即开发，发布，听取意见，改进。不断重复这个流程。

　　第六章，敏捷开发模型，这是个软件工程具体的模型，作者在这里也有讲到。敏捷流程是一堆方法论的总结，是一种软件开发的思想。作者从理论和实际分别出发，分析了敏捷流程的问题和解法，最后对其做了一定的完善。在最后的敏捷总结中，作者对敏捷流程的本质进行了一定程度的分析。并通过一系列的问答指出，敏捷也有其使用范围。详细分析了敏捷流程的足与不足。