# 品質來自對細節的講究

“品質來自對細節的講究”是我一直以來的信念，對於軟體開發上的種種細節我都不放過，盡量不讓自己處於模糊地帶，這樣才能在下次遇到相同或類似問題時得以迅速理解並解決，除了可以縮短處理問題的時間外，最重要的是可以提升軟體品質，以及在撰寫程式初期能就避免細節中潛藏的瑕疵。

我目前在公司裡最主要的工作是帶領一群軟體工程師開發軟體專案，時常帶大家一起寫 Code、看 Code，有時間的時候還會替他們做 Code Review 並點出一些程式撰寫的問題或提供更好的寫法，對他們的要求不曾少過。

曾經有位工程師問我：「保哥，我以前都一直認為寫程式不就是 "**解決問題**" 而已嗎？而且以前的主管也從來不會問我為什麼要這麼寫或哪裡寫不好要改，為什麼你還要花時間看我們寫的 Code，有時還會要求我們將寫好沒問題的 Code 進行重構(Refactoring)或整個打掉重練？」

我回答他：「我們是個軟體團隊，每個人都需要自律，並且負起一位工程師應付的責任，每個人的技術知識都應該不斷精進，你不應該滿足於 "**解決問題**" 這個層級，而應該進而 "**理解原理**" 與 "**探究細節**"，從這個角度出發所寫的東西不但有成就感，也更踏實。」

我還說：「我們彼此都應能互相支援，任何時刻都可以輕易的接起另一位工程師寫的程式並讓軟體繼續發展下去，沒有怨言，只要架構清楚、程式碼撰寫習慣一致就比較不會有問題。像我們公司有些四、五年前做的專案到現在還在維護，如果當初沒要求程式寫法，我想現在維護起來一定非常辛苦，想想你過兩年後如何維護你現在寫的程式吧。」

我是個熱愛程式設計的人，對我來說寫程式很有趣、很有新鮮感，但有趣的地方絕不止於 "**解決問題**" 而已，我曾經也這麼想過，但後來我理解到，問題總會有解決的一天，但當同樣的問題不斷出現時，你會知道問題可以解決，但慢慢的你就會失去新鮮感、失去成就感，寫程式就會變成例行公事，就不好玩了。

軟體不像建築工程般做不好會危及人的性命，我們不見得需要先規劃好所有細部藍圖才開始施工，我們只要有個架構、瞭解大致的需求就可以開始動工了，做錯了就是 "**改**"，責無旁貸的"**改**"，寫軟體一定要預留 "**修改**" 的空間，這就是我盡力要求 "**可維護性**" 的關係。我們公司一年可以接數十件大大小小的軟體專案，如果每個專案都只能由開發的人來維護，那人力配置一定會極度不平衡，相對的軟體品質遲早出問題。

再者，你應該也知道客戶講的東西經常 "**昨是今非**"，越大的案子越是這樣，連簽了名的文件都還能不算數，對於一些**小範圍的更動**對**軟體**來說本來就應該是合理的，但我看到有些朋友對於客戶修改規格的舉動經常忿忿不平，還有一些經常接案的外包人員來說，也經常在為一些很小幅度的規格變更堅持己見，但是光花在不願意修改所溝通的時間我想軟體早就不知道修完幾遍了，一切都出在對軟體專案錯誤的認知，或是自己的寫的軟體不容易修改所做出的 "**合理反應**"。

客戶心情好或是內心極度愧對我們時，有時還會好心的主動提出願意付錢請我們修改程式，我們為了繼續經營客戶，這種案子當然要繼續接下去。所以無論如何只要是我們開發出來的軟體，一定要盡量預留軟體修改的空間，以免每個客戶都只做一次生意，那很累。若是客戶不要求，且案子真的確定完成後需求不可能會變更情況下，那也真的沒什麼好要求的了。

隆重聲明一下，我當然不可能認同客戶狂亂的規格變更，凡事總有個界線在，我只是想強調做軟體專案應該與客戶站在同一陣線，以客戶滿意度為依歸。但若遇到超級沒 sense 又很愛凹你做東做西且打死不追加預算的客戶時，你可以有兩個選擇：(1) 直接退錢說不做了 (2) 硬著頭皮改到底。

我幾年前曾經花了幾萬塊去上**超強記憶力**的課程，印象最深的只有一句話：「人的 "**記憶**" 幾乎是無限的，人之所以會**忘記**是因為 "**回憶**" 的方式有問題。」

技術的細節如此的多，有人會問我：「我怎麼可能把所有細節都記得，有需要再查 Google 就有了啊。」首先，Google 查到的東西不見得是對的，你不瞭解**細節**自然也無法判斷對錯。當然，我也不例外，我會忘事情，技術細節也會忘，但那不是忘記，只是回憶不起而已，有些知識被消化了，已經進入潛意識，寫程式時你會很自然的會將你曾經學過、認真研究過的東西都給用上，只是你不知道而已。

若真的要**回憶**起舊時記憶的最佳方式，就是不斷的在腦中**建立索引**！像我自己寫部落格文章，腦子裡記得的只有**關鍵字**而已，這些關鍵字就是我的**索引**資料，因為都是自己寫的東西，關鍵字自己最清楚，所以我隨時可以找到想要找的資料，找不到才會去翻 Google 的資料。

我前幾天就有個有趣的經歷，我在看別人寫的程式，他寫的資料統計程式一直有數據不正確的情況，我看了好幾個小時竟看不出問題所在，最後無意間發現原來他寫的類別定義了一堆**類別層級(Class)**的欄位變數(Field)，並且共用於多個方法，他以為這些變數只要宣告一遍然後所有方法(Method)都可以直接使用很方便，卻完全沒有想到這會造成極大的副作用(Side Effect)。我最早一開始寫程式時很喜歡使用「全域變數」，當時是我在寫 Perl、PHP 的時代，但就因為吃過很多 Debug 的虧，老早就不用這種開發技巧了，但在看別人的 Code 時卻不會直覺的想到，只有自己寫 Code 時才會避開這個問題，而這就是對技術細節內化的最佳證據。

有一句話說得很好：「時間花在哪裡，成就就在哪裡」想要做好軟體工程師的角色，就應該多花時間專研技術細節，這並非是一條不歸路，做軟體的人，不滿意隨時可以轉換跑道，但你走這條路的時候不認真就是浪費時間，你只要有付出努力就一定會獲得有價值的東西，畢竟寫程式是腦內革命，不是每個人都走的下去的，但要長期走下去就必須要有源源不絕的熱情、對新知的無限渴望與用不完的新鮮感。

以上是我的個人觀點，歡迎切磋討論。