肯特·貝克:改變人生的代碼整理魔法
本文作者 肯特·貝克 ,是最早研究軟體開發的模式和重構的人之一,是敏捷開發的開創者之一,更是極限編程和測試驅動開發的創始人,同時還是 Smalltalk 和 JUnit 的作者,對當今世界的軟體開發影響深遠。現在 Facebook 工作。
本周我一直在整理 Facebook 代碼,而且我喜歡這個工作。我的職業生涯中已經整理了數千小時的代碼,我有一套使這種整理更加安全、有趣和高效的規則。
整理工作是通過一系列短小而安全的步驟進行的。事實上,規則一就是如果這很難,那就不要去做。我以前在晚上做填字遊戲。如果我卡住那就去睡覺,第二天晚上那些沒有發現的線索往往很容易發現。與其想要一心搞個大的,不如在遇到阻力的時候停下來。
整理會陷入這樣一種感覺:你錯失的要比你從一個個成功中獲得的更多(稍後會細說)。第二條規則是當你充滿活力時開始,當你累了時停下來。起來走走。如果還沒有恢復精神,那這一天的工作就算做完了。
只有在仔細追蹤其它變化的時候(我把它和最新的差異搞混了),整理工作才可以與開發同步進行。第三條規則是立即完成每個環節的工作。與功能開發所不同的是,功能開發只有在完成一大塊工作時才有意義,而整理是基於時間一點點完成的。
整理在任何步驟中都只需要付出不多的努力,所以我會在任何步驟遇到麻煩的時候放棄。所以,規則四是兩次失敗後恢復。如果我整理代碼,運行測試,並遇到測試失敗,那麼我會立即修復它。如果我修復失敗,我會立即恢復到上次已知最好的狀態。
即便沒有閃亮的新設計的願景,整理也是有用的。不過,有時候我想看看事情會如何發展,所以第五條就是實踐。執行一系列的整理和還原。第二次將更快,你會更加熟悉避免哪些坑。
只有在附帶損害的風險較低,審查整理變化的成本也較低的時候整理才有用。規則六是隔離整理。如果你錯過了在編寫代碼中途整理的機會,那麼接下來可能很困難。要麼完成並接著整理,要麼還原、整理並進行修改。
試試這些。將臨時申明的變數移動到它第一次使用的位置,簡化布爾表達式(return expression == True
?),提取一個 helper,將邏輯或狀態的範圍縮小到實際使用的位置。
規則
- 規則一、 如果這很難,那就不要去做
- 規則二、 當你充滿活力時開始,當你累了時停下來
- 規則三、 立即完成每個環節工作
- 規則四、 兩次失敗後恢復
- 規則五、 實踐
- 規則六、 隔離整理
尾聲
我通過嚴格地整理改變了架構、提取了框架。這種方式可以安全地做出重大改變。我認為這是因為,雖然每次整理的成本是不變的,但回報是指數級的,但我需要數據和模型來解釋這個假說。
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive