41、注重实效的团队
成为注重实效的个体有好处,但如果个体是在注重实效的团队中工作,这些好处就会成倍增长。把注重实效的技术应用于作为整体的团队,一旦你有了一组注重实效的开发者,让他们工作在能够发挥自身能力的环境中,他们很快就会发展并提炼他们自己的、有效的团队动力机制。
不要留破窗户
质量是一个团队问题,最勤勉的开发者在不在乎质量的团队里,会发现自己很难保持修正琐碎问题所需要的热情。如果团队主动鼓励不要花费时间在这样的修正上,问题就会进一步恶化。
团队作为一个整体,不应该容忍破窗户,团队必须为产品的质量负责,支持那些了解“不要留破窗户”哲学的开发者,并鼓励那些还不了解这种哲学的人。
质量只可能源于全体团队成员都作出自己的贡献,无法把保证产品质量的责任委派给“质量官员”。
煮青蛙
作为整体的团队甚至比“青蛙”更容易煮熟,大家认为,另外有人在处理某个问题,或是团队领导一定批准了用户要求作出的某项改动。即使是目的最明确的团队对项目中的重大改动可能也会很健忘。
确保每个人都主动地监视环境的变化,指定一个人,持续的检查范围的扩大,时间标度的缩减、新增特性、新环境–任何不在最初的约定中的东西。对新需求进行持续的度量。
交流
看上去沉默寡言的项目团队是最糟糕的团队。他们举行无章次的会议,会上没有人想说话,他们的文档混乱,没有两位相同外观的文档,每一份都使用不同的术语。
杰出的项目团队有着截然不同的个性,人们希望他们一同开会,因为他们知道自己将看到准备良好,会让每个人都感到愉快的演出。他们制作的文档新鲜、准确、一致。团队用一个声音说话,甚至还可能有幽默感。
不要重复你自己
重复会造成工作的浪费,并且可能会带来维护的噩梦。指定某个成员单人项目资料管理员,负责协调文档和代码仓库,其他成员在查找资料时,首先找这个人。当项目对一个资料管理员太大时,可以指定多人负责工作的各个方面。
正交性
围绕功能、而不是工作职务进行组织
这里的功能并不必然意味着最终用户的用例,数据库访问层是功能,帮助子系统也是功能。
按功能组织有助于使团队作为整体与变化的各种效应隔离开来。能够极大的减少各个开发者的工作之间的相互影响、缩短时间标度、提高质量、并减少缺陷数目。
自动化
确保一直和准确的一种很好的方式是使团队所做的每件事情自动化。指定一个或多个团队成员担任工具构建员,构造和部署使项目中的苦差事自动化的工具。
知道合适停止绘画
团队是由个体组成的,让每个成员都能以他们自己的方式闪亮,给他们足够的空间,以支持他们并确保项目的交互能够符合需求。然后,要抵制“足够好的软件”中的画家不断画下去的诱惑。
42、无处不在的自动化
无论是构建和发布流程,是书面的代码复查工作、还是其他任何在项目中反复出现的任务,都必须是自动的。人工流程不能保证一致性,也无法俺保证可重复性,特别是在不同的人对流程的哥哥方面有不同的解释时。
一切都要自动化
不要使用手工流程
人的可重复性并不像计算机那么好。我们也不应期望他们能那样。shell脚本或批处理能以相同的次序、反复执行同样的命令,他们能被置于源码控制之下,你因而也可以检查流程的修改历史。
使用cron ,我们可以自动安排备份,夜间构建、网站维护,以及其他任何可以无人照管的完成的事情。
项目编译
项目编译是一件应该可靠、可重复地进行的琐碎工作,我们通常通过makefile编译项目,可以增加挂钩,让其为我们生成代码,并自动运行回归测试。
构建自动化
典型情况下,项目构建包含以下几个步骤:
- 从仓库中迁出源码
- 从头开始构建项目
- 创建可分发映像
- 运行规定的测试
对于大多数项目,这一层面的构建是在每天夜间自动运行的。在典型情况下,与在构建的项目的某个具体部分时运行的测试相比,这样的夜间构建中运行的测试要更完整。
你想要作为产品发现的最终构建,可能具有与常规的夜间构建不同的需求,最终构建可能要求锁住仓库,或是标上发布号,要求设置不同的优化和调试模式。
自动化管理
我们可以运行脚本,让它们基于源码和文档的内容,自动为我们完成各种流程。我们的目标是维持自动、无人照管、内容驱动的工作流。
让计算机去做重复、庸常的事情,它会做的比我们更好,我们有更重要、更困难的事情要做。
43、无情的测试
寻找bug有点像用网(单元测试)捕捉小鱼,用粗大的网(集成测试)捕捉吃人的鲨鱼。
早测试、常测试、自动测试
一旦我们有了代码,我们就想开始进行测试。使用自动测试的团队成功的机会要大得多。
bug被发现的越早,进行修补的成本越低。好的项目拥有的测试代码可能比产品代码还要多。
要通过全部测试,编码才算完成
你写出了一段代码,并不意味着你可以告诉你的老板或客户,说它已经完成,代码从不会真正完成,在它通过所有可用的测试之前,你不能声称它已经可供使用。
测试什么?
- 单元测试
- 集成测试
- 验证和效验
- 资源耗尽、错误及恢复
- 性能测试
- 可用性测试
怎样测试
- 回归测试
- 测试数据
- 演练GUI系统
- 对测试进行测试
- 彻底测试
何时进行测试
大多数测试都应该自动完成,尽可能频繁的进行测试,并且总是在我们把代码嵌入源码仓库之前,有些源码控制系统可用自动完成这一工作。
有些测试不容易那么频繁的运行,可以每周或者每月一次。
把网收紧
有bug漏过了现有测试网,你需要增加新的测试,以在下一次抓住它。
44、全都是写
应把文档作为整个开发过程的完整组成部分加以接受。不进行重复劳动,不浪费时间,并且把文档放在手边,就放在代码当中。
把英语当做又一种编程语言
把文档建在里面,不要栓在外面
代码中的注释
根据源码中的注释和声明产生格式化文档相当直接了当,但首先外面必须确保在代码中确实有注释。代码中应该有注释,但太多的注释可能和太少一样糟。
一般而言,注释应该讨论为何要做某事,他的目的和目标。代码已经说明了它是怎样完成的,再为此加上注释就是多余的,且违反DRY原则。
我们喜欢看到简单的模块级头注释、关于重要数据与类型声明的注释、以及给每个类和每个方法所加的简要头注释,用以描述函数的用法和任何不明了的事情。
不应该出现在源码中的注释内容:
- 文件中的代码导出的函数的列表
- 修订历史
- 该文件使用的其他文件的列表
- 文件名
可执行文档
如果你的文档是带有标记命令的纯文本,可以使用工具自动提取schema,并重新对其进行格式化。
使用像JavaDoc的工具,可以根据源码生成API级的文档。
打印还是编排
设法把文档制作成能够在web上在线发布的形式,用超链接整合在一起,使文档保持最小。
45、极大的期望
现实中,项目的成功是由它在多大程度上满足了用户的期望来衡量的,不符合用户期望的项目注定是失败的。
温和的超出用户的期望
交流期望
和用户一同工作,达成对开发过程和最终产品,以及他们尚未描述出来的期望的共同理解。
额外的一英里
给用户的东西要比他们期望的多一点,让用户高兴。
46、傲慢与偏见
在你的作品上签名
过去时代的手艺人,为能在他们的作品上签名而自豪,你也应该如此。你的签名应该被视为质量的保证,当人们在一段代码上看到你的名字时,应该期望它是可靠的,用心编写的,测试过的和有文档的,一个真正专业的作品,由真正专业人员编写。
更多有关《程序员修炼之道》的读书笔记,请关注 :
http://tabalt.net/blog/the-pragmatic-programmer-reading-notes/
本文链接:http://tabalt.net/blog/tpp-pragmatic-projects/,转载请注明。
