初步了解
对于本书进行了一遍粗略的阅读对于本书有了一个粗略的见解。
1.这本书并不像传统的教材一般，整本书通篇罗列着晦涩难懂的概念，而是运用生动幽默的语言去打动读者，作者将自己的感触和对于软件工程的理解，通过简明扼要的手法落于纸上，更加能够帮助读者理解这本书和软件工程。
2.没读这本书之前，并不太懂软件工程的概念，只是认为软件的核心的就是代码，那么软件工程的核心就是写代码的程序员如何写好代码。在一开始的读书过程中，我颠覆了以往的观念，但后来其实想想也并无大错，其实软件工程的一系列方法，都是为了让程序员更好的去完成工作。软件这门工程，也如同盖楼一样，一个人的能力强大， 最多让某个结构更加坚固，但是软件工程着眼的是整个工程，并不简简单单局限于某个点某个面。我们所罗列的方法与思想，都是为了整个工程流程而服务的。这才是软件工程的核心所在
- 《构建之法》的章节比一般书籍更多（当然在计算机书籍中属于正常），共有17张，每个章节讲述的都是不同的重点，把17章看过了以后，就如同手把手带你领略过了一遍整个软件开发的过程。涵盖的部分包括了测试、项目经理、开发人员、用户体验等等多个方面。多方位的考虑一个软件的成功元素。不同的需求读者，可以选择自己想要的章节进行细化的阅读
其中我对于团队一段印象非常的深刻
总结了一点东西
1.交流
2.说到做到
3.接受团队赋予的角色并按照角色要求工作
4.投入团队
5.流程
6.准备
7.理性
以下是我对于团队的一些重要因素的理解概括
1.目标(Purpose)
团队应该有一个既定的目标，为团队成员导航，知道要向何处去，没有目标这个团队就没有存在的价值。
小知识自然界中有一种昆虫很喜欢吃三叶草(也叫鸡公叶)，这种昆虫在吃食物的时候都是成群结队的，第一个趴在第二个的身上，第二个趴在第三个的身上，由一只昆虫带队去寻找食物，这些昆虫连接起来就像一节一节的火车车箱。管理学家做了一个实验，把这些像火车车箱一样的昆虫连在一起，组成一个圆圈，然后在圆圈中放了它们喜欢吃的三叶草。结果它们爬得精疲力竭也吃不到这些草。
这个例子说明在团队中失去目标后，团队成员就不知道上何处去，最后的结果可能是饿死，这个团队存在的价值可能就要打折扣。团队的目标必须跟组织的目标一致，此外还可以把大目标分成小目标具体分到各个团队成员身上，大家合力实现这个共同的目标。同时，目标还应该有效地向大众传播，让团队内外的成员都知道这些目标，有时甚至可以把目标贴在团队成员的办公桌上、会议室里，以此激励所有的人为这个目标去工作。
2.人(People)
人是构成团队最核心的力量，2个(包含2个)以上的人就可以构成团队。目标是通过人员具体实现的，所以人员的选择是团队中非常重要的一个部分。在一个团队中可能需要有人出主意，有人定计划，有人实施，有人协调不同的人一起去工作，还有人去监督团队工作的进展，评价团队最终的贡献。不同的人通过分工来共同完成团队的目标，在人员选择方面要考虑人员的能力如何，技能是否互补，人员的经验如何。
3.定位(Place)
团队的定位包含两层意思：
团队的定位，团队在企业中处于什么位置，由谁选择和决定团队的成员，团队最终应对谁负责，团队采取什么方式激励下属? 个体的定位，作为成员在团队中扮演什么角色?是订计划还是具体实施或评估?
4.权限(Power)
团队当中领导人的权力大小跟团队的发展阶段相关，一般来说，团队越成熟领导者所拥有的权力相应越小，在团队发展的初期阶段领导权是相对比较集中。团队权限 [3] 关系的两个方面：
(1)整个团队在组织中拥有什么样的决定权?比方说财务决定权、人事决定权、信息决定权。
(2)组织的基本特征，比方说组织的规模多大，团队的数量是否足够多，组织对于团队的授权有多大，它的业务是什么类型。
5.计划(Plan)
计划的两层面含义：
(1)目标最终的实现，需要一系列具体的行动方案，可以把计划理解成目标的具体工作的程序。
(2)提前按计划进行可以保证团队的顺利进度。只有在计划的操作下团队才会一步一步的贴近目标，从而最终实现目标。
精度感想(12)
第一章《概论》旨在说明软件工程的概念。
几个概念：
软件 = 程序 + 软件工程
软件工程可以定义为: 把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程；软件工程包括一下领域：源代码管理+需求分析+程序设计+软件构建+软件测试+软件维护+生命周期管理等，广泛意义的软件工程，还包括用户体验、用户界面设计(UID)等； 软件工程决定了软件质量。
文中还提到软件工程和计算机科学的关系，这也是容易让人迷糊的两个概念，很多同学在高考填志愿的时候不知道他们的区别，到学校后发现学的东西差异也不是很大；而实质上这是两个侧重点差异很大的概念；从知识领域上说，计算机科学包含计算机体系结构、操作系统、图形学、人工智能等，而软件工程包含软件需求、软件设计、软件维护、软件测试等；
软件工程的目标：创造足够好的软件。那么什么是足够好，不仅仅是没有bug；评价软件的维度包括：用户满意度、可靠性、软件流程的质量、可维护性等。关于软件流程的质量，指的是软件团队和开发流程的问题太多，导致团队成员无法良好协作，按时交付，也可以说是软件团队的bug; 流程的质量往往是我们的研发过程中最容易忽视的地方，反思目前我们的现状，很对研发团队的研发流程实质是处于真空状态，开发人员甚至不知道怎样才是软件开啊的正确姿势。下半年结合团队运作中SM、BA、QA的角色职责梳理，特别关注下团队的研发流程质量。
总之，从三点去理解软件工程：
1 研发出符合用户需求的软件
2 通过一定的软件流程，在预计的时间内发布“足够好”的软件
3 通过数据和其他方式展现所开发的软件是可以维护的继续发展的
第二章《个人技术和流程》，本章的实质是在说明，一个合格的软件工程师是怎样的，他应该具备哪些技能。
总结下来，一个合格的工程师在开发时需要同时考虑质量和效率，与之同时需要具备的技能包括：单元测试、效能分析、个人研发流程（PSP）；
关于单元测试的正确做法：
1 单元测试应该在最低的功能/参数上验证程序的正确性
2 单元测试必须由最熟悉代码的人(作者)来写
3 单元测试过后，机器状态保持不变
4 单元测试要快(一个测试用例的运行时间是几秒钟)
5 独立性—测试的运行/通过/失败不依赖于别的测试
6 覆盖所有代码路径
7 单元测试应该集成到自动化测试的框架中
8 单元测试必须和产品代码一起保存和维护
关于性能分析。
性能分析往往是开发人员容易忽视的步骤，这也是为什么我们一年一年的不停做性能优化的原因，大部分人对嵌入式的实时性和性能要求没有概念。 Visual Studio实际上提供了性能分析工具(Tools\PerformanceTools\Performance Wizard),其中有两种分析方法:Sampling和Instrumentation,即抽样和代码注入，抽样的原理比较简单，kprofile也类似，就是用比较短的周期去采用PC指针，看看是在哪个函数在执行，并把当前周期的时长累计为该函数的执行时长； 代码注入，相当于打点，是将检测的代码加入到每个函数中。
一般进行性能分析的做法是，先用抽样的方法找到函数热点，然后对特定的模块用代码注入进行详细分析。
这个方法，后面在我们的性能优化工作中可以多尝试下，让业务和支撑领域相关人员看看效果。
关于个人开发流程。
我们熟知CMM和CMMI，软件行业的国际通用标准，这两种能力成熟度模型，他们是用来衡量一个团队能力的模型，由卡内基梅隆大学(CMU)制定推出。其实CMU的专家针对软件工程师也有一套模型，叫Personal Software Process（PSP），即个人开发流程的标准；
为简单说明PSP以及它的意义，截两张图，看完你就明白了；
这张图，说明的是标准的PSP步骤；其中值得关注的一点是，代码复审是在测试之前进行的。
作者做了一个很有意思的统计，对两组人的PSP过程耗时进行了对比分析。一组是中科大大四的学生，一组是工作三年的软件工程师；见下图：
上图可以明显看到，工作三年后的工程师在“需求分析”和“测试”两个方面明显的要花更多的时间（60%以上），而在具体编码上，工程师比学生花更少的时间。
假设再统计一组6年工程师的数据，我相信又不太一样，但是趋势应该一样，即对质量的要求更高，成熟的工程师在需求分析、设计、测试上会花更多的心思。而普通的开发人员，把更多的精力放到了写代码上。
总结：个人开发流程要着眼的是整个软件开发的流程，输出高质量的产品，需要从个人开发流程上去找bug，然后不断修正，工程师才会成长，产品质量才会不断提高。
