mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
translated
This commit is contained in:
geekpi
parent
4fef38fbe3
commit
ac9235be0c
@ -1,38 +0,0 @@
|
||||
translating---geekpi
|
||||
|
||||
# The Life-Changing Magic of Tidying Up Code
|
||||
|
||||
I have been tidying up Facebook code this week and loving it. I’ve tidied up for thousands of hours over my career, and I have some rules for making this style of cleanup safe, fun, and efficient.Tidying up works through a series of small, safe steps. In fact, Rule #1 is If it’s hard, don’t do it. I used to do crossword puzzles at night. If I got stuck and went to sleep, the next night those same impossible clues were often easy. Instead of stressing about the big effects I want to create, I am better off just stopping when I encounter resistance.Tidying up is concave in the sense that you have a lot more to lose by a mistake than you have to win by any individual success (more on that later). Rule #2 is Start when you’re fresh and stop when you’re tired. Get up and walk around. If I don’t come back refreshed, I’m done for the day.Tidying up can happen in parallel with development, but only if you carefully track other changes (I messed this up with my latest diff). Rule #3 is Land each session’s work immediately. Unlike feature development, where it sometimes makes sense to land only when a chunk of work is done, tidying up is time based.Tidying up requires little effort for any step, so I am willing to discard any step at the first sign of trouble. For example, Rule #4 is Two reds is a revert. If I tidy, run the tests, and encounter a failed test, then if I can fix it immediately I do. If I try to fix it and fail, I immediately revert to the last known good state.Tidying up works even without a vision of the shiny new design. However, sometimes I want to see how things might play out, so Rule #5 is Practice. Perform a sequence of tidyings and revert. The second time will go much faster and you’ll be more familiar with which bumpy spots to avoid.Tidying up works only if the risk of collateral damage is low and the cost of reviewing tidying changes is also low. Rule #6 is Isolate tidying. This can be tough when you run across the chance to tidy in the midst of writing new code. Either finish and then tidy or revert, tidy, and make your changes.Try it. Move the declaration of a temp adjacent to its first use. Simplify a boolean expression (“return expression == True” anyone?). Extract a helper. Reduce the scope of logic or state to where it is actually used.
|
||||
|
||||
### The Rules
|
||||
|
||||
1. If it’s hard, don’t do it
|
||||
|
||||
2. Start when you’re fresh and stop when you’re tired
|
||||
|
||||
3. Land each session’s work immediately
|
||||
|
||||
4. Two reds is a revert
|
||||
|
||||
5. Practice
|
||||
|
||||
6. Isolate tidying
|
||||
|
||||
### Coda
|
||||
|
||||
I’ve made architectural changes strictly by tidying. I’ve extracted frameworks strictly by tidying. You can make big changes safely in this style. I think this is because, while the cost of each tidying is constant, the payoff is power-law distributed. I need both data and a model to explain this hypothesis.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.facebook.com/notes/kent-beck/the-life-changing-magic-of-tidying-up-code/1544047022294823/
|
||||
|
||||
作者：[KENT BECK ][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [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/
|
||||
@ -0,0 +1,36 @@
|
||||
# 整理代码的变革魔力
|
||||
|
||||
本周我一直在整理 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]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [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/
|
||||
Loading…
Reference in New Issue
Block a user