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++編程的視頻教程，有興趣或者正在學習的小伙伴一定要去看一看哦！會對你有幫助的~
分享（原始碼、專案實戰視頻、專案筆記，基礎入門教程）
歡迎轉行和學習編程的伙伴，利用更多的資料學習成長比自己琢磨更快哦！
免費學習書籍：
免費學習資料：
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/254345.html
標籤：其他
下一篇：躬身入局，弄臟雙手