點(diǎn)擊關(guān)注公眾號(hào)，Java干貨及時(shí)送達(dá)
點(diǎn)擊上方 Java技術(shù)迷，選擇 設(shè)為星標(biāo)
出品 | CSDN（ID：CSDNnews）
代碼行數(shù)越少越好？讀懂別人的代碼很困難？如何編寫出“完美”的代碼？每天要堅(jiān)持8小時(shí)編程？......拜托，這些編程誤區(qū)程序員應(yīng)該盡早知道！
作為開發(fā)人員，你會(huì)聽到許多有關(guān)“代碼行數(shù)”的令人難以置信的瘋狂理論——不要相信他們！以代碼行數(shù)作為決策依據(jù)是一件非常荒謬的事情。在極少數(shù)情況下，代碼行數(shù)可能還有那么一丁點(diǎn)意義，在絕大數(shù)情況下，代碼行數(shù)什么都代表不了。根據(jù)代碼行數(shù)做決策就好像按照頁數(shù)評(píng)價(jià)書籍的水準(zhǔn)。
有些人可能會(huì)認(rèn)為，應(yīng)用程序中的代碼行越少，就越容易閱讀。這句話只有部分正確，我認(rèn)為代碼可讀性的度量標(biāo)準(zhǔn)包括：
如果減少代碼行數(shù)會(huì)影響到上面任何一條，那么就有問題。實(shí)際上，基本上減少代碼行數(shù)都會(huì)影響到上面的標(biāo)準(zhǔn)，因此總會(huì)出問題。不過，如果你能夠設(shè)法滿足上述條件，那么代碼行數(shù)就是完美的，根本用不著統(tǒng)計(jì)數(shù)量。
“C比X更好，因?yàn)镃的性能更好?！?/span>“Python比X更好，因?yàn)镻ython更簡(jiǎn)潔?！?/span>“Haskell比X更好，因?yàn)镠askell是外星語言?！?/span>
一言以蔽之，比較編程語言本身就是無稽之談。它們是語言，又不是口袋妖怪。別誤會(huì)，語言之間的確有差異，只不過“一無是處”的語言畢竟是少數(shù)（盡管有很多過時(shí)的語言）。每種語言都有其獨(dú)特的優(yōu)點(diǎn)，從這個(gè)角度來說，語言就好像工具箱中的工具。螺絲刀能夠勝任錘子做不到的事情，但是你會(huì)說螺絲刀比錘子好嗎？（顯然錘子更好使）。在談?wù)撊绾卧u(píng)估語言之前，我想先說明一點(diǎn)。在少數(shù)情況下，語言的選擇確實(shí)很重要，某些語言顯然無法處理某些情況。如果你編寫前端代碼，那么連選擇語言的權(quán)利都沒有。在某些特定的情況下，性能很重要，那么就不能選用X語言了，但這種情況很少見。通常，語言的選擇都是項(xiàng)目中最不重要的問題之一。以下是我認(rèn)為在選擇語言時(shí)，你應(yīng)當(dāng)考慮的核心因素（優(yōu)先級(jí)從高到低）：還有一些無法控制的緊密聯(lián)系。如果你從事數(shù)據(jù)科學(xué)工作，那么就需要使用Python、R或Scala（也許是Java）。如果是一個(gè)業(yè)余項(xiàng)目，那么就隨心所欲選擇自己喜歡的。只有一條規(guī)則我覺得沒有商量的余地：如果遇到的大多數(shù)問題都無法通過StackOverflow直接解決，那么我會(huì)拒絕使用這種語言。不是說我沒有解決問題的能力，而是我覺得不值得花那么多時(shí)間。
讀懂別人的代碼是一件困難的事情。Robert C. Martin在“干凈的代碼”中談到了這一點(diǎn)：“實(shí)際上，讀代碼和寫代碼所花費(fèi)的時(shí)間之比遠(yuǎn)超過10：1。在編寫新代碼的時(shí)候，我們一直在閱讀舊代碼。……[因此，]我們的代碼應(yīng)該易于閱讀，易于編寫?！?/span>
很長(zhǎng)一段時(shí)間里，我一直以為自己不善于閱讀別人的代碼。隨著時(shí)間的流逝，我意識(shí)到幾乎每個(gè)程序員每天都在為閱讀別人的代碼而苦惱。閱讀別人的代碼就像學(xué)一門外語。即使你很熟悉某種語言，但仍然需要使用別人的不同風(fēng)格以及體系結(jié)構(gòu)。而且我們一般都會(huì)假設(shè)寫代碼的人貫徹了一致性和可靠性，但有時(shí)并非如此，這確實(shí)是一個(gè)很難克服的問題。但是我發(fā)現(xiàn)了很多有幫助性的技巧。閱讀別人的代碼可以極大地提高你閱讀代碼的能力。在過去的兩年中，我查看了很多Github中的PR。每讀一個(gè)PR，就會(huì)覺得閱讀別人代碼的能力又提高了一點(diǎn)點(diǎn)。Github中的PR特別具有幫助性，原因如下：可以隨時(shí)練習(xí)，只需找到自己想貢獻(xiàn)的開源項(xiàng)目即可。
在一定范圍內(nèi)練習(xí)閱讀別人的代碼（功能性的PR或改bug的PR）。
注意所需的細(xì)節(jié)，努力讀懂每一行。
還有一種對(duì)閱讀別人的代碼有幫助行的技巧，這種技巧更加獨(dú)特。我想到的這種技巧可以大幅減少閱讀陌生代碼庫所需的時(shí)間。在看到我想閱讀的風(fēng)格的代碼后，我首先我會(huì)打開vi，然后開始用項(xiàng)目中使用的風(fēng)格編寫代碼。這樣會(huì)減少對(duì)代碼的陌生感。
在加入團(tuán)隊(duì)工作之前，有4年的時(shí)間里我這個(gè)開發(fā)人員都是“獨(dú)行狼”。在大多數(shù)時(shí)間里，我會(huì)假設(shè)每位程序員編寫的代碼都是完美的。我以為稍加努力和假以時(shí)日，我也會(huì)編寫出“完美”的代碼?！禞ava開發(fā)手冊(cè)（嵩山版）》建議你看下。以前，我曾經(jīng)常常為此而感到焦慮。在加入團(tuán)隊(duì)后，我很快就發(fā)現(xiàn)沒人能夠編寫“完美”的代碼。但是，進(jìn)入系統(tǒng)的代碼幾乎總是“完美”的，為什么會(huì)這樣呢？答案就在于代碼審查。我們團(tuán)隊(duì)擁有非常出色的工程師。他們都是最有能力，最有信心的程序員。如果有人建議提交未經(jīng)審查的代碼，那么我們團(tuán)隊(duì)中的每個(gè)成員（包括我）都會(huì)群起而攻之。即使你覺得自己是下一個(gè)比爾·蓋茨，你也會(huì)犯錯(cuò)。甚至都無需上升到邏輯上的錯(cuò)誤，就連錯(cuò)字、漏字的問題都無法避免，這些都是你的大腦無暇顧及的問題，所以需要由別人來幫你檢查。努力與注重細(xì)節(jié)并樂于指摘你的代碼的人一起工作。雖然剛開始聽到批評(píng)時(shí)，你會(huì)覺得很難受，但這是持續(xù)改進(jìn)的唯一方法。盡最大努力避免在代碼審查過程中產(chǎn)生抵抗情緒，也不要發(fā)表針對(duì)個(gè)人的評(píng)論。努力做到對(duì)事不對(duì)人。審核代碼時(shí)，如果代碼的作者做出的選擇我并不熟悉，那么我會(huì)立即通過Google查看他們的選擇是否與流行觀點(diǎn)不符。我并不是說流行觀點(diǎn)永遠(yuǎn)是對(duì)的，只不過流行觀點(diǎn)是默認(rèn)的選擇。如果有人決定不采納流行的觀點(diǎn)，那也很好啊，只不過我需要知道這是否合理。在審查代碼時(shí)，有一點(diǎn)至關(guān)重要：你必須了解決策背后的基本原理。另外，用“初學(xué)者的頭腦”看同樣的問題，往往可以發(fā)現(xiàn)被這個(gè)人拋諸腦后的東西。4、程序員的工作并不意味著每天要堅(jiān)持8個(gè)小時(shí)的編程一般的開發(fā)人員或“偉大的”開發(fā)人員每天需要做多長(zhǎng)時(shí)間的編程工作呢？這是一個(gè)非常普遍的問題，但是從來沒有人給出明確的答案。每天寫代碼的時(shí)間超過4小時(shí)的人非常少。不贊同這一點(diǎn)的人要么是個(gè)例外，要么公司應(yīng)該珍惜他們。編程是一項(xiàng)耗費(fèi)精力的工作，需要精神高度集中。要求程序員每天寫5-8小時(shí)的代碼是不近人情的做法。在極少數(shù)情況下，為了按時(shí)完成任務(wù)或?yàn)榱思影噘M(fèi)，有人會(huì)延長(zhǎng)工作時(shí)間，但這種情況很少見。其實(shí)我這里說的“極少數(shù)情況”的意思是幾乎沒有。如果由于公司計(jì)劃上的問題或招聘的人手不足而導(dǎo)致你加班，那么請(qǐng)不要容忍。坦白來說，每天編寫8個(gè)小時(shí)的代碼，對(duì)你和公司都沒有好處。如果你的老板有這種要求，那么只能說他目光短淺，因?yàn)閺拈L(zhǎng)期來看，這種高強(qiáng)度的工作對(duì)生產(chǎn)力和心理健康都有惡劣的影響。請(qǐng)注意，我并不是建議你每天只工作4個(gè)小時(shí)。通常，我們應(yīng)該把剩下的4小時(shí)用在如下工作上：除此之外，我強(qiáng)烈建議你在白天的工作時(shí)間里定時(shí)休息并鍛煉身體（即使只是短暫的鍛煉）。事實(shí)證明，運(yùn)動(dòng)對(duì)緩解精神疲勞有很大的幫助。我發(fā)現(xiàn)，我在無法集中精力的時(shí)候，鍛煉特別有幫助。
原文：https://stackoverflow.blog/2019/08/07/what-every-developer-should-learn-early-on/
