軟體開發的那些真理，上大學時我怎麽就沒記住！

作者丨Ryland

譯者丨無明

策劃丨小智

很多開發者在編程多年以後，總是在實際工作的慘痛教訓中學會了一些本該在大學時期就掌握的軟體開發真理。我太難了，早幹嘛去了……

1

不要太在意“代碼行數”

你可能聽到過很多有關“代碼行數”的瘋狂理論，但請不要把它們當真。基於代碼行數來做技術決策是一件很荒謬的事情。代碼行數能夠為我們提供的信息是很有限的。實際上，在大多數情況下，代碼行數能夠為我們提供的信息為零。基於代碼行數來做技術決策無異於基於一本書的頁數來判斷書的質量。

有人認為，項目的代碼越少就越容易讀懂，但這個觀點隻說對了一部分。我認為，具有可讀性的代碼應該具備以下這些特點：

一致性；

自描述；

良好的文檔；

使用了穩定的特性；

不會太複雜；

性能不會太差。

如果為了減少代碼行數而破壞了這些原則，那才是問題。事實上，如果你盡量去遵循這些原則，代碼行數自然會處在一個很完美的位置，根本不需要特意去計算究竟有多少行代碼。

2

不一定要把編程語言分出“好壞”

人們經常會這樣說：

C 語言比某某語言好，因為它的性能更好。

Python 比某某語言好，因為它更簡潔。

Haskell 比某某語言好，因為它是異類。

使用一句話來評判和比較一門編程語言是對語言本身的侮辱。它們是編程語言，可不是什麽口袋精靈。

編程語言之間確實存在差別，而且很少存在“沒有用”的編程語言（除了那些過時或者已經死掉的語言）。每一門編程語言都在某些方面做出了權衡，它們就像工具箱裡的工具。起子可以做錘子做不到的事情，但你能說起子比錘子更好嗎？

在說出我的編程語言評判標準之前，需要先澄清一個問題。編程語言的選擇很少會對一個項目起到實質性的作用。如果你寫的是前端代碼，選擇不會太多，但通常來說，編程語言的選擇只是決定項目成敗的一個不那麽重要的因素。

以下是我認為在選擇編程語言時需要考慮的一些因素（已經排好序了）：

是不是有很多相關教程；

開發速度；

出現 bug 的幾率；

庫生態系統的質量和廣度；

性能；

好不好招人。

不過，有一些場景是你無法掌控的。例如，如果你是一名數據科學家，那可能就得用 Python、R 語言或 Scala。如果只是一個個人項目，那完全可以選擇使用你喜歡的編程語言。我在選擇編程語言時只有一條原則：如果 StackOverflow 上與這門語言相關的問題不多，我就不會使用這門語言。並不是說遇到問題自己解決不了，而是因為花太多時間在這些問題上面不值得。

3

閱讀別人的代碼是個麻煩事

閱讀別人的代碼其實並非易事。Robert Martin 在《整潔代碼之道》裡提到過這個問題：

事實上，人們花在閱讀代碼和花在寫代碼上的時間比率超過了 10 比 1。閱讀舊代碼是寫新代碼的一個組成部分……所以，容易讀懂的代碼會讓寫新代碼的工作變得更容易些。

有很長一段時間，我被閱讀別人的代碼這件事所困擾。後來發現，其實有很多人都跟我一樣，每天都要面對這個問題。閱讀別人的代碼就像是在閱讀一本用外文寫的書，即使代碼是用你熟悉的語言寫的，代碼的風格和架構仍然會不一樣。這個問題不太好解決，不過我發現下面這些做法可能會對你有所幫助。

評審別人的代碼有助於提升閱讀代碼的能力。在過去兩年中，我評審了很多 GitHub PR。每評審完一個 PR，我就越能夠適應閱讀別人的代碼。GitHub PR 很適合用來提升代碼閱讀能力，因為：

隨時都可以評審，只要找到你想加入的開源項目；

在劃定的範圍內進行練習（一個功能、一個 bug）；

需要專注細節，迫使你仔細查看每一行代碼。

第二種方式有點特別，這也是我一直在踐行的，可以幫我節省很多時間。在了解了某個項目的代碼風格之後，就用這種風格來寫代碼，這樣可以提升閱讀這種風格代碼的能力。因為你已經體驗過類似的風格，所以再去閱讀這樣的代碼就不會感到陌生。

4

不要試圖寫出“完美”的代碼

在加入團隊工作之前，我做了 4 年的“獨行俠”。那個時候，我以為每一個程序員都會寫出完美的代碼，而寫出“完美”的代碼是需要付出時間和努力的。

我曾經為此感到焦慮，但在加入了團隊之後，我才發現，沒有人會寫“完美”的代碼。但為什麽進入到生產環境的代碼總是那麽“完美”呢？答案是：代碼評審。

我所在的團隊裡有很多聰明人，他們都是很有能力且自信的程序員。如果有人膽敢提交未經評審的代碼，他們一定不會善罷甘休。即使你覺得自己是下一個比爾蓋茨，也無法避免犯錯。我說的不單單是邏輯錯誤，還包括拚寫錯誤、丟字元之類的。

爭取與那些願意跟你摳細節和給你意見的人合作。忠言逆耳，但這也是提升自己的一條路徑。在接受代碼評審時要虛心，不要把它跟個人聯繫在一起。別人評審的是你的代碼，而不是針對你。

在評審別人的代碼時，我會用谷歌搜索解決方案，看看代碼的解決方案與流行的解決方案有什麽不一樣的地方。通常，抱著“初學者”的心態會發現更多別人發現不了的問題。

5

程序員並非無時不刻都在寫代碼

這是個很普遍的問題，但從來沒有人能夠給出一個明確的答案。

很少有人每天寫代碼的時間會超過 4 個小時。

如果有人不是這樣的，那說明他們的公司應該對他們更好一些。編程是一項很耗費腦力的活動，一個人一周 5 天、每天 8 個小時都在寫代碼是完全不合理的，除非是為了趕進度，但這種情況不應該是常態。如果一家公司因為管理上的問題或者不想招更多的人而讓你加班，你就沒必要容忍！

其次，即使你每天花 8 個小時寫代碼，對你的公司來說也不一定有好處。你的老闆可能會認為這樣子很好，但其實這是一種短視，因為從長遠來看，這樣做會影響到生產力和員工的健康。

需要說清楚的是，我並不是建議你每天隻工作 4 個小時。另外的 4 個小時你還需要：

做調研；

與同事討論；

幫助別人解決問題；

計劃未來的工作；

參加代碼評審；

開會。

我個人強烈建議每天都要定時休息，做一些運動，哪怕是簡單的運動。我發現，運動有助於緩建精神壓力，幫你更好地集中精神。

https://dev.to/taillogs/what-developers-should-actually-learn-in-college-2ne

今日薦文

Volcano 0.2：持續調度器及作業管理增強