本文作者 肯特·贝克 ，是最早研究软件开发的模式和重构的人之一，是敏捷开发的开创者之一，更是极限编程和测试驱动开发的创始人，同时还是 Smalltalk 和 JUnit 的作者，对当今世界的软件开发影响深远。现在 Facebook 工作。
本周我一直在整理 Facebook 代码，而且我喜欢这个工作。我的职业生涯中已经整理了数千小时的代码，我有一套使这种整理更加安全、有趣和高效的规则。
整理工作是通过一系列短小而安全的步骤进行的。事实上，规则一就是如果这很难，那就不要去做。我以前在晚上做填字游戏。如果我卡住那就去睡觉，第二天晚上那些没有发现的线索往往很容易发现。与其想要一心搞个大的，不如在遇到阻力的时候停下来。
整理会陷入这样一种感觉：你错失的要比你从一个个成功中获得的更多（稍后会细说）。第二条规则是当你充满活力时开始，当你累了时停下来。起来走走。如果还没有恢复精神，那这一天的工作就算做完了。
只有在仔细追踪其它变化的时候（我把它和最新的差异搞混了），整理工作才可以与开发同步进行。第三条规则是立即完成每个环节的工作。与功能开发所不同的是，功能开发只有在完成一大块工作时才有意义，而整理是基于时间一点点完成的。
整理在任何步骤中都只需要付出不多的努力，所以我会在任何步骤遇到麻烦的时候放弃。所以，规则四是两次失败后恢复。如果我整理代码，运行测试，并遇到测试失败，那么我会立即修复它。如果我修复失败，我会立即恢复到上次已知最好的状态。
即便没有闪亮的新设计的愿景，整理也是有用的。不过，有时候我想看看事情会如何发展，所以第五条就是实践。执行一系列的整理和还原。第二次将更快，你会更加熟悉避免哪些坑。
只有在附带损害的风险较低，审查整理变化的成本也较低的时候整理才有用。规则六是隔离整理。如果你错过了在编写代码中途整理的机会，那么接下来可能很困难。要么完成并接着整理，要么还原、整理并进行修改。
试试这些。将临时申明的变量移动到它第一次使用的位置，简化布尔表达式（return expression == True？），提取一个 helper，将逻辑或状态的范围缩小到实际使用的位置。
规则
- 规则一、 如果这很难，那就不要去做
- 规则二、 当你充满活力时开始，当你累了时停下来
- 规则三、 立即完成每个环节工作
- 规则四、 两次失败后恢复
- 规则五、 实践
- 规则六、 隔离整理
尾声
我通过严格地整理改变了架构、提取了框架。这种方式可以安全地做出重大改变。我认为这是因为，虽然每次整理的成本是不变的，但回报是指数级的，但我需要数据和模型来解释这个假说。
发表回复