轉(zhuǎn)帖|行業(yè)資訊|編輯:郝浩|2016-09-05 14:25:46.000|閱讀 222 次
概述:我個(gè)人認(rèn)為編寫業(yè)務(wù)邏輯代碼還是要從可讀性入手,輕松的能看懂代碼,如果代碼有問(wèn)題,可以快速定位和修復(fù)。我們又不是做底層框架編寫,要追求各種設(shè)計(jì)和擴(kuò)展性。
# 界面/圖表報(bào)表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
最近經(jīng)常做業(yè)務(wù)邏輯代碼review的工作,發(fā)現(xiàn)各種風(fēng)格的代碼,其中有一種是封裝和抽象做的非常的多,代碼層次非常的深入,表面給人感覺(jué)是:牛逼的代碼。
但是從清晰度和可維護(hù)性來(lái)說(shuō),還是不推薦這么做,理由如下:
我個(gè)人認(rèn)為編寫業(yè)務(wù)邏輯代碼還是要從可讀性入手,輕松的能看懂代碼,如果代碼有問(wèn)題,可以快速定位和修復(fù)。我們又不是做底層框架編寫,要追求各種設(shè)計(jì)和擴(kuò)展性。
下面列舉我覺(jué)得是清晰可維護(hù)的業(yè)務(wù)邏輯代碼的一些特性。
雖然面向?qū)ο笾v究?jī)?nèi)聚和封裝,但是太多的子方法和類,實(shí)在是會(huì)把人繞到頭暈,我推薦的做法是,方法盡量的內(nèi)聯(lián),是同一個(gè)業(yè)務(wù)的就通通放到某個(gè)方法里面,如果這段邏輯實(shí)在太長(zhǎng),可以考慮抽取一些子方法(盡量別太多)。至于類,別動(dòng)不動(dòng)就來(lái)個(gè)類封裝一把,要避免類膨脹。
現(xiàn)在網(wǎng)上的一些文章流行去除所有注釋,通通用一個(gè)好的方法名字表達(dá)即可。這種做法我個(gè)人是很反對(duì)的。雖然方法的命名極其重要,但是寫業(yè)務(wù)邏輯代碼,必要的注釋還是要的,另外的同事閱讀代碼的時(shí)候,也比較容易讀懂代碼的意圖。
如果從事過(guò)互聯(lián)網(wǎng)項(xiàng)目的同學(xué),應(yīng)該有一種深深的體會(huì),線上出現(xiàn)問(wèn)題,除了看各種監(jiān)控系統(tǒng)之外,就是看日志了。日志的輸出必須是有意義準(zhǔn)確的,尤其是 異常日志和業(yè)務(wù)日志。好的日志輸出,可以快速定位問(wèn)題并快速解決。如果解決一個(gè)問(wèn)題要一個(gè)小時(shí)的話,有可能公司就損失幾百萬(wàn)了。
例如:
getInputParameter(); process(); output();
這種就屬于代碼的對(duì)稱性。
只是簡(jiǎn)單的根據(jù)業(yè)務(wù)場(chǎng)景直白的編寫代碼也是不可行的。必要的設(shè)計(jì)可以帶來(lái)更加清晰的代碼結(jié)構(gòu)。
沒(méi)有UT的代碼實(shí)在是太恐怖了,尤其是互聯(lián)網(wǎng)應(yīng)用的代碼,稍微出點(diǎn)問(wèn)題,公司就有可能損失一大筆錢。
編寫ut的時(shí)候,至少一定要把重要的流程覆蓋到,萬(wàn)一代碼有問(wèn)題了,也只是小問(wèn)題。再者,由于需求的變更,原來(lái)寫好的代碼還需要再次改動(dòng),如果你沒(méi)有ut覆蓋的話,可能影響原來(lái)代碼的功能。ut可以帶給我們信心。另外UT也可以促進(jìn)你編寫清晰的代碼。
本文轉(zhuǎn)載自
本站文章除注明轉(zhuǎn)載外,均為本站原創(chuàng)或翻譯。歡迎任何形式的轉(zhuǎn)載,但請(qǐng)務(wù)必注明出處、不得修改原文相關(guān)鏈接,如果存在內(nèi)容上的異議請(qǐng)郵件反饋至chenjj@fc6vip.cn