肯特·贝克：改变人生的代码整理魔法
==========

> 本文作者<ruby>肯特·贝克<rt>Kent Beck</rt></ruby>，是最早研究软件开发的模式和重构的人之一，是敏捷开发的开创者之一，更是极限编程和测试驱动开发的创始人，同时还是 Smalltalk 和 JUnit 的作者，对当今世界的软件开发影响深远。现在 Facebook 工作。

本周我一直在整理 Facebook 代码，而且我喜欢这个工作。我的职业生涯中已经整理了数千小时的代码，我有一套使这种整理更加安全、有趣和高效的规则。

整理工作是通过一系列短小而安全的步骤进行的。事实上，规则一就是**如果这很难，那就不要去做**。我以前在晚上做填字游戏。如果我卡住那就去睡觉，第二天晚上那些没有发现的线索往往很容易发现。与其想要一心搞个大的，不如在遇到阻力的时候停下来。

整理会陷入这样一种感觉：你错失的要比你从一个个成功中获得的更多（稍后会细说）。第二条规则是**当你充满活力时开始，当你累了时停下来**。起来走走。如果还没有恢复精神，那这一天的工作就算做完了。

只有在仔细追踪其它变化的时候（我把它和最新的差异搞混了），整理工作才可以与开发同步进行。第三条规则是**立即完成每个环节的工作**。与功能开发所不同的是，功能开发只有在完成一大块工作时才有意义，而整理是基于时间一点点完成的。

整理在任何步骤中都只需要付出不多的努力，所以我会在任何步骤遇到麻烦的时候放弃。所以，规则四是**两次失败后恢复**。如果我整理代码，运行测试，并遇到测试失败，那么我会立即修复它。如果我修复失败，我会立即恢复到上次已知最好的状态。

即便没有闪亮的新设计的愿景，整理也是有用的。不过，有时候我想看看事情会如何发展，所以第五条就是**实践**。执行一系列的整理和还原。第二次将更快，你会更加熟悉避免哪些坑。

只有在附带损害的风险较低，审查整理变化的成本也较低的时候整理才有用。规则六是**隔离整理**。如果你错过了在编写代码中途整理的机会，那么接下来可能很困难。要么完成并接着整理，要么还原、整理并进行修改。

试试这些。将临时申明的变量移动到它第一次使用的位置，简化布尔表达式（`return expression == True`？），提取一个 helper，将逻辑或状态的范围缩小到实际使用的位置。

### 规则

- 规则一、 如果这很难，那就不要去做
- 规则二、 当你充满活力时开始，当你累了时停下来
- 规则三、 立即完成每个环节工作
- 规则四、 两次失败后恢复
- 规则五、 实践
- 规则六、 隔离整理

### 尾声

我通过严格地整理改变了架构、提取了框架。这种方式可以安全地做出重大改变。我认为这是因为，虽然每次整理的成本是不变的，但回报是指数级的，但我需要数据和模型来解释这个假说。

--------------------------------------------------------------------------------

via: https://www.facebook.com/notes/kent-beck/the-life-changing-magic-of-tidying-up-code/1544047022294823/

作者：[KENT BECK][a]
译者：[geekpi](https://github.com/geekpi)
校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

[a]:https://www.facebook.com/kentlbeck
[1]:https://www.facebook.com/notes/kent-beck/the-life-changing-magic-of-tidying-up-code/1544047022294823/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website#
[2]:https://www.facebook.com/kentlbeck
[3]:https://www.facebook.com/notes/kent-beck/the-life-changing-magic-of-tidying-up-code/1544047022294823/
