最近沒啥產出，心態不太好，想寫的很多，但博客更新的比較少。
今天談談系統設計的感悟吧（雖然也沒設計過NB的系統）。
做出一個系統和做功能是不同的，考慮的因素也不相同。相對來說，功能開發比較簡單，系統設計考慮的內容比較多。
商業論證
這個是在項目啓動階段考慮的問題，所有的項目開發的目標都爲了實現一定的有價值的目標而存在的。再美好的過程，再高深的技術，再精英的團隊，開發出來的東西沒人用，沒產生價值，全部成了沉沒成本，最後只能成爲談資而已。
時間、成本、質量
無論是系統還是功能開發，亦或者是二次開發，都要滿足一個基本原則，即在有限的時間，投入適當的成本，去完成既定的功能，即達到目標要求的質量。無論代碼寫的多麼漂亮，用的技術多麼高大上，最終都是在制約因素的限制下，實現既定的功能。質量是唯一不能妥協的因素。
權責統一
這個是在項目啓動階段要明確的事，一個團隊，一個項目組一定要明確誰是負責的人，誰應該對這個全局負責，明確權利和責任，是保障成功的關鍵。人人頭上有指標 人人肩上有責任。模糊的角色設定，往往在開發的過程中讓人捉襟見肘。
可持續性
日常開發和開源軟件的寫法還是有很大區別的。開源軟件只需要暴露接口，即實現什麼功能，調用什麼方法就可以了。使用者很少去關心裏面的實現邏輯，打開軟件的源碼，你會發現有些地方也是一大坨一大坨的，如果業務代碼也寫成這樣，基本上後面很難保證不出問題。
日常開發則不是，你自己寫的項目，是需要隨着項目的使用週期，功能迭代需要無數次的修改。所以，註釋，清晰的邏輯是十分重要。如果你的代碼只是自己比較清楚，邏輯高度壓縮，那麼估計只能自己維護了，因爲別人看不懂。這也是爲啥背鍋的總是離職人員的原因了。
在一個生命週期比較長的開發中，你是否考慮過產品的擴容，DB的縮容。是否能在現在的基礎上，逐步升級你的系統。還是等到山前的時候，纔去考慮方案？
文檔
文檔是對業務的說明，產品文檔，技術文檔一定要寫。開發人員大多數不願意寫文檔，其實這是不對的。
代碼源於產品邏輯，而清晰的代碼又可以總結出業務流，數據流。文檔書寫需要遵循幾個宗旨。
- 清晰，文檔一定要清晰，主要目標是告訴他人這是什麼，怎麼用等內容，所以一定要清晰的表達出自己的意思。
- 安全，文檔一定要安全，安全的意思是，文檔的服務器一定不要是臨時的，自己搭建的。是有人在維護的，這樣可以避免人員流失引起文檔斷更的尷尬。
每個角色都應該不斷的總結，整理歸納。
人生不只有true或false
世界是豐富多彩的，我在定義變量時很少定義成true/false, 這個習慣不太好。不過我有我自己的想法，總在一些場景的時候考慮，如果來了第三種情況怎麼辦。結果就定義成了0和1，如果來了擴展第三種情況，就加個2即可。
代碼也是如此，要考慮到有第三種情況。是加case。
先寫到這裏吧。