先前在網(wǎng)絡(luò)看到很多人在推薦與分享 Clean Code 這本書(shū)，當(dāng)時(shí)，并無(wú)很強(qiáng)烈動(dòng)機(jī)想要看這本書(shū)。先入為主的覺(jué)得這又只是一本介紹程序 Design Patten 的書(shū)罷了。實(shí)際上到書(shū)店翻開(kāi)這本書(shū)之后，尤其在前面幾頁(yè)中看到下面這一張圖。心中Wow一聲，心想這本書(shū)一針見(jiàn)血的刺進(jìn)我的痛。
這本書(shū)介紹非常多程序開(kāi)發(fā)者因該注意的程序撰寫(xiě)概念跟守則，這里就不一一介紹，有興趣的人建議可以買(mǎi)來(lái)看看。不過(guò)個(gè)人覺(jué)得此書(shū)有些章節(jié)中，閱讀者若是沒(méi)有兩三年的實(shí)務(wù)程序開(kāi)發(fā)經(jīng)驗(yàn)或是維護(hù)許多大型系統(tǒng)的經(jīng)歷，可能無(wú)法感同身受或是認(rèn)同書(shū)中的一些作法及想法。
Clean Code對(duì)于維運(yùn)成本有甚么關(guān)系呢?個(gè)人認(rèn)為有良好的Clean Code概念，不僅可以降低團(tuán)隊(duì)的開(kāi)發(fā)成本，也可以讓系統(tǒng)維運(yùn)成本也跟著降地。系統(tǒng)維運(yùn)項(xiàng)目大致有下面幾點(diǎn):
系統(tǒng)數(shù)據(jù)維護(hù)
Bug修正
功能規(guī)格的修正或是修改
開(kāi)發(fā)新功能與新需求
維運(yùn)成本考慮就只有下面三項(xiàng):
時(shí)間
人力
風(fēng)險(xiǎn)
個(gè)人認(rèn)為最耗成本的維運(yùn)項(xiàng)目是第二項(xiàng)到第四項(xiàng)。一般而言企業(yè)內(nèi)部的IT要真正只需維護(hù)自己所開(kāi)發(fā)的系統(tǒng)的情況并不多，絕大多數(shù)的人都必須去承接前人所留下或是外部導(dǎo)入的系統(tǒng)。由此可知，當(dāng)新團(tuán)隊(duì)或是新人承接后，不僅是對(duì)原本系統(tǒng)架構(gòu)及ProcessKnowhow不熟外，可能連代碼在寫(xiě)甚么都看不懂也大有人在。故經(jīng)常發(fā)生 好的代碼帶你上天堂，壞的程序碼會(huì)讓你生不如死 的戲碼。因此，當(dāng)系統(tǒng)的代碼是很雜亂時(shí)，所付出的代價(jià)就是，若系統(tǒng)要進(jìn)行Trouble shooing時(shí)，問(wèn)題被解決的時(shí)間就會(huì)被拉長(zhǎng)，且若是用戶(hù)有新新需求或是功能變更時(shí)，程序的開(kāi)發(fā)時(shí)程將會(huì)被拉長(zhǎng)，縱使只是加一個(gè)小功能，所花費(fèi)的的時(shí)程會(huì)比之前系統(tǒng)創(chuàng)建的時(shí)間還長(zhǎng)。尤其當(dāng)這系統(tǒng)架構(gòu)隨時(shí)間越來(lái)越大或是錯(cuò)綜復(fù)雜時(shí)，所花費(fèi)的修改或是添加功能的成本也隨之越大。最可怕的是，當(dāng)新團(tuán)隊(duì)接手后，完全無(wú)法針對(duì)該系統(tǒng)進(jìn)行修改或是維護(hù)時(shí)，勢(shì)必需要重新創(chuàng)建一套新系統(tǒng)時(shí)候，這是不僅是成本的消耗，同時(shí)，還必須承擔(dān)新舊系統(tǒng)交換上下線、新系統(tǒng)須包含舊系統(tǒng)功能、新系統(tǒng)時(shí)程…等風(fēng)險(xiǎn)，當(dāng)然，風(fēng)險(xiǎn)與時(shí)間是成反比的。
當(dāng)一個(gè)團(tuán)隊(duì)在開(kāi)發(fā)系統(tǒng)時(shí)，若只在乎"完成"系統(tǒng)功能而不考慮架構(gòu)及代碼規(guī)范，進(jìn)而產(chǎn)出雜亂的代碼，在短期內(nèi)或許可以滿足需求，看似用很少的成本，發(fā)揮極大的效益。但是，就系統(tǒng)營(yíng)運(yùn)的時(shí)間拉長(zhǎng)，，實(shí)際上后續(xù)的維運(yùn)卻是必須再花費(fèi)更多成本支出，才能滿足其維運(yùn)需求。
從上圖可知，若是該系統(tǒng)的代碼越雜亂(只求速度與代碼產(chǎn)能的后果)，此系統(tǒng)后續(xù)的各項(xiàng)功能開(kāi)發(fā)或是變更，所完成的時(shí)間是越來(lái)越長(zhǎng)，因?yàn)椋绦虍a(chǎn)能是越來(lái)越低了。然而，主管為了解決這現(xiàn)象，往往就會(huì)出現(xiàn)人月神話的場(chǎng)景。但是，往往只能治標(biāo)無(wú)法治本。
程序產(chǎn)能碼 / 人力 = 時(shí)間
就一般程序員而言，在程序開(kāi)發(fā)約三個(gè)月后，大概就會(huì)忘記之前程序?yàn)槭裁匆@樣寫(xiě)?？上攵婚_(kāi)始就把的代碼變得很雜亂，不易閱讀。在三個(gè)月后有新需求或是用戶(hù)功能變更的時(shí)候，團(tuán)隊(duì)又需要花大量的時(shí)間成本重新Review Code，造成往往只需要花幾個(gè)小時(shí)就可以完成的功能，卻必須痛苦的好幾天或是好幾周才有辦法完成。若是又有遇到時(shí)間壓力，最后不是系統(tǒng)品質(zhì)下降，就是另一個(gè)雜亂的代碼誕生。在這本書(shū)中提到「我們抱怨需求一變?cè)僮?，違背原本的設(shè)計(jì)，我們感嘆開(kāi)發(fā)進(jìn)度過(guò)于緊湊，導(dǎo)致無(wú)法把事情做好。我們滔滔不絕將原因歸咎于愚蠢的主管,偏執(zhí)的客戶(hù),無(wú)用的市場(chǎng)型態(tài)，但是錯(cuò)并不在這些事物上，而是在我們本身，我們不夠?qū)I(yè)」，這句話我認(rèn)為說(shuō)得很好，因?yàn)?，無(wú)論是PM或是用戶(hù)都是針對(duì)他們需負(fù)責(zé)的工作而做事，相對(duì)的開(kāi)發(fā)者或IT人員該負(fù)責(zé)的工作就是在交付功能之余，也須保護(hù)代碼不要過(guò)于混亂。而若是要達(dá)到所謂 Clean Code 那樣不是要花費(fèi)更大的成本? 我認(rèn)為不然，就以可靠度工程中的浴缸曲線理論來(lái)思考。當(dāng)一個(gè)系統(tǒng)開(kāi)發(fā)期間，花費(fèi)較高的成本，其實(shí)是在初期的系統(tǒng)分析與架構(gòu)設(shè)計(jì)，中間的程序開(kāi)發(fā)成本相對(duì)是低的，而若是因?yàn)槌跗诘募軜?gòu)有問(wèn)題或是中間開(kāi)發(fā)代碼是不易維護(hù)，則會(huì)影響到后面的維運(yùn)或是需求增加，進(jìn)而將會(huì)造成維運(yùn)成本的墊高，而越后面的修正是會(huì)花費(fèi)比初期更高的成本才有辦法完成任務(wù)。
最后，軟件工程常常會(huì)提到開(kāi)發(fā)需要有許多文檔或是單元測(cè)試及一堆測(cè)試后才可以上線，基本上這是無(wú)誤的，不過(guò)，就以制造業(yè)的IT開(kāi)發(fā)者來(lái)說(shuō)，往往時(shí)程與需求都被壓的喘不過(guò)氣，若是有分析文檔與說(shuō)明手冊(cè)，就已經(jīng)很不錯(cuò)，要做到測(cè)試部分，如果可以在上線進(jìn)行壓力測(cè)試及集成測(cè)試就很棒了。要進(jìn)行單元測(cè)試實(shí)在不可能，且也不一定公司會(huì)有這樣測(cè)試單位，因此，常常開(kāi)發(fā)者就是測(cè)試者，結(jié)果就是甚么都沒(méi)有。上線的系統(tǒng)不可能完全都沒(méi)有任何Bug或是一個(gè)完美的系統(tǒng)，甚至不修改功能的系統(tǒng)，我覺(jué)得在制造業(yè)這是不太可能發(fā)生，但是，至少保持良好的代碼或是可讀性高的代碼，對(duì)于后續(xù)的維運(yùn)是有幫助，至少出問(wèn)題時(shí)候，還可以快速找到問(wèn)題所在，而不是像偵探一樣大海撈針去找線索，系統(tǒng)需要Enhance時(shí)，開(kāi)發(fā)時(shí)程也會(huì)較快許多。
