總結影響系統健壯性的一些因素
最近一直在苦惱，為什麼我們的程式存在這麼多的問題。拋開用戶提出的新需求，拋開用戶覺得開始設計的不合理，就單說明確需求與設計的前提下，做出的產品，為什麼會有這麼多的bug，並且感覺像個無底洞一樣，已經上線許久了，還時不時的還會出現一些bug，更讓人頭疼的是，這些bug，隱藏的很深，犯的錯極其低級，而且在這種環境下，已經產生了一大批的數據，抓狂不！！！
（剛寫到這裡，也想等有時間再寫一寫，思考思考，產品的一些規則，如何能夠被很好的記錄下來。）
之前在網上看到了一檔節目【程式設計師吐槽大會】，一名叫水彧的中間件程式設計師，他說了一段兒對我來說很勵志的段子：你看我們程式碼，雖然近看密密麻麻一片，你站遠了看，滿螢幕只有兩個字-自信！如果有人來質疑我們的程式碼，我們也有一句統一回復：請先看一下文檔；再質疑就是：請仔細看一下文檔；如果你還質疑，那就是：請熟讀並背誦文檔！！！
回過頭來，看看我們自己寫的程式碼，往往就是，測試：你這個有問題啊！開發：好的，我先看一下程式碼；完全沒有自信的樣子。而我們是如何一步一步寫出這麼讓自己不自信的程式碼的呢？我想了想，原因其實有很多，下面就列出一些來，好讓以後在工作的過程中不斷的反思，不斷的解決這些問題。
1，基本功差。從一種語言的變數開始、類型轉換、運算符、條件語句、循環語句、面向對象特性、執行緒等等，沒有一個良好的掌握，那麼產生bug的可能性就極高；
用Java舉個例子，比如：定義了Controller、Service，在Service實現類當中，因為調用一個方法時，產生了兩個需要的返回值，其中一個return了，而另一個通過全局變數來實現臨時存儲，然後下一步讀取來用，而忽略了Service實例的單一性，導致如果多個請求一起來的時候，這個值可能會取的是另一個值。這種隱患，當開發人員，在開發和做單元測試的時候，往往自己是測不出來的，如果測試人員也沒有做出覆蓋性測試，好吧，那麼這個bug，就會在上線後產生一定的後果。
2，邏輯覆蓋不全，比較複雜的業務邏輯下，條件可能會有很多種可能性，各個功能塊之間關係也是特彆強，互相調用，傳參。如果沒有採用良好的設計模式，或者清晰的模組劃分時，很可能寫的邏輯，只覆蓋到了某些方面，而另一些方面就會在極端情況下產生bug。
再舉個簡單點的例子，之前遇到過一個項目，邏輯層次大致是：項目=》任務=》分組=》表單=》欄位，那麼這些數據在移動端展示的時候，如果配置時，有部分改動，對用戶有影響時，需要給出提示，記錄上的提示是標識一個紅點，到詳情頁的時候，需要把改動的詳細資訊都列出來。那麼從直觀上講，就需要一層一層的判斷，是誰改變了，改變了什麼，這些改變是否需要給出提示，改動語言的組織等等。真正寫的時候，如果也是平鋪直敘的寫，會發現有一大堆的邏輯，很容易把自己搞暈，最後出一大堆的bug。可能在寫程式碼之前還畫了流程圖，呵呵，那也無濟於事，後期的維護也很費勁。
3，沒有充足的日誌。首先說，一個項目，如果沒有日誌，那肯定是不行的，而有日誌，記錄的不完整，也是不行的，那記得太多，日誌空間佔用太大，還要考慮考慮，所以合適程度，需要做好度量。日誌，通常分為系統日誌和操作日誌。系統日誌在編寫的過程中，盡量採用底層拋出，上層捕捉的機制來實現，而往往有些程式碼，try{……}catch(){什麼都沒有}，有意無意的把異常給吃掉了；日誌等級劃分不明確，調試日誌寫到了錯誤日誌裡面；沒有調試日誌的開關，寫的日誌太多；日誌寫了，不好獲取到，或者沒有很好的組織，特別像多執行緒中的日誌，看了之後，你都順不下來是怎麼走的流程。
其實有時候，在用戶沒有提及的情況下，主動寫寫操作日誌也是很必要的，避免出現數據丟失的情況發生，用戶找來了，百口難辯，不定哪個用戶不小心刪了，他說是系統出問題了，捉急不！！！
4，必要的驗證放到客戶端問題。
我們往往因為項目團隊的配置不均衡，會出現一些功能開發轉移的現象，比如，有好多個前端，而只有一兩個後端，那麼後端的工作量就特別大，這時，就會出現一些偷機動作，把一些功能放到前端來實現，比方說，獲取數據時，用戶資訊，往往只有用戶id，那用戶名，就需要關聯來取，而一些通過微服務架構搭建的系統，只能通過介面來獲取，那麼誰取不是誰呀，客戶端來取吧。那麼客戶端就把數據取到後，又調一次服務，把用戶名拼起來，組裝好，再顯示。當然這個例子，對實現來說，也不是什麼問題，關鍵有些驗證性的內容，理應由服務端來實現的，或者說是必須由服務端來實現的，如果放到前端，那就是隱藏的炸彈。比如：非空的檢測，重名的檢測，服務端如果不做好校驗，將來庫裡面的數據異常了，繼而會引起其它的關聯性問題。
5，沒有測試程式碼，單元測試太隨意。測試程式碼這個倒不是一定的，因為我們經常會覺得寫出這些程式碼，是需要消耗時間的，特別是需求變化比較大的項目，寫好完整的測試，工作真的要翻倍。但如果有可能的話，還是覺得寫上為好，有時候，也比較羨慕那種外包項目，把約束寫的清清楚楚，明明白白，介面測試運行一下，通過即完成，也是極好的。而單元測試的必要性是相當大的，特別是白盒測。很多時候，我們開發完後，有個理想的輸出，得到個理想的輸出就算完事兒了，但邊界值，覆蓋率較低的邏輯分支，卻得不到測試，這便是惡夢的星星之火。
5，時間緊任務重。這個問題，真的是不想說，又不能不說。中小型的企業一般都不會對項目管理進行量化分析，那怕有什麼CMMI，ISO的認證，實際工作中，所謂的度量分析，往往就是用戶要求的時間加權領導拍腦袋的時間，完事兒。沒有人才庫、沒有需求數轉換、沒有合理的度量分析演算法，開干！於是，開發人員先著急忙慌寫一堆bug，還覺得美滋滋，一測試，一上線，傻眼了，bug修啊修，改啊改，工期延啊延，超啊超。
當然任務有時候也不能怪領導安排的緊，開發人員的問題在哪兒呢？如果不是著急的寫bug，那麼就是慢慢的寫bug，這完全取決於自身的上進心。
所以我們應該極力做出良好的系統設計，致力寫出高品質的邏輯程式碼，這樣才能心安理得的【寫一段程式碼，品一杯茶茗】
註：圖片來源於網路，如有侵權，請聯繫刪除
