如何寫好代碼

作者:金蝶中間件公司CTO袁紅崗

不知不覺做軟件已經做了十年,有成功的喜悅,也有失敗的痛苦,但總不敢稱自己是高手, 因爲和我心目中真正的高手們比起來,還差的太遠。世界上並沒有成爲高手的捷徑,但一些基 本原則是可以遵循的。

  1. 紮實的基礎。數據結構、離散數學、編譯原理,這些是所有計算機科學的基礎,如果 不掌握他們,很難寫出高水平的程序。據我的觀察,學計算機專業的人比學其他專業的人更能 寫出高質量的軟件。程序人人都會寫,但當你發現寫到一定程度很難再提高的時候,就應該想 想是不是要回過頭來學學這些最基本的理論。不要一開始就去學OOP,即使你再精通OOP,遇到 一些基本算法的時候可能也會束手無策。

  2. 豐富的想象力。不要拘泥於固定的思維方式,遇到問題的時候要多想幾種解決問題的 方案,試試別人從沒想過的方法。豐富的想象力是建立在豐富的知識的基礎上,除計算機以外 ,多涉獵其他的學科,比如天文、物理、數學等等。另外,多看科幻電影也是一個很好的途徑 。

  3. 最簡單的是最好的。這也許是所有科學都遵循的一條準則,如此複雜的質能互換原理 在愛因斯坦眼裏不過是一個簡單得不能再簡單的公式:E=mc^2。簡單的方法更容易被人理解, 更容易實現,也更容易維護。遇到問題時要優先考慮最簡單的方案,只有簡單方案不能滿足要 求時再考慮複雜的方案。

讀林斌博士寫好代碼十個祕訣

軟件的質量屬性

魯棒 - Solid and Robust Code
簡潔 - Maintainable and Simple Code
高效 - Fast Code
簡短 - Small Code
共享 - Re-usable Code
可測試 - Testable Code
可移植 - Portable Code

集百家之長, 歸我所用 - Follow Basic Coding Style
1.代碼能夠清晰的表達你的思路
2.代碼應該具備自解釋能力,註釋代碼別是單純解釋語句,這種註釋毫無疑義
3.編碼的縮進和排版規範
4.所有的函數和變量應有他人容易理解的名字
5.將Tab鍵改用爲4個空格字符
6.減少但個函數的長度,控制在50-100行以內
7.避免幻數,多使用枚舉和常量的定義

取個好名字 - Use Naming Conventions
1.採用匈牙利命名法對變量進行命名
2.名字要清晰表達含義,不要怕長

凌波微步, 未必摔跤 - Evil goto’s? Maybe Not…
1.goto的使用應該遵循原則,而不是全盤否定
2.不用寫高深晦澀的語句,不要一味追求性能忽視代碼可讀性
3.模式並不是一味正確,特定問題更需要考慮反模式

先發制人, 後發制於人- Practice Defensive Coding
1.儘量保持代碼的簡潔和簡單
2.調用其它接口和函數時候首先對返回值進行檢查
3.避免有符號/無符號,32位/16位,被零除等誤算情況

見招拆招, 滴水不漏 - Handle The Error Cases: They Will Occur!
1.通過異常處理機制來保證程序代碼的健壯性
2.異常處理中一定要注意資源的釋放
3.異常處理要關注日誌的詳細記錄,便於後續BUG分析
4.不用把後臺編碼或系統異常直接拋給用戶

熟習劍法刀術, 所向無敵 - Learn Win32 API Seriously
1.Win32 API是微軟平臺編程根本
2.對系統強大的公用類庫的熟悉和整理將事半功倍

雙手互搏, 無堅不摧 - Test, but don’t stop there
1.如果你沒有進行測試,你完成的代碼將僅僅是個半成品
2.儘可能多的對自己的代碼進行測試
3.編碼人員應該更專注於百盒測試和單元測試
4.要善於使用JUnit,NUnit,PureCoverage,Compuware,NCover等測試工具
5.相互間的Review和走查是對代碼可維護性的重要測試手段
6.有特殊性能要求時候需要對相關功能或模塊單獨進行性能測試

活用段言 - Use, don’t abuse, assertions
1.斷言可以很好的描述假設和不可能的情況
2.斷言對程序Debug很有用,可以儘早的發現程序問題

草木皆兵, 不可大意 - Avoid Assumptions
1.考慮到用戶使用的各種場景
2.不用假設用戶會正確輸入數據,要做好各種完整性和邊界的檢驗
3.程序中70%左右代碼是爲了保證這種完整性服務的,正常條件下功能可能30%代碼就實現了

最高境界, 無招勝有招 - Stop writing so much code
1.一味拷貝粘貼代碼就是在製造拷貝BUG,這種代碼對系統無任何意義
2.編碼過程注意重用,函數級->組件級->系統級
3.通過重構持續改進代碼質量,改進自我邏輯思維

最後總結下:
1.養成良好編碼習慣,你面試的一小段代碼可能就足一展現你全部陋習。
2.熟練使用好各種輔助工具,但不要全部依賴工具,最主要是學習分析和設計的思考方式
3.注重單元測試,關注程序性能,可維護性,可測試性是編碼技能提升重要手段
4.通過重構使編碼過程形成完整閉環的反饋迴路,重構能力可以很好體現自己的設計能力
5.養成良好習慣,形成自己的編碼過程檢查單,多請教老員工可
  4. 不鑽牛角尖。當你遇到障礙的時候,不妨暫時遠離電腦,看看窗外的風景,聽聽輕音 樂,和朋友聊聊天。當我遇到難題的時候會去玩遊戲,而且是那種極暴力的打鬥類遊戲,當負 責遊戲的那部分大腦細胞極度亢奮的時候,負責編程的那部分大腦細胞就得到了充分的休息。 當重新開始工作的時候,我會發現那些難題現在竟然可以迎刃而解。

  5. 對答案的渴求。人類自然科學的發展史就是一個渴求得到答案的過程,即使只能知道 答案的一小部分也值得我們去付出。只要你堅定信念,一定要找到問題的答案,你纔會付出精 力去探索,即使最後沒有得到答案,在過程中你也會學到很多東西。

  6. 多與別人交流。三人行必有我師,也許在一次和別人不經意的談話中,就可以迸出靈 感的火花。多上上網,看看別人對同一問題的看法,會給你很大的啓發。

  7. 良好的編程風格。注意養成良好的習慣,代碼的縮進編排,變量的命名規則要始終保 持一致。大家都知道如何排除代碼中錯誤,卻往往忽視了對註釋的排錯。註釋是程序的一個重 要組成部分,它可以使你的代碼更容易理解,而如果代碼已經清楚地表達了你的思想,就不必 再加註釋了,如果註釋和代碼不一致,那就更加糟糕。

  8. 韌性和毅力。這也許是”高手”和一般程序員最大的區別。A good programming is 99 weat and 1ffee。高手們並不是天才,他們是在無數個日日夜夜中磨練出來的。成功能給 我們帶來無比的喜悅,但過程卻是無比的枯燥乏味。你不妨做個測試,找個10000以內的素數 表,把它們全都抄下來,然後再檢查三遍,如果能夠不間斷地完成這一工作,你就可以滿足這 一條。
 
  這些是我這幾年程序員生涯的一點體會,希望能夠給大家有所幫助。

發佈了21 篇原創文章 · 獲贊 33 · 訪問量 7萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章