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