From 95d1007fb4a3048fbd3e716edb2ef698c6ba1989 Mon Sep 17 00:00:00 2001 From: wxy Date: Wed, 22 Nov 2017 15:27:08 +0800 Subject: [PATCH] PRF:20170608 The Life-Changing Magic of Tidying Up Code.md @geekpi --- ... Life-Changing Magic of Tidying Up Code.md | 44 ++++++++++++------- 1 file changed, 28 insertions(+), 16 deletions(-) diff --git a/translated/tech/20170608 The Life-Changing Magic of Tidying Up Code.md b/translated/tech/20170608 The Life-Changing Magic of Tidying Up Code.md index 0c726fd8ba..d9ef84a90a 100644 --- a/translated/tech/20170608 The Life-Changing Magic of Tidying Up Code.md +++ b/translated/tech/20170608 The Life-Changing Magic of Tidying Up Code.md @@ -1,32 +1,44 @@ -# 整理代码的变革魔力 +肯特·贝克：改变人生的代码整理魔法 +========== -本周我一直在整理 Facebook 代码并且喜欢上它。我职业生涯中已经整理了好几千小时的代码，并且我也有一些使这种整理安全、有趣和高效的规则。通过一系列小而安全的步骤整理项目。事实上，规则一如果很难做到，那么不要去做。我以前在晚上做填字游戏。如果我卡住然后去睡觉了，第二天晚上那些不可能的线索往往很容易。与其强调我想要创造的巨大影响，不如在遇到阻力的时候停下来。整理会陷入一种感觉你会因为错误失去的比你从一个个成功中获得的更多（稍后说更多）。第二条规则是当你充满活力时开始，当你累了时停下来。起来走走。如果我没有恢复精神，我一天的工作就完了。只有在仔细追踪其他变化的时候（我把它和最新的差异搞混了），整理工作可以才能与开发同步进行。第三条规则立即完成每个环节的工作。与功能开发不同的是，功能开发只有在完成一大块工作时才有意义，整理是基于时间的。整理在任何步骤只需要一点点努力，所以我会在任何步骤遇到麻烦的时候放弃。例如，规则四是两次失败后恢复。如果我整理，运行测试，并遇到一个失败的测试，那么我会立即修复它。如果我修复失败，我会立即恢复到已知的最好的状态。没有闪亮的新设计的愿景，整理也是有用的。不过，有时候我想看看事情会如何发展，所以第五条就是实践。执行一系列的整理和还原。第二次将更快，你会更加熟悉避免哪些坑。只有在附带损害的风险较低，审查整理变化的成本也较低的时候整理才有用。规则六是隔离整理。如果你错过了在编写代码中间整理的机会，那么接下来可能很困难。要么完成并接着整理，要么还原、整理并进行修改。试试吧。将临时申明的变量移动到第一次使用的附近。简化布尔表达式（“return expression == True”？）？提取一个 helper。将逻辑或状态的范围缩小到实际使用的位置。 +> 本文作者肯特·贝克Kent Beck，是最早研究软件开发的模式和重构的人之一，是敏捷开发的开创者之一，更是极限编程和测试驱动开发的创始人，同时还是 Smalltalk 和 JUnit 的作者，对当今世界的软件开发影响深远。现在 Facebook 工作。 + +本周我一直在整理 Facebook 代码，而且我喜欢这个工作。我的职业生涯中已经整理了数千小时的代码，我有一套使这种整理更加安全、有趣和高效的规则。 + +整理工作是通过一系列短小而安全的步骤进行的。事实上，规则一就是**如果这很难，那就不要去做**。我以前在晚上做填字游戏。如果我卡住那就去睡觉，第二天晚上那些没有发现的线索往往很容易发现。与其想要一心搞个大的，不如在遇到阻力的时候停下来。 + +整理会陷入这样一种感觉：你错失的要比你从一个个成功中获得的更多（稍后会细说）。第二条规则是**当你充满活力时开始，当你累了时停下来**。起来走走。如果还没有恢复精神，那这一天的工作就算做完了。 + +只有在仔细追踪其它变化的时候（我把它和最新的差异搞混了），整理工作才可以与开发同步进行。第三条规则是**立即完成每个环节的工作**。与功能开发所不同的是，功能开发只有在完成一大块工作时才有意义，而整理是基于时间一点点完成的。 + +整理在任何步骤中都只需要付出不多的努力，所以我会在任何步骤遇到麻烦的时候放弃。所以，规则四是**两次失败后恢复**。如果我整理代码，运行测试，并遇到测试失败，那么我会立即修复它。如果我修复失败，我会立即恢复到上次已知最好的状态。 + +即便没有闪亮的新设计的愿景，整理也是有用的。不过，有时候我想看看事情会如何发展，所以第五条就是**实践**。执行一系列的整理和还原。第二次将更快，你会更加熟悉避免哪些坑。 + +只有在附带损害的风险较低，审查整理变化的成本也较低的时候整理才有用。规则六是**隔离整理**。如果你错过了在编写代码中途整理的机会，那么接下来可能很困难。要么完成并接着整理，要么还原、整理并进行修改。 + +试试这些。将临时申明的变量移动到它第一次使用的位置，简化布尔表达式（`return expression == True`？），提取一个 helper，将逻辑或状态的范围缩小到实际使用的位置。 ### 规则 -1. 如果这很难，不要去做 - -2. 当你充满活力时开始，当你累了时停下来 - -3. 立即完成每个环节工作 - -4. 两次失败后恢复 - -5. 实践 - -6. 隔离整理 +- 规则一、 如果这很难，那就不要去做 +- 规则二、 当你充满活力时开始，当你累了时停下来 +- 规则三、 立即完成每个环节工作 +- 规则四、 两次失败后恢复 +- 规则五、 实践 +- 规则六、 隔离整理 ### 尾声 -我通过整理严格地改变了架构。我严格通过整理提取框架。这种方式可以安全地做出重大改变。我认为这是因为，虽然每次整理的成本是不变的，但回报是指数级的。我需要数据和模型来解释这个假设。 +我通过严格地整理改变了架构、提取了框架。这种方式可以安全地做出重大改变。我认为这是因为，虽然每次整理的成本是不变的，但回报是指数级的，但我需要数据和模型来解释这个假说。 -------------------------------------------------------------------------------- via: https://www.facebook.com/notes/kent-beck/the-life-changing-magic-of-tidying-up-code/1544047022294823/ -作者：[KENT BECK ][a] +作者：[KENT BECK][a] 译者：[geekpi](https://github.com/geekpi) -校对：[校对者ID](https://github.com/校对者ID) +校对：[wxy](https://github.com/wxy) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出