肯特·貝克：改變人生的代碼整理魔法

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

本文作者肯特·貝克Kent Beck，是最早研究軟體開發的模式和重構的人之一，是敏捷開發的開創者之一，更是極限編程和測試驅動開發的創始人，同時還是 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 譯者：geekpi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出