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/,转载请注明。