Make it run, make it right, make it fast

若是問我工做十多年後相比剛畢業參加的時候，學到了哪些重要的經驗，那麼「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: 設計穩定後，對實際運行狀況中出現的性能問題進行優化 經歷這些階段後，項目的進度和質量都會有一個比較好的結果。