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