許多開發(fā)人員在程序編寫許多年以后，常常在具體工作中的經(jīng)驗教訓中學會了許多本應在大學階段就了解的程序開發(fā)王道。我太難了，早干什么去了……

1、不必太在乎“代碼行數(shù)”

你或是聽見過許多有關“代碼列數(shù)”的瘋狂基礎理論，但請不必把他們當真。根據(jù)代碼列數(shù)來做技術性策略是一件很荒誕的事兒。代碼列數(shù)能夠 為我們出具的信息內容是很有限的。實際上，在大部分情形下，代碼列數(shù)能夠 為我們出具的信息內容為零。根據(jù)代碼列數(shù)來做技術性策略相當于根據(jù)一本書的頁碼來分辨書的品質。

有些人覺得，新項目的代碼越小就會越易于搞懂，但這一看法只說對了一小部分。我覺得，有著易讀性的代碼應當具有下列這類特點：

一致性；

自描述；

保持良好的文檔；

應用了穩(wěn)定性的特點；

不會太繁雜；

特性不會不好。

假如是因為減小代碼列數(shù)而損壞了這類規(guī)范，那才算是疑問。實際上，假如你盡可能去遵照這類規(guī)范，代碼列數(shù)自然會處于1個很極致的位子，壓根不用刻意去測算到底有多少行代碼。

2、并不一定要把開發(fā)語言區(qū)分“優(yōu)劣”

大家常常會這樣說：

C 語言比某某語言好，是因為它的特性更佳。

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

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

應用一段話來評定和對比一種開發(fā)語言是對語言其本身的抵毀。他們是開發(fā)語言，并不一定什么口袋精靈。

開發(fā)語言相互之間的確存有差異，并且極少存有“沒有用”的開發(fā)語言（除開一些落伍或是早已死了的語言）。每一種開發(fā)語言都是在一些層面做到了衡量，他們就如同工具箱里的工具。起子能夠 做鐵錘沒法做到的事兒，但你能夠說起子比鐵錘更佳嗎？

在講出我的開發(fā)語言評定規(guī)范之前，必須先弄清楚1個疑問。開發(fā)語言的挑選極少會對1個新項目起著實際性的功能。假如你寫的是前端開發(fā)代碼，挑選不會過多，但一般而言，開發(fā)語言的挑選僅僅取決于新項目成功與失敗的1個不那樣關鍵的要素。

下列就是我覺得在挑選開發(fā)語言時必須考慮到的許多要素（早已排好序了）：

是否有許多有關實例教程；

開發(fā)設計速率；

出現(xiàn) bug 的概率；

庫生態(tài)系統(tǒng)的品質和深度廣度；

特性；

容不容易招工。

只不過，有許多場景是你沒辦法操控的。比如說，假如你是一位大數(shù)據(jù)工程師，那或是就要用 Python、R 語言或 Scala。假如僅僅1個個體新項目，那完全能夠 挑選應用你最喜歡的開發(fā)語言。我在挑選開發(fā)語言時僅有一條規(guī)范：假如 StackOverflow 上與這門語言有關的疑問不多，我便不會應用這門語言。并不一定說碰到疑問自身搞不定，只是是因為花過多時間在這類疑問上面不怎么值得。

3、瀏覽他人的源代碼是個煩心事

瀏覽他人的源代碼我覺得并非易事。Robert Martin 在《整潔源代碼之道》里提及過這一難題：

實際上，大家花在瀏覽源代碼和花在敲代碼上的時間比例超出了 10 比 1。瀏覽舊源代碼是寫新源代碼的1個組成部分……因此，容易讀懂的源代碼會讓寫新源代碼的工作變得更容易些。

有很長一段時間，我被瀏覽他人的源代碼這件事情所困惑。以后發(fā)覺，我覺得有很多人都跟我一樣，每日必須應對這一難題。瀏覽他人的源代碼就好像在瀏覽1本用外文寫的書，即便源代碼是用你熟知的語言寫的，源代碼的設計風格和構架依然會不太一樣。這一難題不大好處理，但是我發(fā)現(xiàn)了下邊這類做法將會會對你有一定的協(xié)助。

審查他人的源代碼有利于提高瀏覽源代碼的工作能力。在過去的2年中，我審查了許多 GitHub PR。每審查完1個 PR，我就越能夠融入瀏覽他人的源代碼。GitHub PR 很合適用于提高源代碼閱讀能力，是因為：

隨時隨地都能夠審查，只需要找到你要想添加的開源項目；

在規(guī)定的范圍之內開展訓練（1個功能、1個 bug）；

需要專業(yè)專注關鍵點，驅使你細心查詢每一列源代碼。

第二類方法有點兒特殊，這同樣是我一直都在樹立的，能夠給我節(jié)約許多時間。在掌握了某一項目的源代碼設計風格以后，就用這類設計風格來敲代碼，如此能夠提高瀏覽這類設計風格源代碼的工作能力。由于你早已感受過相似的設計風格，因此再去瀏覽如此的源代碼就不會感覺生疏。

4、不必嘗試編寫“完美無缺”的源代碼

一些時候，原以為每1個程序猿都是會編寫完美無缺的源代碼，而編寫“完美無缺”的源代碼是需要支付時間和支付的。

曾經(jīng)的我因此感覺焦慮，但在添加了團隊以后，我才發(fā)覺，沒有人會寫“完美無缺”的源代碼。但為什么進入到生產環(huán)境的源代碼總是那么“完美無缺”呢？答案是：源代碼審查。

我所處的團隊里有許多聰明人，他們全部都是很有工作能力且有信心的程序猿。假如有人膽敢遞交未經(jīng)許可審查的源代碼，他們必定不會善罷甘休。即便你感覺自身是另一個比爾蓋茨，也沒法防止犯錯誤。我講的不單是邏輯性錯誤，還包含拼寫錯誤、丟字符這類的。

取得與一些樂意跟你摳關鍵點和給你建議的人協(xié)作。忠言逆耳，但這同樣是提高自己的1條路徑。在接收源代碼審查時要謙虛，不必把它跟個體聯(lián)系在一起。他人審查的就是你的源代碼，而并不是專門針對你。

在審查他人的源代碼時，我會用谷歌搜索引擎解決方法，看一下源代碼的解決方法與時興的解決方法有哪些不同之處。一般而言，懷著“初學者”的心理狀態(tài)會發(fā)覺很多他人發(fā)覺不上的難題。

5、程序猿并不是無時不刻都在敲代碼

它是個很常見的問題，但幾乎沒人可以列出1個清晰的答案。

非常少有人每日敲代碼的時間會超出 4 個鐘頭。

假如有人并非這樣的，那說明他們的企業(yè)應當對他們更好一點。程序編寫是一項很消耗頭腦的活動，一個人一星期 5 天、每日 8 個鐘頭都是在敲代碼是根本不科學的，除非是是以便趕項目進度，但這樣的事情不應當是常態(tài)化。假如一所企業(yè)由于管理上的問題或是不愿招更多的人而讓你加班加點，那就沒有必要忍受！

另一方面，即便你每天花費 8 個鐘頭敲代碼，對你的企業(yè)而言也未必有益處。你的老總很有可能會覺得這樣子非常好，但我覺得它是一類短視，由于從長久看來，這樣做會危害到生產力和職工的身心健康。

需要說清晰的是，我并非提議你每日只工作 4 個鐘頭。此外的 4 個鐘頭你還需要：

做調查研究；

與同事探討；

幫助他人解決困難；

計劃以后的工作；

參與編碼審查；

開會。

我本人強烈要求每日必須按時歇息，做一點健身運動，即使是簡易的健身運動。我發(fā)現(xiàn)了，健身運動有利于緩建心理壓力，幫你能夠更好地集中精神實質。