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

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

1、不必太在乎“代碼行數”

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

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

一致性；

自描述；

保持良好的文檔；

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

不會太繁雜；

特性不會不好。

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

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

大家常常會這樣說：

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

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

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

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

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

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

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

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

開發(fā)設計速率；

出現 bug 的概率；

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

特性；

容不容易招工。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

做調查研究；

與同事探討；

幫助他人解決困難；

計劃以后的工作；

參與編碼審查；

開會。

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