《构建之法》读书笔记二

第四章两人合作：代码规范、极限编程、结对编程、两人合作的不同阶段、影响其他人的技巧。代码规范分为代码风格规范、代码设计规范。代码风格规范中缩进一般4个空格；行宽限定100个字符；善于运用括号；断行与空白{}行使用规范；分行的使用格式；命名的规范；下划线_；大小写以及注释。代码设计规范有函数的应用；goto的应用；错误处理（参数处理，断言）；C++中类的使用，构造函数，析构函数，new和delete，运算符，异常，类型继承。代码复审（自我复审，同伴复审，团队复审）找出Bug.找出代码的错误：编码错误和规范问题（发现逻辑错误，发现算法错误，发现潜在的错误和回归性错误，发现可能需要改进的地方，教育(互相教育)开发人员，传授经验）。代码复审： 代码复审前；代码必须成功编译，在所有要求的平台程序员必须测试过代码 ； 程序要必须提供新的代码，以及文件差异分析工具。 复审者可以选择面对面的复审、独立复审或其他方式。 在面对面复审中，一般是开发者控制流程，讲述修改的前因后果。但是复审者有权在任何时候打断叙述，提供自己的意见。

代码复审中修改之后会不会影响别的功能；此类修改是不是只有这一块；说明是否明确；对于这样的修改，有没有别的成员需要告知；导致问题的根本原因是什么？如何以后自动避免问题再次出现？

代码复审后更正明显的错误；对于无法很快更正的错误，要在项目管理软件中创建Bug把他们记录下来；把所有的错误记载自己的一个“我常犯的错误“表中，作为以后自我复审的第一步;

结对编程：强调双方的共同点，从团队共同的愿景讲起，让双方觉得处于一个安全的环境。重于行为和后果这一层面。

 第五章团队和流程：软件团队的模式（一窝蜂模式—>主治医师模式—>明星模式—>业余剧团模式—>秘密团队—>特工团队—>交响乐团模式—>爵士乐模式—>功能团队模式—>官僚模式）开发流程（写了再改模式—>瀑布模型—>瀑布模式的变形（生鱼片模型，大瀑布带着小瀑布模型）—>RUP—>Boss-Driven Process—>Evolutionary Delivery,MVP和MBP）TSP原则

第六章敏捷流程：敏捷流程以及原则（找出完成产品需要做的事情—>决定当前冲刺需要解决的事情—>冲刺）。敏捷流程的问题以及解决方法：定义好任务究竟是什么；完成任务所需时间；然后一步步去验证。而一个敏捷的团队需要有自主管理，自我组织，多功能型。敏捷流程的经验教训：

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

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

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

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

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

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

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

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

敏捷不是万能的，敏捷的方法只能让你更早知道你是否能如期完成任务，可以帮助我们尽快让用户看到项目的部分价值。

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

第七章MSF：MSF基本原则

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

MSF过程模型

 

 

 

第八章需求分析

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

不同角度对于软件需求（对产品功能性需求，对产品开发过程需求，非功能性需求，综合需求）

软件产品的利益相关者（用户，顾客，市场分析者，监管机构，系统/应用集成商，软件团队，软件工程师）

获取用户需求——用户调研（焦点小组，深入面谈，卡片分析，用户调查问卷，人类学调查......）

三拍”——反例

拍脑袋

拍胸脯

拍屁股

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

 

	外围功能	杀手功能
必要需求	第二象限 建议采取“抵消”的办法，快速地达到“和别热差不多”，对于大家都特别看重的功能，采取“优化”的办法，达到行业最佳。	第一象限 建议采取“差异化”的办法，全力以赴投资在这个领域
辅助需求	第三象限 建议采取“维持”的办法，以最低代价维持此功能	第四象限（不是用户的刚需，而是辅助功能，但是我们有独特的办法做的更好） 建议采取“维持”的办法，或者现在“不做”等待好的时机。或者让部分人员做实验

计划和需求

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

 

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

第九章 项目经理

PM的能力

学习能力

观察理解能力

分析管理能力

销售能力

交流能力，处理冲突的能力

一定的专业能力

自省的能力

PM的任务

带领团队形成团队的目标/远景，把抽象的目标转化为可执行的、具体的、优美的设计

管理软件的具体功能的生命周期

创建并维护软件的规格说明书，让它成为开发/测试人员及时准确的指导，而不是障碍。

代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各种需求的优先级

分析并带领其他成员形成对缺陷/变更需求的一致意见，并确保实施。

带领其他成员确保项目保持功能/时间/资源的合理平衡，跟踪项目进展，确保团队发布让客户满意的软件

收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中的优缺点，推动项目成员持续改进，从而提振士气。

第十章典型用户和场景

软件功能说明书

定义好相关的概念

规范好一些假设

避免一些误解，界定一些边界条件

描述主流的用户/软件交互步骤

服务质量的说明

技术说明书

抽象

内聚/耦合/模块化

信息隐藏和封装

界面和实现的分离

如何处理错误情况

程序模块对于运行环境、相关模块、输入输出参数有什么假设？这些假设和相关的人员验证过么？

应对变化的灵活性

对大量数据的处理能力，如果数据量增大，程序还能保持高的效率么？

第十一章 软件设计与实现

图形建模和分析方法

思维导图、实体关系图、Use Case Diagram

其他设计方法

形式化的方法、文学化编程

开发阶段的日常管理