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