軟件開發(fā)需要注意的，都在這兒了

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

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

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

有些人覺得，新項(xiàng)目的代碼越小就會(huì)越易于搞懂，但這一看法只說對(duì)了一小部分。我覺得，有著易讀性的代碼應(yīng)當(dāng)具有下列這類特點(diǎn)：

一致性；

自描述；

保持良好的文檔；

應(yīng)用了穩(wěn)定性的特點(diǎn)；

不會(huì)太繁雜；

特性不會(huì)不好。

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

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

大家常常會(huì)這樣說：

C 語言比某某語言好，是因?yàn)樗�的特性更佳�?/p>

Python 比某某語言好，是因?yàn)樗�更�?jiǎn)約。

Haskell 比某某語言好，是因?yàn)檫@是異類。

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

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

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

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

是否有許多有關(guān)實(shí)例教程；

開發(fā)設(shè)計(jì)速率；

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

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

特性；

容不容易招工。

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

3、瀏覽他人的源代碼是個(gè)煩心事

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

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

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

審查他人的源代碼有利于提高瀏覽源代碼的工作能力。在過去的2年中，我審查了許多 GitHub PR。每審查完1個(gè) PR，我就越能夠融入瀏覽他人的源代碼。GitHub PR 很合適用于提高源代碼閱讀能力，是因?yàn)椋?/p>

隨時(shí)隨地都能夠?qū)彶椋�只需要找到你要想添加的開源項(xiàng)目；

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

需要專業(yè)專注關(guān)鍵點(diǎn)，驅(qū)使你細(xì)心查詢每一列源代碼。

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

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

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

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

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

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

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

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

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

非常少有人每日敲代碼的時(shí)間會(huì)超出 4 個(gè)鐘頭。

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

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

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

做調(diào)查研究；

與同事探討；

幫助他人解決困難；

計(jì)劃以后的工作；

參與編碼審查；

開會(huì)。

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