构建之法阅读笔记01

看完《构建之法》前六章，不由得感受到作者与王建民主任思想相似的微妙。

个人感受部分：我过去虽然也有提升自己技术能力的想法，并按部就班的实施着我自己认为完美的“大佬养成计划”，但在看完书中二三章的内容后，才发现自己的层次和要求都很低，自己所做的并不足以成为一名优秀的技术人员，通俗的来讲，就是对自己还不够狠，对自己的认识也不够清晰，设定的计划更谈不上完美。所以，在以后的技术能力训练中，一定要系统，善始善终的做好每一个项目。

书中让我最茅塞顿开的地方是第二章的个人技术和流程以及软件工程师的成长，改变了我长期以来对我这个专业发展方向的很多困惑和误解，我一直觉得我作为一个程序员只要学如何写代码，顶多把数据结构和算法掌握清楚、操作系统和计算机网络的知识学习扎实，会写前端会折腾数据库就可以了，其他的能不了解就不用了解。我对于职业规划还一直还停留在学好算法计算机基础就可以进大公司的非常低级的想法层面上，读了这本书之后我才明白自己其实离一个优秀的程序员还差得很远，虽然我一直在努力为实现进入大公司成为优秀的软件工程师这一目标而努力，但是其实努力得还远远不够，而且光局限自己把代码写好是远远不够的，团队协作、小组敏捷开发、迭代会议、单元测试和代码复审这些部分都是我之前完全不了解的，而在我读完以后更有针对性和方法来实现自己的目标，开始关注踏实的学习和提升自己，并更加注意和身边的同学合作写代码并和自己身边的同学一起互相学习，这也提示我这样的初级软件工程师要如何让自己成长起来。

第一章 概论

在这一章中，作者为我们介绍了一些关于软件工程的基本知识。

①软件=程序+软件工程：正是因为对软件开发活动（构建管理、源代码管理、软件设计、软件测试、项目管理）相关的内容的完成，才能完成把整个程序转化成为一个可用的软件的过程。

扩展的推论:软件企业=软件+商业模式

②软件开发的不同阶段：玩具阶段→业余爱好阶段→探索阶段→成熟的产业阶段

③软件所具有的特殊性：复杂性、不可见性、易变性、服从性、非连续性（由软件的本质所决定的）

软件还有其他特性：

·有许多不同的程序设计语言、软件工具和软件开发平台

·存在许多不同的软件开发流程

·软件团队中存在许多不同的角色

·软件通常既可以存储在磁带上，也可以存储在CD/DVD上

④作者邹欣总结的自己做过的项目的各自特点：

• Build To Learn：开发软件，构建系统的目的是做进一步的试验，试图发现客观规律或某个试验方法的优点与缺点。这些项目经常是科研论文的基础工作。

• Build To Show：为了突出地展现某个技术的作用，开发一些演示为目的的软件，这些项目很吸引眼球，经常获得新闻报道，但是功能未必全面。

• Build To Serve：为了服务一定范围的目标用户而构建的工具等，有时以公开的SDK形式发布。

• Build To Win：以在市场上赢得用户为目标而构建的软件。这也是种种科学发现，技术突破最好的试金石。这是我在研究院之外的十余年中做的最多的项目类型，也是这本书的英文名字。

第二章 个人技术和流程

2.1 单元测试

①重要的单元测试：有效解决程序员对模块功能的误解、疏忽或不了解模块的变化之类的问题，使自己负责的模块功能定义尽量明确，模块的质量得到稳定的、量化的保证。

②好的单元测试的标准：

在最基本的功能/参数上验证程序的正确性

单元测试必须由最熟悉代码的人（程序的作者来写）

单元测试过后，机器的状态保持不变

单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）

单元测试应该产生可重复、一致的结果

独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性

单元测试应该覆盖所有代码路径

单元测试应该集成到自动测试的框架中

单元测试必须和产品代码一起保存和维护

③单元测试的基础上能够建立关于这一模块的回归测试，目的是：

（1）验证新的代码的确改正了缺陷

（2）同时验证新的代码有没有破坏模块的现有功能，有没有Regression

2.2 效能分析工具

效能分析方法：抽样和代码注入

2.3 个人开发流程

个人开发流程PSP（Personal Software Process）

特点：（1）不局限于某一种软件技术，而是着眼于软件开发的流程，这样，开发不同应用的软件工程师可以互相比较。

（2）不依赖于考试，而主要靠工程师自己收集数据，然后分析、提高。

（3）在小型、初创的团队中，很难找到高质量的项目需求，这意味着给程序员的输入质量不高。在这种情况下，程序员的输出（程序/软件）往往质量也不高，然而这并不能全部由程序员负责。

（4）PSP依赖于数据（工程师输入数据的时间代价、数据可能遗失或者不准确的风险、可能会出现一些数据不利于工程师本人的情况）

（5）PSP目的是记录工程师如何实现需求的效率，而不是记录顾客对产品的满意度，工程师有可能很高效地开发出一个顾客不喜欢的软件。

第三章 软件工程师的成长

3.1 个人能力的衡量与发展

①软件工程包括了开发、运用、维护软件的过程中的很多技术、做法、习惯和思想。软件工程把这些相关的技术和过程统一到一个体系中，叫“软件开发流程”，软件开发流程的目的是为了提高软件开发、运营和维护的效率，以及提升用户满意度、软件的可靠性和可维护性。

②初级软件工程师的成长包括以下几种：

（1）积累软件开发相关的知识，提升技术技能（如对具体技术的掌握，动手能力）。例如：对JAVA、C/C++、C#的掌握，诊断/提高效能的技术，对设备驱动程序、内核调试器的掌握，对于某一开发平台的掌握

（2）积累问题领域的知识和经验（例如对医疗或金融行业的了解）

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

（4）提升职业技能（区别于技术技能），包括：自我管理的能力、表达交流的能力、与人合作的能力、按质按量完成任务的执行力

（5）实际成果——最重要的评价标准

3.2 软件工程师的职业发展

自我评估，自我评价清单：

软件工程师能力自我评价表

 

第四章 两人合作

4.1 代码规范

包括代码风格规范和代码设计规范

4.2 代码风格规范

代码风格原则：简明、易读、无二异性

缩进：4个空格，而不是TAB

行宽：限定为100字符

括号

断行与空白的{}行

分行

命名：匈牙利命名法

下划线：分隔变量名字中的作用域标注和变量语义

大小写（Pascal形式和Camel形式）

注释

4.3 代码设计规范

函数：只做一件事，并且要做好

goto：有助于程序逻辑的清晰体现

错误处理：参数处理、断言

类的处理

4.4 代码复审

①形式：自我复审、同伴复审、团队复审

②目的：找出代码错误、发现逻辑错误、发现算法错误、发现潜在的错误和回归性错误、发现可能需要改进的地方、传授经验

③代码复审后把记录整理出来：

（1）更正明显的错误

（2）记录无法很快更正的错误

（3）把所有的错误记在自己的一个“我常犯的错误”表中，作为以后自我复审的第一步

4.5 结对编程

①角色：

驾驶员：控制键盘输入

领航员：起到领航、提醒的作用

②好处：（1）在开发层次，可以提供更好的设计质量和代码质量，两人合作解决问题的能力更强。

（2）对开发人员，带来更多的信心，高质量的产出带来更高的满足感。

（3）企业管理层次上，有效地交流，相互学习和传递经验，分享知识，取得更高的投入产出比。

 

第五章 团队和流程

5.2 软件团队的模式

主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、功能团队模式、官僚模式

5.3 开发流程

①写了再改模式

②瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。

瀑布模型的适用范围：产品的定义非常稳定但正确性非常重要、产品模块之间的接口能很好地定性定义和验证、使用的技术很成熟、子团队不能做到频繁的交流。

③瀑布模型的变形：生鱼片模型（各个相邻模块像生鱼片那样部分重叠）以及大瀑布带着小瀑布（各个子系统统一到最后进行系统测试）

5.4 统一流程RUP

统一流程Rational Unified Process，团队的各种成员在一个复杂的软件项目中的不同阶段做不同的事。这些不同类型的工作在RUP中叫做规程或者工作流。简介：

业务建模、需求、分析和设计、实现、测试、部署、配置和变更管理、项目管理。

分为四个阶段：初始阶段（达到生命周期目标里程碑）、细化阶段（达到生命周期结构里程碑）、构造阶段（达到初始功能里程碑）、交付阶段（达到产品发布里程碑）

 

第六章 敏捷流程

6.1 敏捷的流程

①敏捷开发原则：

（1）尽早并持续地交付有价值的软件以满足顾客需求

（2）敏捷流程欢迎需求的变化，并利用这些变化来提高用户的竞争优势

（3）经常发布可用的软件，发布间隔可以从几周到几个月，能短则短

（4）业务人员和开发人员在项目开发过程中应该每天共同工作

（5）以有进取心的人为项目核心，充分支持信任他们

（6）无论团队内外，面对面的交流始终是最有效的沟通方式

（7）可用的软件是衡量项目进展的主要指标

（8）敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去

（9）只有不断关注技术和设计，才能越来越敏捷

（10）保持简明——尽可能简化工作量的技艺

（11）只有能自我管理的团队才能创造优秀的架构、需求和设计

（12）时时总结如何提高团队效率并付诸行动

②敏捷流程概述：找出完成产品需要做的事情→决定当前的冲刺（Sprint）需要解决的事情→冲刺（冲刺期间每天开每日例会）→得到软件的一个增量版本并发布

6.3 敏捷的团队

自主管理：自己挑选任务、自己提出改进并实施改进

自我组织：每个人联合起来对项目负责

多功能型：每个人都全面负责，自己搞定规格说明书，和别人沟通，自己搞定测试

6.4 敏捷总结

在迭代开始时，团队审视摆在他们面前的任务，选择他们认为可以在迭代期间完成的那些任务（Plan）。然后团队独立地尽最大努力完成这些任务（Do）。在迭代结束时，团队给利益关系人展示成果（Check），并对开发流程进行调整（Act/Adjust）。

这里有一些实践者的经验教训：

（1）敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论。

（2）Scrum Master不是一个官，而是一个没有行政权力的沟通者，就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master，大多行不通。

（3）一些项目需要很多暗箱操作和政治角力才能搞定，Scrum会把这些矛盾都摆到明处。这有好处，也有风险。

（4）在复杂的项目里，要让一线团队成员做决定。

（5）创业公司的团队其实经常是运行在Scrum 的模式中（只不过大家太忙，没工夫论证自己到底有多么Scrum）。

（6）在Scrum计划阶段的估计不是一个“合同”，领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint，这样即使不准的估计也不会有大的损害。

（7）不要和管理层谈“流程”，他们只关心“结果”。

（8）在大型团队、跨地区的团队，或者复杂项目中，Scrum并没有非常完美的答案，Scrum的创始人也承认这一点.