|
|
品質(zhì)來(lái)自對(duì)細(xì)節(jié)的講究”是我一直以來(lái)的信念，對(duì)于軟件開發(fā)上的種種細(xì)節(jié)我都不放過(guò)，盡量不讓自己處于模糊地帶，這樣才能在下次遇到相同或類似問(wèn)題時(shí)得以迅速理解并解決，除了可以縮短處理問(wèn)題的時(shí)間外，最重要的是可以提升軟件質(zhì)量，以及在撰寫程序初期能就避免細(xì)節(jié)中潛藏的瑕疵。
我目前在公司里最主要的工作是帶領(lǐng)一群軟件工程師開發(fā)軟件項(xiàng)目，時(shí)常帶大家一起寫 Code、看 Code，有時(shí)間的時(shí)候還會(huì)替他們做 Code Review 并點(diǎn)出一些程序撰寫的問(wèn)題或提供更好的寫法，對(duì)他們的要求不曾少過(guò)。
曾經(jīng)有位工程師問(wèn)我：「保哥，我以前都一直認(rèn)為寫程序不就是 "解決問(wèn)題" 而已嗎？而且以前的主管也從來(lái)不會(huì)問(wèn)我為什么要這么寫或哪里寫不好要改，為什么你還要花時(shí)間看我們寫的 Code，有時(shí)還會(huì)要求我們將寫好沒問(wèn)題的 Code 進(jìn)行重構(gòu)(Refactoring)或整個(gè)打掉重練？」
我回答他：「我們是個(gè)軟件團(tuán)隊(duì)，每個(gè)人都需要自律，并且負(fù)起一位工程師應(yīng)付的責(zé)任，每個(gè)人的技術(shù)知識(shí)都應(yīng)該不斷精進(jìn)，你不應(yīng)該滿足于 "解決問(wèn)題" 這個(gè)層級(jí)，而應(yīng)該進(jìn)而 "理解原理" 與 "探究細(xì)節(jié)"，從這個(gè)角度出發(fā)所寫的東西不但有成就感，也更踏實(shí)?！?/p>
我還說(shuō)：「我們彼此都應(yīng)能互相支持，任何時(shí)刻都可以輕易的接起另一位工程師寫的程序并讓軟件繼續(xù)發(fā)展下去，沒有怨言，只要架構(gòu)清楚、程序代碼撰寫習(xí)慣一致就比較不會(huì)有問(wèn)題。像我們公司有些四、五年前做的項(xiàng)目到現(xiàn)在還在維護(hù)，如果當(dāng)初沒要求程序?qū)懛ǎ蚁氍F(xiàn)在維護(hù)起來(lái)一定非常辛苦，想想你過(guò)兩年后如何維護(hù)你現(xiàn)在寫的程序吧?！?/p>
我是個(gè)熱愛程序設(shè)計(jì)的人，對(duì)我來(lái)說(shuō)寫程序很有趣、很有新鮮感，但有趣的地方絕不止于 "解決問(wèn)題" 而已，我曾經(jīng)也這么想過(guò)，但后來(lái)我理解到，問(wèn)題總會(huì)有解決的一天，但當(dāng)同樣的問(wèn)題不斷出現(xiàn)時(shí)，你會(huì)知道問(wèn)題可以解決，但慢慢的你就會(huì)失去新鮮感、失去成就感，寫程序就會(huì)變成例行公事，就不好玩了。
軟件不像建筑工程般做不好會(huì)危及人的性命，我們不見得需要先規(guī)劃好所有細(xì)部藍(lán)圖才開始施工，我們只要有個(gè)架構(gòu)、了解大致的需求就可以開始動(dòng)工了，做錯(cuò)了就是 "改"，責(zé)無(wú)旁貸的"改"，寫軟件一定要預(yù)留 "修改" 的空間，這就是我盡力要求 "可維護(hù)性" 的關(guān)系。我們公司一年可以接數(shù)十件大大小小的軟件項(xiàng)目，如果每個(gè)項(xiàng)目都只能由開發(fā)的人來(lái)維護(hù)，那人力配置一定會(huì)極度不平衡，相對(duì)的軟件質(zhì)量遲早出問(wèn)題。
再者，你應(yīng)該也知道客戶講的東西經(jīng)常 "昨是今非"，越大的項(xiàng)目越是這樣，連簽了名的文件都還能不算數(shù)，對(duì)于一些小范圍的更動(dòng)對(duì)軟件來(lái)說(shuō)本來(lái)就應(yīng)該是合理的，但我看到有些朋友對(duì)于客戶修改規(guī)格的舉動(dòng)經(jīng)常忿忿不平，還有一些經(jīng)常接項(xiàng)目的外包人員來(lái)說(shuō)，也經(jīng)常在為一些很小幅度的規(guī)格變更堅(jiān)持己見，但是光花在不愿意修改所溝通的時(shí)間，我想軟件早就不知道修完幾遍了，一切都出在對(duì)軟件項(xiàng)目錯(cuò)誤的認(rèn)知，或是自己的寫的軟件不容易修改所做出的 "合理反應(yīng)"。
客戶心情好或是內(nèi)心極度愧對(duì)我們時(shí)，有時(shí)還會(huì)好心的主動(dòng)提出愿意付錢請(qǐng)我們修改程序，我們?yōu)榱死^續(xù)經(jīng)營(yíng)客戶，這種項(xiàng)目當(dāng)然要繼續(xù)接下去。所以無(wú)論如何只要是我們開發(fā)出來(lái)的軟件，一定要盡量預(yù)留軟件修改的空間，以免每個(gè)客戶都只做一次生意，那很累。若是客戶不要求，且項(xiàng)目真的確定完成后需求不可能會(huì)變更情況下，那也真的沒什么好要求的了。
隆重聲明一下，我當(dāng)然不可能認(rèn)同客戶狂亂的規(guī)格變更，凡事總有個(gè)界線在，我只是想強(qiáng)調(diào)做軟件項(xiàng)目應(yīng)該與客戶站在同一陣線，以客戶滿意度為依歸。但若遇到超級(jí)沒 sense 又很愛凹你做東做西且打死不追加預(yù)算的客戶時(shí)，你可以有兩個(gè)選擇：(1) 直接退錢說(shuō)不做了 (2) 硬著頭皮改到底。
我?guī)啄昵霸?jīng)花了幾萬(wàn)塊去上超強(qiáng)記憶力的課程，印象最深的只有一句話：「人的 "記憶" 幾乎是無(wú)限的，人之所以會(huì)忘記是因?yàn)?"回憶" 的方式有問(wèn)題?！?/p>
技術(shù)的細(xì)節(jié)如此的多，有人會(huì)問(wèn)我：「我怎么可能把所有細(xì)節(jié)都記得，有需要再查 Google 就有了啊?！故紫?，Google 查到的東西不見得是對(duì)的，你不了解細(xì)節(jié)自然也無(wú)法判斷對(duì)錯(cuò)。當(dāng)然，我也不例外，我會(huì)忘事情，技術(shù)細(xì)節(jié)也會(huì)忘，但那不是忘記，只是回憶不起而已，有些知識(shí)被消化了，已經(jīng)進(jìn)入潛意識(shí)，寫程序時(shí)你會(huì)很自然的會(huì)將你曾經(jīng)學(xué)過(guò)、認(rèn)真研究過(guò)的東西都給用上，只是你不知道而已。
若真的要回憶起舊時(shí)記憶的最佳方式，就是不斷的在腦中建立索引！像我自己寫博客文章，腦子里記得的只有關(guān)鍵詞而已，這些關(guān)鍵詞就是我的索引數(shù)據(jù)，因?yàn)槎际亲约簩懙臇|西，關(guān)鍵詞自己最清楚，所以我隨時(shí)可以找到想要找的數(shù)據(jù)，找不到才會(huì)去翻 Google 的數(shù)據(jù)。
我前幾天就有個(gè)有趣的經(jīng)歷，我在看別人寫的程序，他寫的數(shù)據(jù)統(tǒng)計(jì)程序一直有數(shù)據(jù)不正確的情況，我看了好幾個(gè)小時(shí)竟看不出問(wèn)題所在，最后無(wú)意間發(fā)現(xiàn)原來(lái)他寫的類定義了一堆類層級(jí)(Class)的字段變量(Field)，并且共享于多個(gè)方法，他以為這些變量只要宣告一遍然后所有方法(Method)都可以直接使用很方便，卻完全沒有想到這會(huì)造成極大的副作用(Side Effect)。我最早一開始寫程序時(shí)很喜歡使用「全域變量」，當(dāng)時(shí)是我在寫 Perl、php 的時(shí)代，但就因?yàn)槌赃^(guò)很多 Debug 的虧，老早就不用這種開發(fā)技巧了，但在看別人的 Code 時(shí)卻不會(huì)直覺的想到，只有自己寫 Code 時(shí)才會(huì)避開這個(gè)問(wèn)題，而這就是對(duì)技術(shù)細(xì)節(jié)內(nèi)化的最佳證據(jù)。
有一句話說(shuō)得很好：「時(shí)間花在哪里，成就就在哪里」想要做好軟件工程師的角色，就應(yīng)該多花時(shí)間專研技術(shù)細(xì)節(jié)，這并非是一條不歸路，做軟件的人，不滿意隨時(shí)可以轉(zhuǎn)換跑道，但你走這條路的時(shí)候不認(rèn)真就是浪費(fèi)時(shí)間，你只要有付出努力就一定會(huì)獲得有價(jià)值的東西，畢竟寫程序是腦內(nèi)革命，不是每個(gè)人都走的下去的，但要長(zhǎng)期走下去就必須要有源源不絕的熱情、對(duì)新知的無(wú)限渴望與用不完的新鮮感。
it知識(shí)庫(kù)：品質(zhì)來(lái)自對(duì)細(xì)節(jié)的講究，轉(zhuǎn)載需保留來(lái)源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
