Dropbox 的 iOS 应用中的每一行代码，都是开始于被添加到 Maniphest 中的一个 bug 或者功能任务，Maniphest 是我们的任务管理系统。当一位工程师在上面接受一个任务，那么在开始写代码前相应的责任就已经赋予他。Phabricator 这个平台包含了我们的代码审查工具，这个代码审查工具有很多很好的功能，但它在评估对象之间的相互协作上不是做的很好。为了弥补这点，我们的工程师在开始他们的工作之前需要知道审查他们的任务的人是谁[1]。对于被审查代码的工程师来说，这样能确保在他们的团队中有一个橡皮鸭，这个橡皮鸭知道项目中一些改动代码的背景和原因，并且对代码的设计决策上起到协助的作用。对于审查者来说，这有助于他们将一些变化考虑进他们的开发周期评估中，这样有助于开发周期评估的准确。如果不出意外的话，我们的经验会告诉我们提前做好计划可以有效地避免审查代码过程中的重复劳动。针对项目中的变化做计划可以像在白板前做交流一样简单，也可以像写一篇建设性文档一样深入。这都取决于我们自己的选择。
[1] 我的团队中每个人都要审查代码。新来的同事在可以独立审查较大的任务之前，会先被分配一些比较少的代码量。
随着任务的展开，工程师需要一直谨记我们的代码规范。这个规范是一个最佳实践和一致规范的大融合，它的存在使我们不用去猜测我们应该怎样编码，也使审查变得更容易[2]。因为这是一个大项目，开发团队中没有一个人能对整个项目有完美的映射或理解。所以我们的工程师需要依赖团队中其他工程师的帮助，将这些代码的功能表现拼成一个整体，这有助与我们在阅读代码时能理解其中的逻辑。
[2] 即使这样，每当一个新成员加入时，总还是不免要展开一次关于使用 property 还是 ivar 的辩论。
当这个任务的工作进行到某个阶段时，我们的工程师很可能会做出一些明显不合理的或者不受欢迎的决定。捕获这个心理的最佳时间就是发生这一刻 — 为将来向审查者做好解释的准备。去解释这些变化，说起来容易做起来难，我们的工程师被鼓励使用//TODO，//HAX，和 //FIXME 来在代码中写注释。//TODO 和 //FIXME 从字面上就可以理解它的意义，尽管后者会产生编译警告，所以必须在下一次发布之前要被解决。//HAX 这个注释比较有趣的地方。我们用它标注那些用来绕过 Apple 的 API 里的 bug 但又不容易一眼看明白的方法[3]。我们的注释会写上日期和写这个注释人的名字[4]，在之后很多时候我们总会感激这些额外的上下文的[5]。
[3] 标注里通常是第三方来源或者 radar 的链接，还有特殊的重现步骤。
[4] 比如像 //HAX:(ashleynh) 2015-03-09