商業論證

這個是在項目啟動階段考慮的問題，所有的項目開發的目標都為了實現一定的有價值的目標而存在的。再美好的過程，再高深的技術，再精英的團隊，開發出來的東西沒人用，沒產生價值，全部成了沈沒成本，最後只能成為談資而已。

 

時間、成本、質量

無論是系統還是功能開發，亦或者是二次開發，都要滿足一個基本原則，即在有限的時間，投入適當的成本，去完成既定的功能，即達到目標要求的質量。無論代碼寫的多麽漂亮，用的技術多麽高大上，最終都是在制約因素的限制下，實現既定的功能。質量是唯一不能妥協的因素。

權責統一

這個是在項目啟動階段要明確的事，一個團隊，一個項目組一定要明確誰是負責的人，誰應該對這個全局負責，明確權利和責任，是保障成功的關鍵。人人頭上有指標 人人肩上有責任。模糊的角色設定，往往在開發的過程中讓人捉襟見肘。

可持續性

日常開發和開源軟件的寫法還是有很大區別的。開源軟件只需要暴露接口，即實現什麽功能，調用什麽方法就可以了。使用者很少去關心裏面的實現邏輯，打開軟件的源碼，你會發現有些地方也是一大坨一大坨的，如果業務代碼也寫成這樣，基本上後面很難保證不出問題。

日常開發則不是，你自己寫的項目，是需要隨著項目的使用周期，功能叠代需要無數次的修改。所以，註釋，清晰的邏輯是十分重要。如果你的代碼只是自己比較清楚，邏輯高度壓縮，那麽估計只能自己維護了，因為別人看不懂。這也是為啥背鍋的總是離職人員的原因了。

在一個生命周期比較長的開發中，你是否考慮過產品的擴容，DB的縮容。是否能在現在的基礎上，逐步升級你的系統。還是等到山前的時候，才去考慮方案？

文檔

文檔是對業務的說明，產品文檔，技術文檔一定要寫。開發人員大多數不願意寫文檔，其實這是不對的。
代碼源於產品邏輯，而清晰的代碼又可以總結出業務流，數據流。文檔書寫需要遵循幾個宗旨。

1. 清晰，文檔一定要清晰，主要目標是告訴他人這是什麽，怎麽用等內容，所以一定要清晰的表達出自己的意思。
2. 安全，文檔一定要安全，安全的意思是，文檔的服務器一定不要是臨時的，自己搭建的。是有人在維護的，這樣可以避免人員流失引起文檔斷更的尷尬。

每個角色都應該不斷的總結，整理歸納。

人生不只有true或false

世界是豐富多彩的，我在定義變量時很少定義成true/false, 這個習慣不太好。不過我有我自己的想法，總在一些場景的時候考慮，如果來了第三種情況怎麽辦。結果就定義成了0和1，如果來了擴展第三種情況，就加個2即可。

代碼也是如此，要考慮到有第三種情況。是加case。
 

先寫到這裏吧。

一些系統設計和系統開發的感悟