大多數程式設計師最重要的應該學習什麼？

大多數人以為他們需要學習特定技術、演算法、數學或其他形式的具體知識。但是在Joost看來，這些從來都不是最主要的。最主要的是他們需要學習“ 自律 ”。這是來自What most young programmers need to learn一文的觀點：

過去七年半以來我在Ronimo輔導了很多程式設計實習生，數百名學生和畢業生，在他們身上我看到一樣同樣的東西需要學習，也許有人認為，他們應該是需要學習特定技術、演算法、數學或其他形式的具體知識。但是在Joost看來，這些從來都不是最主要的。最主要的是他們需要學習“ 自律 ”。有紀律地編寫清晰程式碼，有紀律地在程式碼變得混沌時重構它們；有紀律地刪除未使用的程式碼和新增備註。

我在這個主題上花了大部分時間輔導實習生，不是解釋先進的技術或我們的引擎的細節，而是讓他們編寫更好的程式碼，我總是詢問有工作經驗的開發者，他們認為成為優秀程式設計師最重要的是需要什麼？他們通常回答程式碼應該清晰，易於理解和維護。這確實也是我想聽的，但是年輕的程式設計師罕有能始終遵循的。

記住自律，不要停息，如果所有變數的名稱都錯了，但是功能完美，那麼程式碼將超級混亂，從功能程式碼中逐步理清雖然在短期內可能得不到回報，但這就是邁向自律的第一步，這也是作為實習生的好的導師通常非常注意程式碼質量，從而能迫使實習生邁出正確的第一步。

下面是我經常看到的一些例子：

假的函式/變數/類

這些函式類和變數實際做的事情並不是它們名稱的意思所代表的，而是實現其他功能，它們的名字是假的，名不符實，很明顯，名字應該是正確的，但是讓我們驚訝的是很少見完全封閉的名稱。

......
(banq注：快取失效和命名是電腦科學最難的兩件事)

糾結在一起的類

我看到另外一個問題是泥團一樣黏糊在一起的類，做了很多無關的事情，無關的新特性新功能一點點加入，讓簡單的類變得臃腫，塞入各種與該類名無關的行為，有時一個類的大小超過幾百行程式碼。

...

避免這個問題的辦法應該總是想：我在這裡新增的功能符合類名本身嗎？如果不是，那麼重新命名類的名稱，或者分成兩個獨立的類。

如果你不能想出一個程式碼類的合適名稱，就會發出壞味道，那類的內部就會變得混雜。有時可能一個需要分成兩個部分，才能找到合適的名稱分別代表它們。

超大號的類
隨著時間推移，越來越多程式碼新增到一個類，變得非常臃腫，雖然這個類還能工作，但是程式碼太長，非常繁瑣，容易發生很多bug，方向和細節混同在一起。

切分一個非常大的類的工作是枯燥的，也是一個挑戰，類中程式碼高度交織在一起，執行中不斷修復新增新功能，最後結果是必須有自律才能阻止它變得更大。

一般經驗是我們儘量保持類程式碼低於500行，函式低於50行，有時雖然不可行，但是我們總能尋找到辦法來重構它，切分成更小更易於管理的程式碼塊。

程式碼的註釋
如果沒有註釋，代表沒有任何資訊，這是臨時破碎的程式碼嗎？被取代的舊程式碼在哪裡呢？
..

並行邏輯和重複程式碼
舉一個例子，有某個結構特徵的名稱暗示我們一些它是什麼的資訊，比如“TreeBackground.dds”. 為了瞭解這個特徵能被用於一個tree類，我們需要檢查檔名中是否以單詞“Tree”開始. 透過使用 filename.beginsWith(”Tree”)檢查得很快. 這段程式碼如此短，但是我們在不同地方需要它，這樣我們就複製貼上它，這就造成了重複程式碼，當然每個人知道重複程式碼不好，但是這段程式碼真的很短，複製貼上非常容易，我們這裡面臨的問題很明顯：也許以後我們會檢查這個結構特徵是否適合樹tree的改變，那是我們就需要在每個地方單獨一個個去解決(因為這段短程式碼被複制到這些地方)

一般經驗是，這段程式碼不應該被複制，應該放在一個函式中，即使它超級短，主要因為做一個函式再呼叫需要許多程式碼，而直接複製貼上更直接簡單？

本文討論的事情似乎很簡單，它們應該是大學第一年教，但是面臨的挑戰是如何讓他們花時間去遵循，總是記住它們，這就是這為什麼是最重要的事情，他們最應該學習的不是知識，而自律。

大多數程式設計師最重要的應該學習什麼？

相關文章