经过了几天的阅读，看完了前六章。想着对这些部分做一个总结。
这本书其实际来说，就是在讲软件工程的流程和各个部分的介绍。不同于其他的书，只有文字。这本书有文字，有例子，也有代码。解释的很清楚。并且作者的语言十分诙谐幽默，读起来确实很快，不知不觉就看了二三十页。内容也不是如课本那样十分枯燥的内容。并且各个小节也讲的十分清楚。
作者在第一章提出了一个综述，即什么是软件，什么是软件工程，对于这部分作者不仅提到了基本的定义，还就提出这些定义的理由进行了解释。我们大家都知道， 程序=算法+数据结构，但是包括我自己在内，一直有一个疑问，我学了数据结构，有什么用呢？我在C语言中实现了二叉树的各个算法，但是java中又不使用指针，那么我学习二叉树又有什么用呢？作者通过一个例子来详细的解释了其用处。软件=程序+软件工程。一个软件的实现必然会用到算法和数据结构等设计，但软件是给人用的，人们必然有各种要求，软件公司又要赚钱，那么又是怎么个商业模式呢？这些都是软件工程来考虑的问题范畴。软件工程是什么呢？其实软件工程就是把各种实际的方法用到软件的开发运营和维护上。注重实践。这也是作者提出的learn by doing(做中学)的一个合理解释。软件工程是注重实践的，比起创新，稳定来的更为重要。基于软件的各种特殊性，人们总结了一系列对于软件的方法，这些方法实用起来就是所谓的软件工程了。
在第一章介绍了软件工程概念的基础上，第二章又开始介绍一个人开发软件的流程和技术。即PSP（Personal Software Process） 在问题的伊始，为了保证各个软件中各个模块的稳定性和质量，需要进行单元测试，在这个章节中，作者首先介绍了用VSTS（Visual Studio Team System 由微软开发的一套生命周期管理工具）进行单元测试。这部分由于我自己没有开发的经验，看的迷迷糊糊的。也就不再班门弄斧了。在介绍完后，作者提出了对于单元测试好坏的判定标准。毕竟单元测试也分做的好的和做的不行的。并针对这些提出了一系列的要求。单元测试后，作者又提出了一种回归测试。这种测试是基于单元测试的。所谓的回归（Regress）即倒退，退化的意思。在项目中，如果一个模块以前是正常的，新的构建中却出了问题，就说这个模块发生了一个退步，我们要做的就是修复这个退步，并且继续开发下去。这也就是所谓的回归测试。在这之后，作者介绍了效能分析工具。这种工具可以用来分析算法的复杂度，并帮助人们改善情况。基于以上的单元测试和效能分析工具这两种工具，作者提出了PSP，个人开发的具体流程。并详细介绍了PSP的特点。在这之后，作者提出，每个人要开始管理自己的源代码，并且对软件工程课程的开设提出了自己的一些要求。
第三章， 笔锋一转，提出了评价一个软件工程师的主要方法。个人能力的提高，作者认为有五种方式：1.积累软件开发的相关知识，提升技术技能，比如对于编程语言的掌握，等等。2.积累问题领域的知识和经验。3.对通用的软件设计思想和软件工程思想的理解。4.提升职业技能 ，包括自我管理的能力，表达和交流的能力，与人合作的能力等等。5.实际成果，即实际的项目等。那么如何衡量软件开发的工作量和质量？PSP认为有四个因素：a 项目/任务有多大，b 花了多少时间 c 质量如何 d 是否按时交付。除此之外，在团队中，也有对于个人的期待。相对于PSP，有TSP（Team Software Process），TSP对团队成员也有着很多要求，如交流，说到做到，全力投入等等。在结束了这部分的讲解后，作者指出了软件工程师的一些思维误区：分析麻痹、不分主次，想解决所有依赖问题、过早优化、过早泛化。最后，作者提出了对于软件工程师的职业发展方向。对于我个人的发展有了很大进步。最后的最后，作者通过技能的反面这一概念讲了如何提升自己的技能。
第四章，两人合作。一个项目，大部分情况下都是由很多人一起写的。那么在这种情况下，就对代码的规范，有了一定要求。作者提出了对于代码的规范的两个分类——代码风格规范和代码设计规范。这部分内容很明显与我自己的开发也息息相关。我尽量做到在以后的编程中按照这些规范来写程序，这样才能让程序被别人看懂，进而改进。同时也方便自己日后看懂。在代码的最后，要进行代码复审。代码复审就是找出代码的错误，并且优化代码的算法。在这样的情况下，作者提出了结对编程的概念：结对编程，即两人一起在一起关在一个小黑屋里进行同时同进度的编程，随时进行代码复审。这种方法有好处但也有坏处。最后作者提出了两人合作的不同阶段和技巧。指出在合作中要学会正确的交流，不仅能把自己的想法传递给对方，还要说的好听。
第五章，团队。在两人合作的基础上，就发展到了一个团队。软件团队有着各种各样的模式。作者从一窝蜂模式（Chaos Team） Chaos其实就是英语里混乱的意思，其最起初的混乱模式，到逐渐形成有分工，分工明确，每个人有任务的功能团队模式（Feature Team）在这样的团队里，每个人都有着各自固定的职能，这样的模式也是被大多数现代公司所采用的一种模式。同时也介绍了一种走偏的模式——官僚模式，这种模式中各个老板都为了利益而争夺，十分不平衡。一个好的团队模式对于开发的好处是难以言表的。在好的团队模式中，设计效率和质量都会有着极大的提升。在开发中，也有一些开发流程。从写了再改模式到RUP（Rational Unified Process 统一流程），这一方法集大成的吸收了瀑布模型的特点，对于复杂的软件项目有着很好的解决方案。最后提出了一种最接近迭代式开发流程的渐进交付的流程，即开发，发布，听取意见，改进。不断重复这个流程。
第六章，提出了敏捷流程的概念。敏捷流程是一堆方法论的总结，是一种软件开发的思想。作者从理论和实际分别出发，分析了敏捷流程的问题和解法，最后对其做了一定的完善。在最后的敏捷总结中，作者对敏捷流程的本质进行了一定程度的分析。并通过一系列的问答指出，敏捷也有其使用范围。详细分析了敏捷流程的足与不足。对未来也进行了展望。
来源：https://www.cnblogs.com/wushenjiang/p/12213868.html