构建之法阅读笔记01

第1章 概论
本章是全书的开篇，主要回答两个根本问题：软件到底是什么？软件工程又是什么？通过引入经典的"空姐与程序员对话"案例和航空安全的类比，阐明了软件工程学习的必要性和紧迫性。本章还讨论了软件企业的商业模式对软件需求的影响，并将计算机科学与软件工程进行了对比。
程序：算法 + 数据结构
软件工程：把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程
核心公式：软件 = 程序 + 软件工程
软件工程包含的领域
软件需求分析、软件设计、软件构建、软件测试和软件维护
软件工程的目标
研发出符合用户需求的软件
通过一定的软件流程，在预计的时间内发布"足够好"的软件
能证明所开发的软件是可以维护和继续发展的
第2章 个人技术和流程
本章聚焦于软件工程师个人层面的技术和流程管理。详细介绍了单元测试（包括回归测试、测试覆盖率）、效能分析工具的使用，以及个人软件过程（PSP）的框架。通过小飞学习单元测试的案例，展示了从零开始建立个人开发规范的完整过程。
单元测试（Unit Testing）
什么是Bug：软件的行为和用户的期望值不一样就叫Bug
单元测试框架：如Microsoft Visual Studio的测试工具
测试驱动开发（TDD）：先写测试，再写实现
回归测试：当代码修改后，重新运行之前的测试用例，确保没有引入新问题
测试覆盖率：路径覆盖 > 判断覆盖 > 语句覆盖
效能分析工具
抽样分析：快速定位耗时最多的函数
代码注入分析：了解函数调用次数和具体运行情况
关注占比超过50%的瓶颈函数进行优化
关键发现：
大学生在"设计复审"阶段花费时间明显少于职业工程师
职业工程师在"测试"阶段投入更多时间
文档和复审是大学生最容易忽视的环节
第3章 软件工程师的成长
本章探讨软件工程师如何衡量和提升个人能力。首先讨论了个人能力的衡量维度，然后深入分析了软件工程师常见的思维误区（如过早优化、过早泛化），最后介绍了职业发展的路径和自我评估方法。
初级软件工程师的成长方向
技术技能：编程语言、诊断技术、特定开发平台
领域知识：行业背景和经验（如游戏、医疗、金融）
软件设计思想：不是转发文章，也不是机械画UML图
职业技能：自我管理、表达交流、与人合作、按时执行
实际成果：用户评价、市场占有率、"行胜于言"
软件开发工作量和质量的衡量因素
项目有多大（LOC/功能点）
花了多少时间（人数×时间）
质量如何（缺陷数量）
TSP对团队成员的要求
交流：能有效沟通
说到做到：按时交付
接受团队赋予的角色
全力投入团队活动
按照团队流程工作
做好准备
理性工作：从事实和数据出发
微软职业等级
等级 要求
SDE（初级） 在学校学到技能，尚未充分锻炼
SDE II（中级） 独立，能写交给的任何东西
Senior SDE（高级） 影响3-12名工程师
Principal SDE（首席） 影响10人以上团队
第4章 两人合作
本章聚焦两人合作开发时的代码规范、代码设计规范、代码复审和结对编程。详细阐述了代码风格规范（缩进、命名、注释等）、代码复审的目的和流程、结对编程的实践技巧，以及反馈的三个层次。
代码风格规范
if-else格式：推荐每个{}独占一行
分行规范：不要把多条语句放在一行；不要把多个变量定义在一行
命名规范：变量名要有意义，避免无意义的缩写（如"ILoveFang"、"SB"）
代码设计规范
函数原则：只做一件事，并且要做好
goto的合理使用：有助于体现程序逻辑清晰性时可以使用
模块化设计：高内聚、低耦合
复审检查清单：
代码可读性
代码容易维护
代码每一行都执行并检查
设计是否遵从已知的设计模式
有没有硬编码
有没有无用的代码
边界条件处理
资源管理（内存、文件、连接）
效能问题
结对编程（Pair Programming）
驾驶员（Driver）：写设计文档，编码，单元测试
领航员（Navigator）：审阅文档，监督编码流程，思考重构，考虑测试覆盖率
角色轮换：每工作1小时休息15分钟，角色互换
平等原则：只有水平上的差距，没有级别上的差异
反馈的三个层次
最外层：行为和后果（可以改正）
中间层：习惯和动机（难以澄清）
最内层：本质和固有属性（无法改变）
第5章 团队和流程
本章从团队和流程的角度讨论软件开发。区分了"非团队"和真正的团队，介绍了多种团队模式（主治医师模式、明星模式、社区模式、官僚模式等），以及各种开发流程（瀑布模型、螺旋模型、RUP、MSF等）。
非团队 vs 团队
非团队：各自为政，缺乏共同目标
真正团队：有共同目标、相互负责、协同工作
开发流程模型
瀑布模型：线性顺序，各阶段严格区分
螺旋模型：风险分析为核心的迭代模型
Rational统一过程（RUP）：分阶段（初始、精化、构建、移交），设置里程碑
微软解决方案框架（MSF）：灵活适应变化
TSP的七条原则
使用妥善定义的流程
团队成员对目标、角色、产品有统一理解
尽量使用成熟的技术和做法
用数据帮助团队做出理性决定
制定切合实际的计划和承诺
增加团队的自我管理能力
专注于提高质量，争取在生命周期早期发现问题
第6章 敏捷流程
本章详细介绍敏捷软件开发方法，特别是Scrum框架。包括敏捷的核心价值观、Scrum的角色（Product Owner、Scrum Master、开发团队）、事件（Sprint、Daily Scrum、Sprint Review）和产物（Product Backlog、Sprint Backlog）。还讨论了敏捷实践中常见的问题和解决方法。
敏捷的核心价值观
个体和互动高于流程和工具
可用的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
敏捷团队的特点
自我管理（Self-managing）
自我组织（Self-organizing）
多功能型（Cross-functional）
敏捷与PDCA
Plan（计划）：Sprint开始时审视任务
Do（执行）：团队尽力完成任务
Check（检查）：展示成果
Act/Adjust（调整）：调整流程
这六章从个人到团队，从基础到进阶，体现了软件工程学习的递进关系。
核心收获
工程思维：软件开发不是"写代码"那么简单，而是一个系统工程
质量意识：测试、复审、流程都是保证质量的重要手段
协作能力：从两人合作到团队协作，沟通和反馈是关键
迭代改进：敏捷的核心理念——小步快跑，持续改进
知行合一：知道道理还不够，必须在实践中不断磨练
个人感受
我过去是怎么做的：
回想我之前在学校做课程设计和小项目的时候，往往是拿到题目就开始写代码。最开始会画一些流程图，但后来觉得太麻烦就省略了。写完代码后，简单运行几个例子测试一下，只要程序能跑出正确结果就算完成。
结合书中所讲，说明为什么这样不好：
书中明确指出"软件 = 程序 + 软件工程"，而我过去的做法恰恰只关注了"程序"部分，完全忽视了"软件工程"。书中提到的"空姐与程序员对话"案例让我印象深刻——程序员只会写代码，却不懂用户需求、不会沟通、不做测试。这样的"码农"在职场中注定会被淘汰。更糟糕的是，书中引用了软件工程奠基人瓦茨·汉弗雷的观点：软件领域90%-95%的工作都是工程工作（维护、测试、改善），只有5%-10%是创新工作。这彻底打破了我"只要技术好就能成功"的幻想。我现在的状态正是那90%部分完全没有训练过的写照。
提出一个解决办法，避免再次掉入陷阱：
从现在开始，每次编程任务都要遵循完整的流程：需求分析阶段用文字清楚写出"这个软件要做什么"；设计文档阶段画出主要模块和它们之间的关系；编码规范阶段统一变量命名、代码排版、注释规则；测试计划阶段列出要测试的边界条件和典型用例；事后总结阶段记录"哪里做得好，哪里可以改进"。