老碼農(nóng)：如何寫出讓自己滿意的代碼
來源:網(wǎng)站推廣 2013-10-31
要做到一年后甚至幾年后你拿到自己寫的代碼,還能很容易看明白當(dāng)時(shí)的思路和實(shí)現(xiàn)
今天有位朋友在微博上問我這樣一個(gè)問題:
“@老碼農(nóng)的自留地 ,最近出于學(xué)習(xí)目的寫一個(gè)管理系統(tǒng),越到后邊,越覺得自己前邊的代碼寫得爛前輩,我想讓代碼寫得更好一點(diǎn),能不能談?wù)勀愕慕?jīng)驗(yàn),給我指點(diǎn)一下!”
我在回復(fù)里剛寫了幾句,就意識(shí)到140個(gè)字很難把我的想法說清楚,本著知無不言言無不盡的好為人師精神,我決定把我的回答寫成一篇博文
首先要說明的是,我寫這篇博客并不代表本人覺得自己的代碼寫得有多好事實(shí)上我很清楚自己的水平,作為一個(gè)做應(yīng)用系統(tǒng)的程序員,和那些做框架做系統(tǒng)的大牛根本就不在一個(gè)層次而且即使在應(yīng)用層次,我的水平大概也只能算二三流,只是因?yàn)闊釔劬幊趟砸恢痹谂Χ?但不管怎么說,能做自己喜歡的工作我已經(jīng)很滿足了所以我稍微篡改了一下問題,針對(duì)“覺得自己前邊的代碼寫得爛”這個(gè)重點(diǎn),把這位朋友問的如何“讓代碼寫得更好一點(diǎn)”改成了“如何寫出讓自己滿意的代碼”
言歸正傳,我自己的體會(huì)是寫代碼很像寫作文,開始寫之前的構(gòu)思過程是最關(guān)鍵的記得高中的時(shí)候,有位語文老師給我傳授的經(jīng)驗(yàn)是,至少花三分之一的時(shí)間來構(gòu)思,反復(fù)斟酌中心思想、各個(gè)段落的大意,文章的脈絡(luò),主要的修辭手法,等等把這些要素都想清楚了,寫起來就可以一氣呵成
我覺得寫代碼也是一樣,思路是最關(guān)鍵的假定采用的技術(shù)平臺(tái)、框架、工具等已經(jīng)確定了,那么在開始動(dòng)手寫之前,花三分之一以上的開發(fā)時(shí)間去把所有的數(shù)據(jù)結(jié)構(gòu)及其相互關(guān)系考慮清楚例如需要定義幾個(gè)類,類和類之間的關(guān)系是怎樣的,每個(gè)類里都有什么屬性,每個(gè)類提供一些什么樣的方法,等等,這些是最核心的這些數(shù)據(jù)結(jié)構(gòu)要考慮得盡可能細(xì),比如功能實(shí)現(xiàn)可能沒問題,但是性能上不理想,這就說明你的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)還需要改進(jìn)這些細(xì)節(jié)要反復(fù)考慮,交叉檢驗(yàn),直到自己覺得很周到了為止在此基礎(chǔ)上,再注意實(shí)現(xiàn)的細(xì)節(jié)、測試用例、代碼可讀性,就應(yīng)該可以寫出讓自己滿意的代碼具體說明如下:
1. 數(shù)據(jù)結(jié)構(gòu)和核心算法
關(guān)于數(shù)據(jù)結(jié)構(gòu)的重要性,大神Linus Torvalds講過這樣的話,我覺得非常贊同:”Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” (低水平程序員總在考慮代碼,高水平程序員總在考慮數(shù)據(jù)結(jié)構(gòu)及其之間的關(guān)系)
數(shù)據(jù)結(jié)構(gòu)考慮清楚了,核心的算法自然就出來了,這就是關(guān)于每個(gè)類的每個(gè)方法如何實(shí)現(xiàn)的問題比如需要實(shí)現(xiàn)一個(gè)中位數(shù)查詢方法,如果你前面確定了數(shù)據(jù)保存的格式是一個(gè)列表,那么你可以考慮采用插入排序法;如果數(shù)據(jù)格式是自平衡二叉排序樹(AVL),則只需直接返回根節(jié)點(diǎn)就可以了
數(shù)據(jù)結(jié)構(gòu)決定算法,所以你在考慮數(shù)據(jù)結(jié)構(gòu)的時(shí)候,一定要盡可能地使數(shù)據(jù)的結(jié)構(gòu)和它的自然屬性相匹配,不然后面的實(shí)現(xiàn)就會(huì)是一場噩夢比如,你把一個(gè)多層級(jí)的結(jié)構(gòu)定義成二維數(shù)組,看上去也靠譜,相當(dāng)于在一個(gè)表格里維護(hù)一個(gè)組織結(jié)構(gòu)圖,可是當(dāng)你做到部門增減的時(shí)候,本層級(jí)的數(shù)組元素移動(dòng)自不必說,下面各個(gè)層級(jí)的元素移動(dòng)就很容易亂套,而且性能很差,可能你寫了2000行代碼還有很多邊界條件會(huì)出錯(cuò)相反,如果用一個(gè)孩子兄弟鏈表來表示這個(gè)樹型結(jié)構(gòu),操作起來就非常容易,可能100行都足夠了
2. 功能實(shí)現(xiàn)
思路確定后,實(shí)現(xiàn)過程也需要大量的構(gòu)思活動(dòng)碰到你比較熟悉有經(jīng)驗(yàn)的領(lǐng)域,你自然可以輕車熟路,但難免會(huì)有一些你不太熟悉的技術(shù)需要嘗試有的同學(xué)比較排斥這種領(lǐng)域,比如我好不容易才掌握了Struts 2,領(lǐng)導(dǎo)又讓我去學(xué)習(xí)Grails框架,我就會(huì)覺得很不爽,大概看了看就挑出它的一堆問題,然后能躲多遠(yuǎn)就躲多遠(yuǎn)可是我要說,這樣的心態(tài)會(huì)阻礙自己不斷提高技術(shù)水平作為一個(gè)程序員,最大的挑戰(zhàn)也是最大的樂趣所在,就是不斷學(xué)習(xí)新的技術(shù),沒有這樣的心態(tài),很快就會(huì)落后
好,那么遇到不熟悉的技術(shù)怎么辦?我的體會(huì)是,先不要急著實(shí)現(xiàn)項(xiàng)目中的代碼,自己另外維護(hù)一個(gè)測試項(xiàng)目,在里邊邊查文檔邊學(xué)習(xí),邊做一個(gè)小功能,把所有需要在項(xiàng)目中實(shí)現(xiàn)的功能先在測試項(xiàng)目里跑通,然后再寫項(xiàng)目里的代碼這樣做的好處是把單個(gè)技術(shù)問題和其他潛在的bug隔離開來,便于快速學(xué)習(xí)新技術(shù)否則,你直接在項(xiàng)目里寫代碼出錯(cuò)以后,要判斷問題的源頭都要多費(fèi)好幾倍的精力
3. 測試
測試很重要,設(shè)計(jì)測試用例就像開發(fā)時(shí)設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)一樣,也是很關(guān)鍵的在設(shè)計(jì)測試用例的時(shí)候,要把當(dāng)時(shí)自己設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)的思路全部忘掉,或者找別人來設(shè)計(jì)測試用例,不然會(huì)不由自主地測試那些你已經(jīng)考慮到了的地方這樣測試是跑通了,用戶一用起來可能各種邊界條件會(huì)到處出問題
有人會(huì)推崇TDD的方法,先設(shè)計(jì)好測試用例,然后在開發(fā)過程中確保所有測試通過我個(gè)人不喜歡這種方法,雖然承認(rèn)從開發(fā)質(zhì)量管理和長期維護(hù)的角度來說TDD是很有必要的,但我個(gè)人嘗試的結(jié)果是,設(shè)計(jì)完測試用例后,想到開發(fā)的目標(biāo)不是實(shí)現(xiàn)功能,而是為了跑通測試,就感到毫無樂趣可言這一點(diǎn)我自己也覺得很矛盾
寫到這里我又想到大神Linus說過的另一句話:”Regression testing” What’s that If it compiles, it is good; if it boots up, it is perfect. (“回歸測試”?這是什么東西?如果代碼能編譯就是好的,如果它啟動(dòng)了,那就是完美的)
當(dāng)然了,大神水平擺在那里,他有資本目空一切,咱確實(shí)沒資格仿效但是我還是覺得TDD也有TDD的問題,測試是很重要,但把它擺到驅(qū)動(dòng)開發(fā)的高度,就有點(diǎn)本末倒置了這個(gè)是我自己的一點(diǎn)看法,本人對(duì)TDD了解得不深入,如果有謬誤之處,請(qǐng)多多指教
4. 代碼可讀性
要想自己滿意,代碼的可讀性一定要好這就涉及到命名和注釋的問題
命名就像超市里的商品標(biāo)簽一樣,要讓看得人一目了然就知道這是個(gè)什么東西,比如你的員工類里有兩個(gè)屬性分別是到崗日期和離職日期,把它們定義成date1和date2就沒有多少可讀性,而定義成dateOnBoard和dateQuit就比較清晰
注釋也是很重要的,它可以用來說明一段代碼的作用,算法的設(shè)計(jì)思想,或者是方法調(diào)用的參數(shù)格式要求等有人覺得命名就是注釋,代碼本身就為自己代言了我覺得這種說法用來強(qiáng)調(diào)命名規(guī)范的重要性是很好的,但是因此說不需要注釋則有失偏頗試想,如果Dijkstra首次發(fā)明最短路徑算法的時(shí)候,他給出的代碼里沒有一行注釋,即使所有的變量命名都定義得準(zhǔn)確而嚴(yán)謹(jǐn),又有幾個(gè)人能看懂他的算法呢?所以,在重要或者復(fù)雜的地方,都需要詳細(xì)地寫一些注釋,便于看代碼的人清晰地了解你的思路
最后總結(jié)一下:要想寫出自己滿意的代碼,首先不要急于動(dòng)手,要先仔細(xì)想清楚思路性的東西,尤其是數(shù)據(jù)結(jié)構(gòu),然后在實(shí)現(xiàn)過程中大膽嘗試小心驗(yàn)證,設(shè)計(jì)好測試用例,確保代碼的可讀性,就可以在代碼中表現(xiàn)出自己的最高水平但畢竟各人水平是有差異的,自己滿意并不等于其他人欣賞我對(duì)此的看法是,不求盡如人意,但求無愧我心,足矣最后再啰嗦一句,技術(shù)水平是可以慢慢提高的,但是好的編程習(xí)慣需要從一開始就養(yǎng)成,它會(huì)讓你在前進(jìn)的道路上事半功倍,受益終生
【更新】針對(duì)評(píng)論中提到的需求不確定導(dǎo)致設(shè)計(jì)和實(shí)現(xiàn)困難的問題,我又寫了一篇有關(guān)需求分析的文章:《關(guān)于需求分析的幾點(diǎn)體會(huì)》,歡迎批評(píng)指正
本文作者: 伯樂在線 – 老碼農(nóng)
本文鏈接: blog.jobbole.com/47966/
文章編輯: 365webcall網(wǎng)頁客服工具(www.365webcall.com)
我的評(píng)論
| 登錄賬號(hào)： | 密碼： | 快速注冊 | 找回密碼 |  |
