《程序员修炼之道》笔记(八)

第八章 注重实效的项目

随着你的项目开动,我们需要从个体的哲学和编码问题转向讨论更大的、项目级的问题。我们将不深入项目管理的具体细节,而是要讨论能使项目成功或失败的几个关键区域。

 

1. 注重实效的团队

书中前面的内容都是帮助个体成为更好的程序员,这些方法在对团队来说仍然有效。

a) 不要留破窗户。质量是一个团队的问题。最勤勉的开发者如果被派到不在乎质量的团队里,也会发现自己很难保持修正琐碎问题所需的热情。团队作为一个整体,不应该容忍破窗户——那些小小的、无人修正的不完美。

 

b) 煮青蛙。在项目开发高涨的热度里,很难再用一只眼睛注意周围的环境,所以作为整体的团队甚至更容易被煮熟。即使是目的最明确的团队对项目中的重大改动可能也会很健忘。团队每个人都应该主动监视环境的变化,也可以指定专人负责检查范围的扩大、时间标度的缩减、新增特性、新环境之类任何不在最初约定中的东西。

 

c) 交流。对外界而言,沉闷寡言、文档混乱的团队是糟糕的团队。而杰出的团队有着截然不同的个性,他们制作的文档准确、一致,团队用一个声音说话,甚至还可能有幽默感。可以使用一个营销的诀窍,来帮助团队作为整体与外界交流:创立品牌。在启动项目时,给它取一个不寻常的名字,这会给团队一个用于建设的身份标识。

 

d) DRY。交流有助于消除团队间的重复,此外可以安排项目成员分工担任项目不同部分的资料管理员(比如数据库schema、日期处理等)。

 

e) 正交性。要围绕功能、而不是工作职务组织小团队,这些小团队分别负责最终系统的特定方面的功能,每个团队都按照他们约定的承诺,对项目中的其他团队负有责任。这种分组方式能够极大地减少各个开发者的工作之间的相互影响。但是这种方法只有在项目拥有负责的开发者、以及强有力的项目管理时才会有效。

 

f) 自动化。自动化可以确保团队所做的每件事情一致、准确。编辑器为代码自动布局、夜间自动构建测试,这些都是很好地方式。自动化是每个项目团队的必要组成部分。

 

g) 知道何时停止绘画。团队由个体组成,要给他们足够的能够闪亮的空间,以支持他们,同时要把握足够好的软件,抵抗不断画下去的诱惑,确保项目的交付能够符合需求。

 


 

 

2. 无情的测试

a) 早测试、常测试,自动测试。寻找bug有点像是用网捕鱼。我们用纤小的网(单元测试)捕捉小鱼,用粗大的网(集成测试)来捕捉大鱼。有时鱼会设法逃跑,所以为了抓住在我们项目池塘里游动的、越来越狡猾的缺陷,要补上我们发现的任何漏洞。

 

与手动执行的测试计划相比,随每次构建运行的测试要有效的多。

 

Bug发现得越早,进行修补的成本就越低。要“编一点,测一点”,在编写产品代码的同时编写测试代码。

 

只有通过全部测试,编码才算完成。好的项目拥有的测试代码可能比产品代码还要多。但编写这些测试代码所花的时间是值得的。长远来看,它最后会便宜得多,而你有希望制作出接近零缺陷的产品。此外,通过了所有测试将给你高度的自信:一段代码已经“完成”了。

 

项目范围测试的三个方面:测试什么、怎样测试、何时测试

 

b) 测试什么

单元测试,这是所有其它形式测试的基础。所有模块都必须通过单元测试,才能继续前进。

 

集成测试,用来验证项目的主要子系统能否工作,并很好地协同。是单元测试的一种扩展,测试整个子系统是否遵守其合约。

 

验证和校验。就算没有bug,但回答的问题本身是错误的,这样的系统也不会有用。需要校验回答一个重要的问题是:这是用户需要的吗?要注意用户的访问模式与开发者所用测试数据的不同。

 

资源耗尽、错误及恢复。虽然在理想的条件下软件会正常运行,但在现实运行环境下,还有内存、磁盘空间、CPU带宽、网络带宽、屏幕分辨率等种种限制。

 

性能测试、压力测试或负载测试有时也很有必要,要测试软件能够满足现实条件下的性能需求,如预期的用户数、连接数、每秒事务数、可伸缩性。有时需要用专门模拟现实环境进行测试。

 

可用性测试。可用性测试是由真正的用户、在真实的环境条件下进行的。软件最好能像是手的延伸一样顺手。可用性测试也要尽早进行,以保证有时间更正,否则没能满足可用性标准就像是除零错误,是重大bug。

 

c) 怎样测试

回归测试,把当前测试的输出与先前或已知的值进行对比,以确定今天对bug的修复没有破坏昨天可以工作的代码。性能、合约、有效性能等都可以进行回归测试。

 

测试数据。数据分为两种,现实世界的数据和合成的数据。

现实世界的数据代表典型的用户数据,有助于揭示出需求分析中的缺陷和误解。

合成数据在需要大量数据、需要测试边界条件、展示特定统计属性时很有用。

 

演练GUI系统。对于涉及到GUI的部分,你的设计应该足够地解耦,以使你无需使用GUI就能对应用逻辑进行测试。从这一点来看,Winform那种界面与代码的组合方式是不好的。

 

彻底测试。衡量测试的覆盖率不能单单只从代码行的覆盖情况,尤其是对于循环、迭代之类的代码。重要的是程序可能具有的状态数。而且即使具有良好的代码覆盖,测试数据、遍历代码的次序对结果也有重大影响。

 

d) 何时进行测试。任何产品代码一旦存在,就需要进行测试。大多数测试应该自动完成,并尽可能地频繁测试,

 

e) 一个bug只抓一次。bug一旦被发现,就应该是最后一次被发现,应该对自动化测试进行修改,从此每次都检查那个特定的bug,不存在例外,不要觉得它不会再次发生。

 

posted @ 2017-05-07 21:34  zhixin9001  阅读(215)  评论(0编辑  收藏  举报