很多開發(fā)者在編程多年以后，總是在實(shí)際工作的慘痛教訓(xùn)中學(xué)會(huì)了一些本該在大學(xué)時(shí)期就掌握的軟件開發(fā)真理。我太難了，早干嘛去了……

1、不要太在意“代碼行數(shù)”

你可能聽到過很多有關(guān)“代碼行數(shù)”的瘋狂理論，但請(qǐng)不要把它們當(dāng)真?；诖a行數(shù)來做技術(shù)決策是一件很荒謬的事情。代碼行數(shù)能夠?yàn)槲覀兲峁┑男畔⑹呛苡邢薜?。?shí)際上，在大多數(shù)情況下，代碼行數(shù)能夠?yàn)槲覀兲峁┑男畔榱??；诖a行數(shù)來做技術(shù)決策無異于基于一本書的頁數(shù)來判斷書的質(zhì)量。

有人認(rèn)為，項(xiàng)目的代碼越少就越容易讀懂，但這個(gè)觀點(diǎn)只說對(duì)了一部分。我認(rèn)為，具有可讀性的代碼應(yīng)該具備以下這些特點(diǎn)：

• 一致性；
• 自描述；
• 良好的文檔；
• 使用了穩(wěn)定的特性；
• 不會(huì)太復(fù)雜；
• 性能不會(huì)太差。

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

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

 

 

人們經(jīng)常會(huì)這樣說：

C 語言比某某語言好，因?yàn)樗男阅芨谩?/span>

Python 比某某語言好，因?yàn)樗?jiǎn)潔。

Haskell 比某某語言好，因?yàn)樗钱愵悺?/span>

使用一句話來評(píng)判和比較一門編程語言是對(duì)語言本身的侮辱。它們是編程語言，可不是什么口袋精靈。

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

在說出我的編程語言評(píng)判標(biāo)準(zhǔn)之前，需要先澄清一個(gè)問題。編程語言的選擇很少會(huì)對(duì)一個(gè)項(xiàng)目起到實(shí)質(zhì)性的作用。如果你寫的是前端代碼，選擇不會(huì)太多，但通常來說，編程語言的選擇只是決定項(xiàng)目成敗的一個(gè)不那么重要的因素。

以下是我認(rèn)為在選擇編程語言時(shí)需要考慮的一些因素（已經(jīng)排好序了）：

• 是不是有很多相關(guān)教程；
• 開發(fā)速度；
• 出現(xiàn) bug 的幾率；
• 庫生態(tài)系統(tǒng)的質(zhì)量和廣度；
• 性能；
• 好不好招人。

不過，有一些場(chǎng)景是你無法掌控的。例如，如果你是一名數(shù)據(jù)科學(xué)家，那可能就得用 Python、R 語言或 Scala。如果只是一個(gè)個(gè)人項(xiàng)目，那完全可以選擇使用你喜歡的編程語言。我在選擇編程語言時(shí)只有一條原則：如果 StackOverflow 上與這門語言相關(guān)的問題不多，我就不會(huì)使用這門語言。并不是說遇到問題自己解決不了，而是因?yàn)榛ㄌ鄷r(shí)間在這些問題上面不值得。

3、閱讀別人的代碼是個(gè)麻煩事

 

 

閱讀別人的代碼其實(shí)并非易事。Robert Martin 在《整潔代碼之道》里提到過這個(gè)問題：

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

有很長(zhǎng)一段時(shí)間，我被閱讀別人的代碼這件事所困擾。后來發(fā)現(xiàn)，其實(shí)有很多人都跟我一樣，每天都要面對(duì)這個(gè)問題。閱讀別人的代碼就像是在閱讀一本用外文寫的書，即使代碼是用你熟悉的語言寫的，代碼的風(fēng)格和架構(gòu)仍然會(huì)不一樣。這個(gè)問題不太好解決，不過我發(fā)現(xiàn)下面這些做法可能會(huì)對(duì)你有所幫助。

評(píng)審別人的代碼有助于提升閱讀代碼的能力。在過去兩年中，我評(píng)審了很多 GitHub PR。每評(píng)審?fù)暌粋€(gè) PR，我就越能夠適應(yīng)閱讀別人的代碼。GitHub PR 很適合用來提升代碼閱讀能力，因?yàn)椋?/span>

• 隨時(shí)都可以評(píng)審，只要找到你想加入的開源項(xiàng)目；
• 在劃定的范圍內(nèi)進(jìn)行練習(xí)（一個(gè)功能、一個(gè) bug）；
• 需要專注細(xì)節(jié)，迫使你仔細(xì)查看每一行代碼。

第二種方式有點(diǎn)特別，這也是我一直在踐行的，可以幫我節(jié)省很多時(shí)間。在了解了某個(gè)項(xiàng)目的代碼風(fēng)格之后，就用這種風(fēng)格來寫代碼，這樣可以提升閱讀這種風(fēng)格代碼的能力。因?yàn)槟阋呀?jīng)體驗(yàn)過類似的風(fēng)格，所以再去閱讀這樣的代碼就不會(huì)感到陌生。

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

在加入團(tuán)隊(duì)工作之前，我做了 4 年的“獨(dú)行俠”。那個(gè)時(shí)候，我以為每一個(gè)程序員都會(huì)寫出完美的代碼，而寫出“完美”的代碼是需要付出時(shí)間和努力的。

我曾經(jīng)為此感到焦慮，但在加入了團(tuán)隊(duì)之后，我才發(fā)現(xiàn)，沒有人會(huì)寫“完美”的代碼。但為什么進(jìn)入到生產(chǎn)環(huán)境的代碼總是那么“完美”呢？答案是：代碼評(píng)審。

我所在的團(tuán)隊(duì)里有很多聰明人，他們都是很有能力且自信的程序員。如果有人膽敢提交未經(jīng)評(píng)審的代碼，他們一定不會(huì)善罷甘休。即使你覺得自己是下一個(gè)比爾蓋茨，也無法避免犯錯(cuò)。我說的不單單是邏輯錯(cuò)誤，還包括拼寫錯(cuò)誤、丟字符之類的。

爭(zhēng)取與那些愿意跟你摳細(xì)節(jié)和給你意見的人合作。忠言逆耳，但這也是提升自己的一條路徑。在接受代碼評(píng)審時(shí)要虛心，不要把它跟個(gè)人聯(lián)系在一起。別人評(píng)審的是你的代碼，而不是針對(duì)你。

在評(píng)審別人的代碼時(shí)，我會(huì)用谷歌搜索解決方案，看看代碼的解決方案與流行的解決方案有什么不一樣的地方。通常，抱著“初學(xué)者”的心態(tài)會(huì)發(fā)現(xiàn)更多別人發(fā)現(xiàn)不了的問題。

5、程序員并非無時(shí)不刻都在寫代碼

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

很少有人每天寫代碼的時(shí)間會(huì)超過 4 個(gè)小時(shí)。

如果有人不是這樣的，那說明他們的公司應(yīng)該對(duì)他們更好一些。編程是一項(xiàng)很耗費(fèi)腦力的活動(dòng)，一個(gè)人一周 5 天、每天 8 個(gè)小時(shí)都在寫代碼是完全不合理的，除非是為了趕進(jìn)度，但這種情況不應(yīng)該是常態(tài)。如果一家公司因?yàn)楣芾砩系膯栴}或者不想招更多的人而讓你加班，你就沒必要容忍！

其次，即使你每天花 8 個(gè)小時(shí)寫代碼，對(duì)你的公司來說也不一定有好處。你的老板可能會(huì)認(rèn)為這樣子很好，但其實(shí)這是一種短視，因?yàn)閺拈L(zhǎng)遠(yuǎn)來看，這樣做會(huì)影響到生產(chǎn)力和員工的健康。

需要說清楚的是，我并不是建議你每天只工作 4 個(gè)小時(shí)。另外的 4 個(gè)小時(shí)你還需要：

• 做調(diào)研；
• 與同事討論；
• 幫助別人解決問題；
• 計(jì)劃未來的工作；
• 參加代碼評(píng)審；
• 開會(huì)。

我個(gè)人強(qiáng)烈建議每天都要定時(shí)休息，做一些運(yùn)動(dòng)，哪怕是簡(jiǎn)單的運(yùn)動(dòng)。我發(fā)現(xiàn)，運(yùn)動(dòng)有助于緩建精神壓力，幫你更好地集中精神。