Chris (chris47) 在 《可不可以不要寫糙 code》系列文把 bad code 稱為「糙 code」，但在我的交友圈講得倒是沒那麼文雅，我們都習慣戲稱為「糞 Code」或是「憤 Code」（笑）。我在讀碩士時，一直對程式碼品質相關的領域很有興趣，在實驗室報論文時也是盡量找相關題材的，而其中有一篇來自於加拿大蒙特婁工程學院電腦工程與軟體工程學系的論文叫做「Why Good Developers Write Bad Code: An Observational Case Study of the Impacts of Organizational Factors on Software Quality」，也就是「為什麼好的開發者會寫爛程式碼：一個有關組織因素影響軟體品質的觀察案例研究」，聽起來是不是很有趣？有興趣的同好可以嘗試找這篇論文來仔細拜讀，。
本來是想在本篇好好講整篇論文做為今天的文章，但是時間與篇幅有限，所以我就挑選裡面提到的十個方向的部分內容以及自我對這方面題材的認知去分享這個題目了。
程式設計師會寫「糞扣」（bad code）的原因有很多種，該篇論文從組織對軟體品質影響的觀察列出了十個方向，這邊先列出來做為參考：
至於我們常在現實面上會遇到的原因，很多都是來自與時程過趕，導致我們只能不斷的在程式碼中欠下技術債，但能讓我們還債的承諾卻一再延遲或是根本沒有，在時程壓力的情況下，就算再厲害的程式設計師都會寫出糞扣（bad code）。而時程趕的原因可能來自於失敗的長期規劃，在規劃中將所有內容都制定的非常嚴謹，導致一出現變數，就可能破壞原本的時程，若是仍要遵守計畫原本的時程，專案時程就會滾雪球般的越來越趕，最後欠下了一屁股的技術債。
因為時程寫下糞扣（bad code），也有可能是來自於預算的緊繃。可能公司目前給這個計畫的預算就只足夠團隊稱五個月，又希望團隊在五個月內將這個專案完成，那麼在固定預算與時程的情況下，軟體品質就會是變數了，當預算和時程越緊繃，軟體品質就會越糞（bad）。最常遇到的情況就是出現 Bug 後，會因為尋找真正原因並解決（solution）它太耗時間，而選擇打上一個 patch 去繞過（workaround），但問題仍在那邊，不知道什麼時候會再次爆發。
文件的相關問題可能也會導致糞扣（bad code）的出現，想想看如果文件寫得很齊全，但是事實上文件有提及的有些功能卻沒有實作到，或是實作介面有改，文件卻沒更新到，若有程式設計師依照這份文件去寫程式會發生什麼事？這是有可能發生的，尤其是當文件越複雜、越龐大，維護成本就會越高，那麼文件就可能在一次、次的疏於更新下，成為我們出錯的溫床。
在台灣人才市場有些公司會將程式設計師也視為一個免洗的職缺，頻繁地替換同一專案的成員，有可能是因為給的薪水過低、或是工作環境差，導致流動性高；或是成員都是採用約聘制，時間一到就不續約等等。而這會導致什麼問題呢？那就是專案團隊一再喪失有關這個專案的部分知識，甚至當離開的成員是這個專案的創始成員時，會對專案的維護造成很大的損失。畢竟我們都很難保證每次交接都有辦法交接完全，可能有接替者有原本的一成知識就已經很厲害了，更多的時候是連交接的機會都沒有，或是所謂的交接只是跟把職責分掉而已。再厲害的程式設計師遇到沒人可問、可能連文件都是過期的 Legacy Project，都會感到頭痛。
另一個我想大家多少有經驗的情境，莫過於高層、主管或是前輩給予過度的壓力。當團隊沒有一個統一的對外窗口時，組織內的高層很有可能就會直接找上開發者，然後拼命丟需求給我們，還要求要在什麼時限內完成（題外，感覺好像回到中學時代被各科老師不斷丟作業，還被要求明天都要完成），還不斷強調這個需求很重要，若是沒及時完成公司可能會損失 XXX 萬元之類的。或是總是認為我們不夠認真，並用情緒勒索或是威脅語氣表達：「若是你沒有全心全意的投入你所有的時間在『某件事』上，我就會對你非常非常非常失望，你明白嗎？」諸如此類的情境。而我們都知道，程式設計本身是一個創作行為，壓力過大時、或是心情沮喪時，寫出來的程式碼會有非常大的可能是慘不忍睹的。
關於組織或環境為什麼會讓強如大神也會寫糞扣（bad code）的原因，礙於篇幅與時間大概就講到這邊，事實上當然還有許多因素，等待我們去暸解。儘管講得不多，也希望能激發彼此省思，是不是當前環境下有些因素會阻礙程式設計師去發揮呢？又該怎麼改善呢？而該篇論文裡面也有提到一些建議改善的方向，不妨在自己想過一輪後，再去看看該篇論文給了什麼建議吧。
iThome鐵人賽
看影片追技術