老碼農的自我修養：如何規劃性的寫出高質量的代碼？分享給你！

 

1. 數據結構和核心算法

關於數據結構的重要性，大神Linus Torvalds講過這樣的話，我以爲很是贊同：」Bad programmers worry about the code. Good programmers worry about data structures and their relationships.」 

（低水平程序員總在考慮代碼，高水平程序員總在考慮數據結構及其之間的關係）

數據結構考慮清楚了，核心的算法天然就出來了，這就是關於每一個類的每一個方法如何實現的問題。好比須要實現一箇中位數查詢方法，若是你前面肯定了數據 保存的格式是一個列表，

那麼你能夠考慮採用插入排序法；若是數據格式是自平衡二叉排序樹（AVL），則只需直接返回根節點就能夠了。

數據結構決定算法，因此你在考慮數據結構的時候，必定要儘量地使數據的結構和它的天然屬性相匹配，否則後面的實現就會是一場噩夢。好比，你把一個 多層級的結構定義成二維數組，

看上去也靠譜，至關於在一個表格裏維護一個組織結構圖，但是當你作到部門增減的時候，本層級的數組元素移動自沒必要說，下面各 個層級的元素移動就很容易亂套，

並且性能不好，可能你寫了2000行代碼還有不少邊界條件會出錯。相反，若是用一個孩子兄弟鏈表來表示這個樹型結構，操做 起來就很是容易，可能100行都足夠了。

2. 功能實現

思路肯定後，實現過程也須要大量的構思活動。碰到你比較熟悉有經驗的領域，你天然能夠輕車熟路，但不免會有一些你不太熟悉的技術須要嘗試。有的同窗 比較排斥這種領域，

做爲一個程序員，最大的挑戰也是最大的樂趣所在，就是不斷學習新的技術，沒有這樣的心態，很快就會落後。

好，那麼遇到不熟悉的技術怎麼辦？個人體會是，先不要急着實現項目中的代碼，本身另外維護一個測試項目，在裏邊邊查文檔邊學習，邊作一個小功能，把 全部須要在項目中實現的功能先在測試項目裏跑通，

而後再寫項目裏的代碼。這樣作的好處是把單個技術問題和其餘潛在的bug隔離開來，便於快速學習新技術。 不然，你直接在項目裏寫代碼出錯之後，要判斷問題的源頭都要多費好幾倍的精力。

 

 

3. 測試

測試很重要，設計測試用例就像開發時設計數據結構同樣，也是很關鍵的。在設計測試用例的時候，要把當時本身設計數據結構的思路所有忘掉，或者找別人 來設計測試用例，

否則會不禁自主地測試那些你已經考慮到了的地方。這樣測試是跑通了，用戶一用起來可能各類邊界條件會處處出問題。

寫到這裏我又想到大神Linus說過的另外一句話：」Regression testing」 What’s that If it compiles, it is good; if it boots up, it is perfect. （「迴歸測試」？這是什麼東西？若是代碼能編譯就是好的，若是它啓動了，那就是完美的。）

固然了，大神水平擺在那裏，他有資本目空一切，咱確實沒資格仿效。可是我仍是以爲TDD也有TDD的問題，測試是很重要，但把它擺到驅動開發的高度，就有點本末倒置了。這個是我本身的一點見解，本人對TDD瞭解得不深刻，若是有謬誤之處，請多多指教。

 

 

4. 代碼可讀性

要想本身滿意，代碼的可讀性必定要好。要作到一年後甚至幾年後你拿到本身寫的代碼，還能很容易看明白當時的思路和實現。這就涉及到命名和註釋的問題。

命名就像超市裏的商品標籤同樣，要讓看得人一目瞭然就知道這是個什麼東西，好比你的員工類裏有兩個屬性分別是到崗日期和離職日期，把它們定義成date1和date2就沒有多少可讀性，而定義成dateOnBoard和dateQuit就比較清晰。

註釋也是很重要的，它能夠用來講明一段代碼的做用，算法的設計思想，或者是方法調用的參數格式要求等。有人以爲命名就是註釋，代碼自己就爲本身代言 了。我以爲這種說法用來強調命名規範的重要性是很好的，

可是所以說不須要註釋則有失偏頗。試想，若是Dijkstra首次發明最短路徑算法的時候，他給出 的代碼裏沒有一行註釋，即便全部的變量命名都定義得準確而嚴謹，又有幾我的能看懂他的算法呢？

因此，在重要或者複雜的地方，都須要詳細地寫一些註釋，便於 看代碼的人清晰地瞭解你的思路。

另外若是你想更好的提高你的編程能力，學好C語言C++編程！彎道超車，快人一步！筆者這裏或許能夠幫到你~

UP在主頁上傳了一些學習C/C++編程的視頻教程，有興趣或者正在學習的小夥伴必定要去看一看哦！會對你有幫助的~

分享（源碼、項目實戰視頻、項目筆記，基礎入門教程）

歡迎轉行和學習編程的夥伴，利用更多的資料學習成長比本身琢磨更快哦！

免費學習書籍：

 

免費學習資料：