千里之堤潰於蟻穴，質量問題警鐘長鳴
是能用就行，還是精益求精？
水文一篇，一點點小感慨。事情緣由如下：
緣起
早上來，開啟程式碼就看到了一個提交。
改動上沒啥問題，不過用到了 ES2015 的新語法，老舊瀏覽器上語法不識別，會直接導致整個檔案掛掉，馬上通知了開發立即修復。
之所以對這個問題這麼敏感。
其一是這真的是一個嚴重的問題，甚至可以說是事故。因為不修這個bug好歹是在特定的場景下才會發生，這個會直接導致特定瀏覽器中整個應用直接完全崩掉。如果用受眾來對比的話，就是不改的情況下，只是一部分使用者在一部分場景下出問題；改了之後則是，一部分使用者整個系統直接完全無法使用。
其二則是因為16年剛入職的時候，一位公司前輩的給我留下的印象，當時我雖是初入前端，但那會前端都不是個部分，甚至只是一個小組，我作為專業前端的產出物，被非前端專業人士發現了bug。當時出問題的程式碼大概是 {default:"某個值"} ，你可能看不出問題，這裡實際是default 是保留關鍵字，某些瀏覽器中不能直接當成key值，如果要用得這樣寫 {"default":"某個值"} 或者是 var obj = {}; obj["default"] = "某個值" ，取值、賦值均一樣。 這件事之所以印象深刻，是因為當時對方不是系統掛了發現的，而是直接搜尋得出的，我當時問你還這麼細心 ，對方說“被你們前端坑的次數多了，就得長點心”。 這點當時對我觸動非常大，因為確實很清楚事情的影響面，那會IE8還是比較常見的。
這次的“事故”雖然很快修復了，但還是造成了真實的影響。
想著我們是有程式碼檢查的，都用3年了，這個程式碼裡理論上是根本提交不了的才對。 做了自查才發現原來我們在自己的倉庫開發再將構建產物放入框架，大約半年前，我們的原始碼也遷移到了框架的倉庫，漏了將檢測的工具遷移過來。
然而就是這個疏漏，不經意間不知道已經引入了多少風險。
再繼
接著下午的時候評審了一個 merge_requests
其實這個如果單純從測試提的 bug 場景來說，提交的程式碼是解決問題的。
但是他能想到加個 if 分支，就沒有想到“即使有成員，也不一定有四個成員”嗎？ 我覺得肯定有意識到，只是從直覺中覺得沒有必要不會遇到，心裡可能在假設真實的場景要麼就有要麼就沒有，不會只有一部分。
但是作為開發者，有個常識叫一切客戶端輸入都不可信。做框架做元件做底層來說，你怎麼知道別人會怎麼來用這個東西呢，會給它提供什麼樣的輸入呢？基於這些，所以我給了上面的建議。
本文打算再次強調下下面幾點，是希望每一個人都能在開發過程中及時地去處理掉發現的問題。
- 修復 bug 要抓住本質，不要無腦往上堆。
- 過程中要不斷對程式碼進行重構。
- 如果一定有問題，請將問題暴露出來，而不是藏起來，假裝它不存在。
寫到這裡，又想起一件事：
之前某個頁面上的某個按鈕功能不能用了，有人找到我排查。最終發現是 js 程式碼和頁面都不匹配了。
幾經溝通，找到了調整的人員，答覆是： 這個頁面不用了，遷移到了新的頁面，系統內是調整過的，這裡的問題可能是外部直接引用了這個地址，從而引發的錯誤。
我的建議是：
- 不用就刪，反正不能正常用的。 這只是一個頁面，不是底層庫，隻影響一個頁面，不能用對方能馬上發現問題，這樣看起來正常，用到才會發現問題，溝通和排查都是很高的成本。
- 原頁面直接提示已經棄用請使用xxx，或者乾脆直接重定向到新的頁面去，來實現外部的無縫切換。
後記
程式設計師中經常流傳一句話，說自己維護的“屎山”程式碼，這可能是想表達之前的程式碼很爛吧。
假設我們不得不面對這樣“不好”的東西，我們應該如何處理呢？我認為底線就是做好隔離不讓它汙染和擴散到更多的地方，更好點呢可能是要想辦法把這個玩意清理乾淨。畢竟誰家都有衛生間不是？它不僅很有用也可以很乾淨。
不過想想一直圖這麼吐槽的這些人又是怎麼對待“屎山”的呢？可能最常見的就是繼續在“屎山”上拉吧。如果這樣，他又有什麼資格這樣說呢？
可現實的問題是那真的是“屎山”嗎？ 你真的就寫得更好嗎？甚至你能寫得出來嗎？
可怕的不是“屎山”，可怕的是繼續在“屎山”上拉，可怕的是自己成為製造“屎山”的人。
你寫的每一行程式碼都是你的名片
願與諸君共勉。 你不是碼農，你不是程式設計師，你是開發者，你是研·發·工·程·師，願你在成長的時候，你寫程式碼也在伴隨著你一起成長。