构建之法 读书笔记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)。

 

个人总结:

通过对本书的拜读,我了解到了代码的测试和团队合作的基本方式,发现最近我们的合作方式很有问题,急需解决。

在编写代码的时候要进行单元测试,保证代码的健壮性。

 

总结来源

原文地址:https://www.cnblogs.com/cxy0210/p/12576956.html