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

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

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

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

　　我還說：「我們彼此都應能互相支持，任何時刻都可以輕易的接起另一位工程師寫的程序并讓軟件繼續(xù)發(fā)展下去，沒有怨言，只要架構(gòu)清楚、程序代碼撰寫習慣一致就比較不會有問題。像我們公司有些四、五年前做的項目到現(xiàn)在還在維護，如果當初沒要求程序?qū)懛ǎ蚁氍F(xiàn)在維護起來一定非常辛苦，想想你過兩年后如何維護你現(xiàn)在寫的程序吧。」

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

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

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

　　客戶心情好或是內(nèi)心極度愧對我們時，有時還會好心的主動提出愿意付錢請我們修改程序，我們?yōu)榱死^續(xù)經(jīng)營客戶，這種項目當然要繼續(xù)接下去。所以無論如何只要是我們開發(fā)出來的軟件，一定要盡量預留軟件修改的空間，以免每個客戶都只做一次生意，那很累。若是客戶不要求，且項目真的確定完成后需求不可能會變更情況下，那也真的沒什么好要求的了。

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

　　我?guī)啄昵霸?jīng)花了幾萬塊去上超強記憶力的課程，印象最深的只有一句話：「人的 "記憶" 幾乎是無限的，人之所以會忘記是因為 "回憶" 的方式有問題。」

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

　　若真的要回憶起舊時記憶的最佳方式，就是不斷的在腦中建立索引！像我自己寫博客文章，腦子里記得的只有關鍵詞而已，這些關鍵詞就是我的索引數(shù)據(jù)，因為都是自己寫的東西，關鍵詞自己最清楚，所以我隨時可以找到想要找的數(shù)據(jù)，找不到才會去翻 Google 的數(shù)據(jù)。

　　我前幾天就有個有趣的經(jīng)歷，我在看別人寫的程序，他寫的數(shù)據(jù)統(tǒng)計程序一直有數(shù)據(jù)不正確的情況，我看了好幾個小時竟看不出問題所在，最后無意間發(fā)現(xiàn)原來他寫的類定義了一堆類層級(Class)的字段變量(Field)，并且共享于多個方法，他以為這些變量只要宣告一遍然后所有方法(Method)都可以直接使用很方便，卻完全沒有想到這會造成極大的副作用(Side Effect)。我最早一開始寫程序時很喜歡使用「全域變量」，當時是我在寫 Perl、php 的時代，但就因為吃過很多 Debug 的虧，老早就不用這種開發(fā)技巧了，但在看別人的 Code 時卻不會直覺的想到，只有自己寫 Code 時才會避開這個問題，而這就是對技術(shù)細節(jié)內(nèi)化的最佳證據(jù)。

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

it知識庫：品質(zhì)來自對細節(jié)的講究，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。