最近终于有时间来读读书了。买了《构建之法》已经一年多了，这次静下心来读完了，收获很大。现在想起自己在上大学的时候学习软件工程是机械工业出版社出版的一本外国书籍的翻译版本，当时由于对于整个行业没有太大的感触，而这本书又全部由专业术语和定义组成，所以当时的课是相当痛苦。而老师通过的这门课程的方式又由各种理论知识考试为准，所以当时学习感觉相当“鸡肋”。

好的地方：

1，情景式、对话式对白，有趣易读。这点非常喜欢，很多实际中碰到的问题在这里可以重现。比如：每日构建，在实际开发中，就会由于各种原因导致不愿意或者没时间去构建。比如：MSF章节中，对于推动信息共享与沟通中，讲“宁可过分沟通”，这点在实际开发过程中十分受用，有时甚至只有过分沟通才能暴露出问题。

2，介绍作为软件从业人员的一些准则。这是本书的又一亮点，比如：两人合作章节，讲如何正确地给予反馈，这点对于很多开发人员来讲很重要，因为在开发过程中会有很多意见不同，如何正确的反馈自己的意见，减少不必要的争执，这点对于提高工作效率十分有用。

3，注重实践。软件工程本来就是一门理论和实践并重的课程，可是很多时候，大学的软件工程理论和实践是分离的，甚至只注重理论，讲一堆概念，定义，这对于初学者理解非常不利，我记得当时我上大学的时候，老师讲解白盒测试、黑盒测试、集成测试、单元测试等等，很多测试的概念，这对于不使用这些测试的大学生完全是陌生的，只有实际做了项目，实际中应运了这个测试，才能知道各个测试是干什么的。而这本书不光讲了这些概念，还通过对话式独白讲解了这些概念在实际中的应运，并且通过学生做项目进一步加深了理解。

4，由浅到深。比如：第一章，举例中讲解了软件工程可能涉及到的的方方面面，非常易于理解。（程序、工程、应用软件、软件服务、源程序、数据、构建、源代码管理、配置管理、质量保障、软件测试、需求分析、程序理解、软件维护、服务运营、软件的生命周期、软件项目的管理、用户体验、商业模式等等）。

5，第十三章，软件测试章节的组织和安排非常喜欢。先讲了不同角度的测试分类，然后着重讲了各个测试，又讲了实战中的测试，并讲了测试中的文档，最后介绍了测试工具。非常喜欢。

6，覆盖面广。这也是这本书的特点，比如：职业道德、绩效、IT行业创新、项目经理等章节。

可以改进的地方：

结构建议：

1，我读的这个版本（人民邮电出版社，ISBN 978-7-115-36916-1）中，配图不够清晰，如图2-1、2-3、2-5、2-6、3-1等

2，4.5.2这个题目一定忘记加粗了。

3，图8-15对四个象限的不同建议，四个象限的标注应该是有问题的，每一象限中都写着第二象限。

4，如果作为大学教程，MSF流程章节，其实没有必要单独成为一章。

内容建议：

1，第2章讲个人技术和流程，从接受程度方面感觉有些突兀。

2，第12章用户体验，讲的不够清楚。主要是：作为一个软件项目，用户体验应该考虑的更早，而整个软件开发的过程中都要考虑用户体验。改进建议：

1)用户体验之初体验：一些设计方面好的例子、一些设计不好的例子

2)用户体验的设计步骤和目标。这里最好能够讲解的更为详细一些。比如用户体验是要求从更底层、更早就要考虑的，应该扩展开来讲解。

3)用户体验的一些标准

4)练习。让大家举一些生活中的例子。马桶？

3，书本重广度和易于理解，深度不够，所以对于选择阅读这本的人，可以看看是否适合自己。

对现在工作的提升：

1.代码复审

代码复审这块的感触非常大，因为之前接触的公司项目，开发流程不够完整，在公司做开发的过程中，缺少了代码复审的环节。导致在上线过程中总会存在一些问题。今年初管理项目过程中加了代码复审，至少有以下几个方面的提升：

1)代码质量较之前提升很多，上线成功率提高很大。

2)新员工培养。很多时候新的开发人员，即使复审的人员不说话，只让他自己讲解一遍自己的代码都会发现很多问题。

2.敏捷流程

在管理项目的这两年中，其实刚接手项目的新人是没有明确的项目管理流程，刚开始不知道自己是瀑布模型还是敏捷流程，把这段不知道自己是什么开发流程的模式称为：前任模型。因为项目是从带你的老员工手里接过来，为了保证项目顺利开发、人员稳定过度，所以一般的情况下刚接手是不会变的。只有在全部掌握了之后，才会去修改之前流程中的不合理部分。

在管理项目的过程中，最接近敏捷流程的一次应该是去年下半年独立管理一个换版项目过程中。使用的是TDD（Test Driven Development）测试驱动开发。

3.需求分析

• 准确寻找需求

现在公司定位的岗位是：项目管理岗位，但是公司对于项目管理的职责范围至少包含了：需求分析师、产品经理、项目经理这三个角色。所以分析需求是工作中的很大一部分。获取和引导需求、分析和定义需求是很考验一个需求分析师能力的时候。

失败案例：

微信公众号系统，项目经理A负责

活动系统，项目经理B负责

业务要求，绑定公众号之后，才能参加活动。

按照业务要求进行的系统功能划分，绑定的判断只能在微信公众号系统判别，而参加活动的业务实现是在活动系统，所以客户绑定之后可以从微信公众号系统跳转到活动系统参加活动，整个活动是在活动系统完成的，符合业务要求（绑定公众号之后，才能参加活动）。但是完成之后，在业务验收阶段：发生如下对话：

业务：为什么我没绑定看不到活动？

项目经理：你要求是绑定只能才能参加活动啊？

业务：是啊，我是绑定之后才能参加活动，但是没绑定的客户要看到活动啊，要给微信公众号系统吸引流量，你绑定判断应该在活动主页的“参加活动”上面加啊，你不能让我们进不来，看不到活动啊。

项目经理：。。。。。。

（因为绑定的判断只能在微信公众号系统，而整个活动功能，活动系统已经实现了，活动系统是不能判断绑定的，所以需要对于功能重新划分实现）。

• 需求划分

职责中有需求分析师的工作内容，接触了各个条线的业务人员之后，会发现很多业务方面的需求多是“对产品功能性的需求”，业务条线人员多是不知道“对产品开发过程的需求”、“非功能性需求”的。所以在这方面的开发过程中，作为项目经理务必要对于业务提出的需求进行审核和分析，提高“非功能性需求”质量。

• 计划和估计

在做需求的过程中，业务和领导问的最多的大概就是这个功能的大概需求多长时间完成，所以项目经理对于项目的计划和估计显得十分重要。书中说的：回溯方法，在很多时候其实就是这样执行的，最终交付日期往前推。

4.事后诸葛亮会议

一个项目或者一个需求完成之后的总结和反思是必不可少的。

思维导图：

学习笔记：

在读书的过程中，有一些点讲的非常好，记录下来：

给授课老师和助教的建议

【1】PXII给授课老师和助教的建议：

第一条：沟通

第二条：简明公开的规则

第三条：循序渐进，激励和不断总结

第四条：对付南郭先生

第五条：模拟实战，用客观数据来评分

第六条：截止期限

第七条：构造怎样的学习环境

第八条：聆听，总结，分享，改进

【2】PXVII给授课老师和助教的建议，第七条：构建怎样的学习环境

• 人是怎么学习的？

1，知识体系是构建出来的，而不是接收到的。与其灌输知识，不如让学生自己构建。

2，人的认知模型改变得非常缓慢，搞那些速成的、疯狂的、喊口号的培训未必改变了人的认知模型。

3，提问能帮助构建知识体系。所以我们要鼓励学生思考、辩论。

4，身心投入是学习的关键。没有一定的工作量，怎么能达到“身心投入”呢？

【3】XVIII给授课老师和助教的建议，第八条：聆听，总结，分享，改进

合法性被别人认可，除了自身的资质以外，还有三个因素。

• 公平性：对所有学生都一视同仁
• 反馈：能听取所有学生的意见，并作调整
• 可预见性：与课程相关的规定不会朝令夕改

【4】XIX给授课老师和助教的建议，第八条：聆听，总结，分享，改进

美国加州大学一流软件企业对软件工程教学的要求，优先级最高的几项依次是：

1，How to enhance sparsely-documented legacy code(怎样改进缺少文档的老代码)；

2，Making testing a first-class citizen(测试与开发并重)；

3，Working with non-technical customers(怎么跟不懂技术的客户交流)；

4，Working in teams(在团队内有效率地工作)。

第一章概论

【1】什么是软件？

【2】什么是软件工程？

第二章个人技术和流程

【1】单元测试

单元测试验证标准：

• 单元测试应该在最低的功能/参数上验证程序的正确性
• 单元测试必须由最熟悉代码的人（程序的作者）来写
• 单元测试过后，机器状态保持不变
• 单元测试要快（一个测试的运行时间是几秒，而不是几分钟）
• 单元测试应该产生可重复，一致的结果
• 独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。
• 单元测试应该覆盖所有的代码路径
• 单元测试应该集成到自动测试的框架中
• 单元测试必须和产品代码一致保存和维护

【2】回归测试

回归测试的目的：

• 验证新的代码的确改正了缺陷
• 同时要验证新的代码有没有破坏模块的现有功能

【3】效能分析工具

• 抽样
• 代码注入

【4】个人开发流程

第三章软件工程师的成长

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

【2】初级软件工程师如何成长？

• 积累软件开发相关的知识
• 积累问题领域的知识和经验
• 对通用的软件设计思想和软件工程思想的理解
• 提升职业技能
• 实际成果

【3】考证

• 软考
• 公司职业认证项目：微软认证专家、Oracle认证项目

【4】怎么提高技能

• 通过不断练习，把那些低层次的问题都解决了，变成不用经过大脑的自动操作，然后才有时间和脑力解决较高层次的问题。
• 解决问题的能力

第四章两人合作

【1】代码风格规范（参考如下自己曾经做过的笔记）

http://www.cnblogs.com/xt0810/p/3543972.html

http://www.cnblogs.com/xt0810/p/3544078.html

http://www.cnblogs.com/xt0810/p/3544356.html

参考：

http://hawstein.com/posts/google-java-style.html

【2】代码设计规范

• 函数：只做一件事，并且做好
• 如何处理C++中的类（这段写的也非常好，不过现在用JAVA多一些，这段暂不记录）
• 代码复审

定义：看代码是否在“代码规范”的框架内正确地解决了问题

  目的：

1.找出代码的错误：编码错误和规范问题

2.发现逻辑错误

3.发现算法错误

4.发现潜在的错误和回归性错误

5.发现可能需要改进的地方

6.教育(互相教育)开发人员，传授经验。

    步骤：

1，代码复审前

1)代码必须成功编译，在所有要求的平台

2)程序员必须测试过代码

3)程序要必须提供新的代码，以及文件差异分析工具。

4)复审者可以选择面对面的复审、独立复审或其他方式。

5)在面对面复审中，一般是开发者控制流程，讲述修改的前因后果。但是复审者有权在任何时候打断叙述，提供自己的意见。

6)复审者必须逐一提供反馈意见。注意，复审者有权提出很多看似吹毛求疵的问题，复审者不必每一件事都要亲自调查，开发者有义务给出详尽的回答。要记住复审者是通过问这些问题来确保软件质量的，而不是有意找碴儿。

7)开发者必须负责让所有的问题都得到满意的解释或解答，或者在TFS（Team Fundation Server管理和开发软件项目的整个生命周期的平台工具）中创建新的工作项以确保这些问题会得到处理。

8)对于复审结果，双方必须达成一致的意见。

a)打回去

b)有条件的同意

c)放行

2，代码复审中

1)修改之后会不会影响别的功能

2)此类修改是不是只有这一块

3)说明是否明确

4)对于这样的修改，有没有别的成员需要告知

5)导致问题的根本原因是什么？如何以后自动避免问题再次出现？

3，代码复审后

1)更正明显的错误

2)对于无法很快更正的错误，要在项目管理软件中创建Bug把他们记录下来

3)把所有的错误记载自己的一个“我常犯的错误“表中，作为以后自我复审的第一步。

4，核查内容:

1)概要部分

a)代码能符合需求和规格说明么？

b)代码设计是否考虑周全？

c)代码可读性如何？

d)代码容易维护么？

e)代码的每一行都执行并检查过了吗？

2)设计规范部分

a)设计是否遵从已知的设计模式或项目中常用的模式？

b)有没有硬编码或字符串/数字等存在？

c)代码有没有依赖于某一平台，是否会影响将来的移植？

d)开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现？在本项目中是否存在类似的功能可以调用而不用全部重新实现？

e)有没有无用的代码可以清除？

3)代码规范部分

修改的部分符合代码标准和风格

4)具体代码部分

a)有没有对错误进行处理？对于调用的外部函数，是否检查了返回值或处理了异常？

b)参数传递有无错误，字符串的长度是字节的长度还是字符的长度？是以0开始计数还是以1开始计数？

c)边界条件是何如处理的？switch语句的default分支是如何处理的？循环有没有可能出现死循环？

d)有没有使用断言（Assert）来保证我们认为不变的条件真的得到满足？

e)对资源的利用，是在哪里申请，在哪里释放的？有无可能存在资源泄露（内存、问卷、各种GUI资源、数据库访问连接，等等）？有没有优化的空间？

5)效能

a)代码的效能如何？最坏的情况是怎么样的？

b)代码中，特别是循环中是否有明显的可优化的部分？

c)对于系统和网络的调用是否会超时？如何处理？

6)可读性

代码可读性如何？有没有足够的注释？

7)可测试性

代码是否需要更新或创建新的单元测试？

【3】结对编程

如何正确地给予反馈？

强调双方的共同点，从团队共同的愿景讲起，让双方觉得处于一个安全的环境。

重于【行为和后果】这一层面。

第五章团队和流程

【1】瀑布模型

适用范围：

• 如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证
• 产品模块之间的借口、输入和输出能很好地用形式化的方法定义和验证
• 使用的技术非常成熟、团队成员都很熟悉这些技术
• 负责各个步骤的子团队分属不同的机构，或在不同的地理位置，不可能频繁的交流

【2】Rational统一流程（RUP）Rational Unified Process

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

一个大阶段的结束称为一个里程碑。

第六章敏捷流程

【1】敏捷的原则

• 尽早并持续地交付有价值的软件以满足顾客需求
• 敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
• 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
• 业务人员和开发人员在项目开发过程中应该每天共同工作
• 以有进取心的人为项目核心，充分支持信任他们
• 无论团队内外，面对面的交流始终是最有效的沟通方式
• 可用软件是衡量项目进展的主要指标
• 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
• 只有不断关注技术和设计，才能越来越敏捷
• 保持简明——尽可能简化工作量的技艺——极为重要
• 时时总结如何提高团队效率，并付诸行动

【2】敏捷流程的经验教训

• 敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论
• Scrum Master 不是一个官，而是一个没有行政权力的沟通者，就像微软的Pm那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master，大多行不通。
• 一些项目需要很多暗箱操作和政治角力才能搞定，Scrum 会把这些矛盾都摆在明处。这有好处，也有风险。
• 在复杂的项目里，要让一线团队成员做决定。
• 创业公司的团队其实经常是运行在Scrum 的模式中（只不过大家太忙，没工夫论证自己到底有多么scrum）。
• 在Scrum计划阶段的古旧不是一个“合同”，领导们不要把它当做一个合同。估计总是不准的。坚持短期的Sprint，这样即使不准的估计也不会有大的损害。
• 不要和管理层谈“流程”，他们只关心“结果”。
• 在大型团队、跨地区的团队，或者复杂项目中，Scrum并没有非常完美的答案，Scrum的创始人也承认这一点。

【3】TDD（Test Driven Development）测试驱动开发

第七章MSF微软解决方案框架（Microsoft Solution Framework）

【1】MSF基本原则

• 推动信息共享与沟通
• 为共同的远景而工作
• 充分授权和信任
• 各司其职，对项目共同负责
• 交付增量的价值
• 保持敏捷，预期和适应变化
• 投资质量
• 学习所有的经验
• 与顾客合作

【2】学习所有的经验

• 含义：

1.把经验总结出来

2.分享经验

• 目的：

1.让团队成员从别人的成果和失败的例子中学到东西

2.帮助新项目重复以往成果的做法

3.培育团队总结的习惯和“批评与自我批评”的文化

【3】责任和驱动

无责任的旁观者和有重大责任的当局者的看法自然是不一样的

第八章需求分析

【1】准确寻找需求：

• 获取和引导需求
• 分析和定义需求
• 验证需求
• 在软件产品的生命周期中管理需求

【2】需求分类

• 对于产品功能性的需求
• 对于产品开发过程的需求
• 非功能性需求
• 综合需求

【3】“三拍”——反例

• 拍脑袋
• 拍胸脯
• 拍屁股

【4】NABCD模型——N（Need，需求）、A（Approach，做法）、B（Benefit，好处）、C（Competitors，竞争）、D（Delivery，推广）。

【5】功能的定位——四象限方法

【6】计划和估计

• 整个软件项目的时间估计也可以从两个方面来看：

1)自底向上。团队成员各自估计底层模块和单个功能（及单元测试）所需的时间，再加上集成及基本测试的时间，就是大概的开发时间。这还没有考虑各个模块之间的相互依赖性。

2)回溯。团队从整个项目最终交付之日往回倒推。

【7】分而治之

• 保证所有子节点覆盖了全部父节点包含的内容
• 保证各个子节点不要互相覆盖
• 叶子节点要保证足够小，能在一个里程碑中完成。在通常的软件项目中，叶子节点的成本最好不要超过两周。如果团队成员从常理出发，认为叶节点不宜再分下去，那就可以停止。
• 从结果出发构建WBS，而不是从团队的活动出发。

第九章项目经理

【1】PM的能力

• 学习能力
• 观察理解能力
• 分析管理能力
• 销售能力
• 交流能力，处理冲突的能力
• 一定的专业能力
• 自省的能力

【2】PM的任务

• 带领团队形成团队的目标/远景，把抽象的目标转化为可执行的、具体的、优美的设计
• 管理软件的具体功能的生命周期
• 创建并维护软件的规格说明书，让它成为开发/测试人员及时准确的指导，而不是障碍。
• 代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各种需求的优先级
• 分析并带领其他成员形成对缺陷/变更需求的一致意见，并确保实施。
• 带领其他成员确保项目保持功能/时间/资源的合理平衡，跟踪项目进展，确保团队发布让客户满意的软件
• 收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中的优缺点，推动项目成员持续改进，从而提振士气。

第十章典型用户和场景

【1】软件功能说明书

• 定义好相关的概念
• 规范好一些假设
• 避免一些误解，界定一些边界条件
• 描述主流的用户/软件交互步骤
• 服务质量的说明

【2】技术说明书

• 抽象
• 内聚/耦合/模块化
• 信息隐藏和封装
• 界面和实现的分离
• 如何处理错误情况
• 程序模块对于运行环境、相关模块、输入输出参数有什么假设？这些假设和相关的人员验证过么？
• 应对变化的灵活性
• 对大量数据的处理能力，如果数据量增大，程序还能保持高的效率么？

第十一章软件设计与实现

【1】每日构建

每一个公司的形式不同

【2】A/B测试：为同一个目标制定两个方案，让一部分用户使用A方案，另一部分用户使用B方案，记录用户的使用情况，看哪个方案更符合设计。

第十二章用户体验

【1】参考书籍

http://www.cnblogs.com/xt0810/p/4662861.html

【2】用户体验的原则

• 仅提供可感触的反馈
• 系统界面符合用户的实现惯例
• 用户有自由控制权
• 一致性和标准化
• 适合各种类型的用户
• 帮助用户识别、诊断并修复错误
• 有必要的提示和帮助文档

第十三章软件测试

【1】测试与开发并重

【2】测试文档

第十四章质量保障

【1】软件工程的质量体现：

• 软件开发过程的可见性
• 软件过程的风险控制
• 软件内部模块，项目中间阶段的交付质量，项目管理工具的因素
• 软件开发成本的控制
• 内部质量指标的完成情况

第十五章稳定和发布阶段

【1】事后诸葛亮会议

第十六章IT行业创新

第十七章人，绩效和职业道德

成本：

时间成本：持续时间：一个月，集中时间：5天。

结束语：

前段时间思考自己，惊喜的发现邹老师和周老师对于我的思考进行了指导，在此不甚感激。

下本书计划：