构建之法 读书笔记01
这次主要阅读的是1到6章
软件=程序+软件工程:正是因为对软件开发活动（构建管理、源代码管理、软件设计、软件测试、项目管理）相关的内容的完成，才能完成把整个程序转化成为一个可用的软件的过程。
软件企业=软件+商业模式
单元测试:有效解决程序员对模块功能的误解、疏忽或不了解模块的变化之类的问题，使自己负责的模块功能定义尽量明确，模块的质量得到稳定的、量化的保证。
好的单元测试的标准：
在最基本的功能/参数上验证程序的正确性
单元测试必须由最熟悉代码的人（程序的作者来写）
单元测试过后，机器的状态保持不变
单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）
单元测试应该产生可重复、一致的结果
独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性
单元测试应该覆盖所有代码路径
单元测试应该集成到自动测试的框架中
单元测试必须和产品代码一起保存和维护
代码风格原则：简明、易读、无二异性
缩进：4个空格，而不是TAB
行宽：限定为100字符
括号
断行与空白的{}行
分行
命名：匈牙利命名法
下划线：分隔变量名字中的作用域标注和变量语义
大小写（Pascal形式和Camel形式）
注释
函数：只做一件事，并且要做好
goto：有助于程序逻辑的清晰体现
错误处理：参数处理、断言
类的处理
①形式：自我复审、同伴复审、团队复审
②目的：找出代码错误、发现逻辑错误、发现算法错误、发现潜在的错误和回归性错误、发现可能需要改进的地方、传授经验
③代码复审后把记录整理出来：
（1）更正明显的错误
（2）记录无法很快更正的错误
（3）把所有的错误记在自己的一个“我常犯的错误”表中，作为以后自我复审的第一步
结对编程:
①角色：
驾驶员：控制键盘输入
领航员：起到领航、提醒的作用
②好处：（1）在开发层次，可以提供更好的设计质量和代码质量，两人合作解决问题的能力更强。
（2）对开发人员，带来更多的信心，高质量的产出带来更高的满足感。
（3）企业管理层次上，有效地交流，相互学习和传递经验，分享知识，取得更高的投入产出比。
①敏捷开发原则：
（1）尽早并持续地交付有价值的软件以满足顾客需求
（2）敏捷流程欢迎需求的变化，并利用这些变化来提高用户的竞争优势
（3）经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
（4）业务人员和开发人员在项目开发过程中应该每天共同工作
（5）以有进取心的人为项目核心，充分支持信任他们
（6）无论团队内外，面对面的交流始终是最有效的沟通方式
（7）可用的软件是衡量项目进展的主要指标
（8）敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
（9）只有不断关注技术和设计，才能越来越敏捷
（10）保持简明——尽可能简化工作量的技艺
（11）只有能自我管理的团队才能创造优秀的架构、需求和设计
（12）时时总结如何提高团队效率并付诸行动
②敏捷流程概述：找出完成产品需要做的事情→决定当前的冲刺（Sprint）需要解决的事情→冲刺（冲刺期间每天开每日例会）→得到软件的一个增量版本并发布
敏捷的团队
自主管理：自己挑选任务、自己提出改进并实施改进
自我组织：每个人联合起来对项目负责
多功能型：每个人都全面负责，自己搞定规格说明书，和别人沟通，自己搞定测试
在迭代开始时，团队审视摆在他们面前的任务，选择他们认为可以在迭代期间完成的那些任务（Plan）。然后团队独立地尽最大努力完成这些任务（Do）。在迭代结束时，团队给利益关系人展示成果（Check），并对开发流程进行调整（Act/Adjust）。
个人总结：
通过对本书的拜读，我了解到了代码的测试和团队合作的基本方式，发现最近我们的合作方式很有问题，急需解决。
在编写代码的时候要进行单元测试，保证代码的健壮性。
