程序員如果遇到系統掛了，會有啥後果？
- 2020 年 4 月 3 日
- 筆記
作為一個程序員遇到系統掛機是特別平常的事情，從軟件的開發周期看在調試過程中盡量多的暴露崩潰的問題，爭取在正式版本上線的時候能夠減少掛機的可能性，平常在調試過程中掛機和崩潰 都是為了盡最大的可能來暴露問題，所以一款軟件產品上線之前都要經歷幾輪的測試，整體的測試通過之後才能正式推廣出來。
如果真的屬於在線上運行過程中程序崩潰了，程序員本身有一定的責任，但最終把關的測試部門也有一定的責任，但是由於軟件本身的複雜性不可能所有的掛機都能提前發現，正是因為存在這種可能性，所以專門會在軟件裏面設置一個崩潰收集模塊，有崩潰的日誌直接上傳到服務器上，如果是單機版本的就只能保存在本地，等着程序員收集數據拿到真實的原因，由於程序本身的細節繁多，沒有一個正式的軟件能夠說不存在掛機的問題，這也是軟件本身屬性決定的。
如果因為單純的掛機就認定程序員的工作不到位很明顯這種認識是片面的，沒有一個程序員說自己寫的代碼程序永遠不會崩潰，優秀的程序員只不過從軟件的架構以及設計細節上最大程度規避，但是完全的杜絕明顯不符合軟件開發的規律，很多不懂技術的老闆覺得軟件開發屬於一鎚子買賣，已經開發設計完了應該就結束了，甚至有了卸磨殺驢的想法現實中很多企業都存在這種惡劣的習性，這種企業因為本身對技術的不尊重註定了企業永遠很難做強，要想把軟件做好就要尊重軟件自身的規律，否則只能適得其反。
作為軟件設計人員本身來講如何最大程度的避免掛機現象？
注重編程基礎的積累。大多數的崩潰本身是基本功不牢固造成，很多想當然的代碼就是這麼出來的，基礎很差的人很容易寫出掛機的程序員，初級小白更加容易寫出掛機的程序，對於一個程序員最大可能的夯實編程基本功是必須要做的事情。
在架構上規避。好的架構能避免很多麻煩，所以一個架構師對於一個工程顯得非常重要，在一個好的架子上寫代碼能夠極大的減少問題的出現，很多格局不是很大的工程，在修改不同的模塊代碼的時候很容易帶動出現問題，特別的一些不是很正規的小公司經常性的出現一些重複性的錯誤，如果出現這種概率非常大就要考慮整體框架的改進了。
寫代碼要保持嚴謹的態度。很多代碼之所以出錯不是寫代碼的人能力不夠，是因為在寫的過程中沒有養成良好的代碼編程習慣，只是在經常天馬行空的寫代碼，這種最容易出問題，所以無論水平如何首先必須有嚴謹的態度，寫代碼的時候要注意力充分集中，寫過的代碼要回過頭來好好檢查，畢竟寫代碼是一個對細節要求極高的工種，所以保持嚴謹是必須的。
對於每次發生的系統崩潰問題都要引起最大程度的重視，每次掛機都是一次極好的學習機會，也是為了下次寫代碼的時候不在發生重複的錯誤，吃一塹長一智，希望能幫到你。
