Make it run, make it right, make it fast

01-25

如果問我工作十多年後相比剛畢業參加的時候，學到了哪些重要的經驗，那麼「Make it work, make it right, make it fast」一定是其中最重要的經驗之一。第一次聽到這句話是從以前老闆 @沈嶸那裡，然後發現是來源自大牛 Kent Beck 《Make It Work Make It Right Make It Fast》。這是軟體項目開發的一條經典原則，實際上不限於軟體開發領域，它把一個項目分成三個階段，每個階段有不同的側重。

Make it work

在這個階段，了解項目需求後，聚焦於項目所需要的最小需求，儘快讓項目先跑起來，不必過於追求設計和性能。同時，展示你的結果，並根據反饋快速調整。

這個階段的重點在於需求的響應，以最快的速度實現需求。這是個快速試錯，快速迭代，驗證需求的過程。

Make it right

到了這個階段，需求基本上已經穩定，要保證項目執行結果正確，更多的測試，儘可能少的bug。但"Make it right"並不僅僅意味著只要結果正確就夠了，還需要對系統進行重構，優化系統設計，讓代碼更簡潔結構更清晰，易於擴展和維護。

這個階段的重點在於保障系統的穩定，同時優化設計和重構。

Make it fast

當系統已經穩定，設計也趨於成熟的時候，還需要對系統進行性能上的優化，良好的性能，不僅可以提升用戶體驗，同時也能降低運維的成本。這裡的「fast」，不僅體現在程序的性能，也包括對整體項目流程效率的提升，例如自動編譯、自動部署的工具或腳本，如果前期沒有做，那麼這時候就要加上了。

這個階段的重點在於系統的性能優化，包括項目流程效率的優化。

常見誤區

「Make it work, make it right, make it fast」這個原則拆開來很好理解，但這三個階段不是孤立的，而是一個整體，同時又是有先後次序的。

在我初學編程的時候，要達到Make it work也並不是太難的事情，網上找些開源項目，參考書上的教程，總能把一個不算太複雜的項目搭出來，但卻沒有能力去make it right，更沒有辦法去make it fast。最終的結果就是做出來的項目難以維護，性能低下。

在我學了一段時間編程後，懂了一些設計模式，了解了一些性能優化的辦法，於是開始直接省略第一步，首先考慮的是「Make it fast」，假想系統有超大用戶超大訪問量，然後考慮的是「Make it right」，設計的時候為了設計模式而設計模式，恨不得把所有設計模式應用個遍，最後再想著"Make it work"，但這時候因為前期的過度設計，系統複雜而臃腫，要讓它work，簡直是太難了，最終就是開發頻繁延期，甚至難產，做出來的程序也難以維護。

經過這麼多年的磨鍊，現在大到項目，小到具體功能，在每個版本都會儘可能的按照這個原則來實行：

Make it work: 首先最低限度滿足項目需求，將初步結果拿出來演示，根據反饋快速調整
Make it right: 需求穩定後，對代碼進行重構，良好的設計，易於維護和擴展
Make it fast: 設計穩定後，對實際運行情況中出現的性能問題進行優化

經歷這些階段後，項目的進度和質量都會有一個比較好的結果。