代碼行數越少越好？讀懂別人的代碼很困難？如何編寫出“完美”的代碼？每天要堅持8小時編程？......拜託，這些編程誤區程序員應該儘早知道！
作爲開發人員，你會聽到許多有關“代碼行數”的令人難以置信的瘋狂理論——不要相信他們！以代碼行數作爲決策依據是一件非常荒謬的事情。在極少數情況下，代碼行數可能還有那麼一丁點意義，在絕大數情況下，代碼行數什麼都代表不了。根據代碼行數做決策就好像按照頁數評價書籍的水準。
有些人可能會認爲，應用程序中的代碼行越少，就越容易閱讀。這句話只有部分正確，我認爲代碼可讀性的度量標準包括：
-
代碼應具備一致性
-
代碼應具備自我描述性
-
代碼應具備良好的文檔
-
代碼應使用穩定的現代功能
-
代碼不應過於複雜
-
代碼的性能不能有問題（不要故意編寫速度過慢的代碼）
如果減少代碼行數會影響到上面任何一條，那麼就有問題。實際上，基本上減少代碼行數都會影響到上面的標準，因此總會出問題。不過，如果你能夠設法滿足上述條件，那麼代碼行數就是完美的，根本用不着統計數量。
語言沒有好壞之分
除了PHP（開個玩笑）。
總是有人會說：
“C比X更好，因爲C的性能更好。”
“Python比X更好，因爲Python更簡潔。”
“Haskell比X更好，因爲Haskell是外星語言。”
一言以蔽之，比較編程語言本身就是無稽之談。它們是語言，又不是口袋妖怪。
別誤會，語言之間的確有差異，只不過“一無是處”的語言畢竟是少數（儘管有很多過時的語言）。每種語言都有其獨特的優點，從這個角度來說，語言就好像工具箱中的工具。螺絲刀能夠勝任錘子做不到的事情，但是你會說螺絲刀比錘子好嗎？（顯然錘子更好使）。
在談論如何評估語言之前，我想先說明一點。在少數情況下，語言的選擇確實很重要，某些語言顯然無法處理某些情況。如果你編寫前端代碼，那麼連選擇語言的權利都沒有。在某些特定的情況下，性能很重要，那麼就不能選用X語言了，但這種情況很少見。通常，語言的選擇都是項目中最不重要的問題之一。
以下是我認爲在選擇語言時，你應當考慮的核心因素（優先級從高到低）：
-
在線資源的數量（比如StackOverflow上的問題數量）
-
開發速度
-
出錯的概率
-
軟件包生態系統的質量和廣度
-
性能特徵
-
招聘人才的難度（對不起，COBOL）
還有一些無法控制的緊密聯繫。如果你從事數據科學工作，那麼就需要使用Python、R或Scala（也許是Java）。如果是一個業餘項目，那麼就隨心所欲選擇自己喜歡的。只有一條規則我覺得沒有商量的餘地：如果遇到的大多數問題都無法通過StackOverflow直接解決，那麼我會拒絕使用這種語言。不是說我沒有解決問題的能力，而是我覺得不值得花那麼多時間。
讀懂別人的代碼是一件難事
讀懂別人的代碼是一件困難的事情。Robert C. Martin在“乾淨的代碼”中談到了這一點：
“實際上，讀代碼和寫代碼所花費的時間之比遠超過10：1。在編寫新代碼的時候，我們一直在閱讀舊代碼。……[因此，]我們的代碼應該易於閱讀，易於編寫。”
很長一段時間裏，我一直以爲自己不善於閱讀別人的代碼。隨着時間的流逝，我意識到幾乎每個程序員每天都在爲閱讀別人的代碼而苦惱。
閱讀別人的代碼就像學一門外語。即使你很熟悉某種語言，但仍然需要使用別人的不同風格以及體系結構。而且我們一般都會假設寫代碼的人貫徹了一致性和可靠性，但有時並非如此，這確實是一個很難克服的問題。但是我發現了很多有幫助性的技巧。
閱讀別人的代碼可以極大地提高你閱讀代碼的能力。在過去的兩年中，我查看了很多Github中的PR。每讀一個PR，就會覺得閱讀別人代碼的能力又提高了一點點。Github中的PR特別具有幫助性，原因如下：
-
可以隨時練習，只需找到自己想貢獻的開源項目即可。
-
在一定範圍內練習閱讀別人的代碼（功能性的PR或改bug的PR）。
-
注意所需的細節，努力讀懂每一行。
還有一種對閱讀別人的代碼有幫助行的技巧，這種技巧更加獨特。我想到的這種技巧可以大幅減少閱讀陌生代碼庫所需的時間。在看到我想閱讀的風格的代碼後，我首先我會打開vi，然後開始用項目中使用的風格編寫代碼。這樣會減少對代碼的陌生感。即使我在Github上瀏覽隨機項目，我也會這樣做。一起來試試看吧。
你永遠無法編寫出“完美”的代碼
在加入團隊工作之前，有4年的時間裏我這個開發人員都是“獨行狼”。在大多數時間裏，我會假設每位程序員編寫的代碼都是完美的。我以爲稍加努力和假以時日，我也會編寫出“完美”的代碼。
以前，我曾經常常爲此而感到焦慮。在加入團隊後，我很快就發現沒人能夠編寫“完美”的代碼。但是，進入系統的代碼幾乎總是“完美”的，爲什麼會這樣呢？答案就在於代碼審查。
我們團隊擁有非常出色的工程師。他們都是最有能力，最有信心的程序員。如果有人建議提交未經審查的代碼，那麼我們團隊中的每個成員（包括我）都會羣起而攻之。即使你覺得自己是下一個比爾·蓋茨，你也會犯錯。甚至都無需上升到邏輯上的錯誤，就連錯字、漏字的問題都無法避免，這些都是你的大腦無暇顧及的問題，所以需要由別人來幫你檢查。
努力與注重細節並樂於指摘你的代碼的人一起工作。雖然剛開始聽到批評時，你會覺得很難受，但這是持續改進的唯一方法。盡最大努力避免在代碼審查過程中產生抵抗情緒，也不要發表針對個人的評論。努力做到對事不對人。
審覈代碼時，如果代碼的作者做出的選擇我並不熟悉，那麼我會立即通過Google查看他們的選擇是否與流行觀點不符。我並不是說流行觀點永遠是對的，只不過流行觀點是默認的選擇。如果有人決定不採納流行的觀點，那也很好啊，只不過我需要知道這是否合理。在審查代碼時，有一點至關重要：你必須瞭解決策背後的基本原理。另外，用“初學者的頭腦”看同樣的問題，往往可以發現被這個人拋諸腦後的東西。
程序員的工作並不意味着每天要堅持8個小時的編程
一般的開發人員或“偉大的”開發人員每天需要做多長時間的編程工作呢？這是一個非常普遍的問題，但是從來沒有人給出明確的答案。
每天寫代碼的時間超過4小時的人非常少。
不贊同這一點的人要麼是個例外，要麼公司應該珍惜他們。編程是一項耗費精力的工作，需要精神高度集中。要求程序員每天寫5-8小時的代碼是不近人情的做法。在極少數情況下，爲了按時完成任務或爲了加班費，有人會延長工作時間，但這種情況很少見。其實我這裏說的“極少數情況”的意思是幾乎沒有。如果由於公司計劃上的問題或招聘的人手不足而導致你加班，那麼請不要容忍。
坦白來說，每天編寫8個小時的代碼，對你和公司都沒有好處。如果你的老闆有這種要求，那麼只能說他目光短淺，因爲從長期來看，這種高強度的工作對生產力和心理健康都有惡劣的影響。
請注意，我並不是建議你每天只工作4個小時。通常，我們應該把剩下的4小時用在如下工作上：
-
研發與工作有關以及無關的主題
-
與同事討論工作
-
幫助其他努力工作的同事
-
計劃未來的工作
-
代碼審覈
-
開會
【END】