寫在前面：

這個(gè)文章核心并不是程序優(yōu)化的具體技巧，而是拿到一個(gè)問題如何思考和利用工具的通用方法。比如即使我們不知道 profiler 這個(gè)東西，通過(guò)搜索"代碼 每一行 時(shí)間"也可以很快知道有這樣的工具叫做 profiler，并且學(xué)會(huì)怎么使用。即使不知道 rand 這個(gè)函數(shù)怎么加速，通過(guò)搜索引擎也可以找到別人寫好的現(xiàn)成代碼。另一方面是發(fā)現(xiàn)瓶頸之后也不要著急自己修復(fù)，如果不是特別一目了然的話，先看看別人是怎么做的。站在巨人的肩膀上，事半功倍。

1.多看看「官方文檔」

我們很多的問題和技術(shù)細(xì)節(jié)，其實(shí)，只要我們認(rèn)真將官方文檔過(guò)一遍，會(huì)發(fā)覺大部分的問題和認(rèn)識(shí)模糊的地方都消失了。甚至，你還能發(fā)現(xiàn)自己之前通過(guò)搜索獲得的到一些資料，可能是不準(zhǔn)確或者已經(jīng)過(guò)時(shí)的。官方文檔是真正的好東西，因?yàn)榫帉懳臋n的人群，通常就是這些技術(shù)或者軟件的開發(fā)者，他們才是對(duì)這些東西最了解的人，因此，他們寫的文檔質(zhì)量是很高的，通常也是最新的。

官方文檔的不足的地方，大概是中文版本不多，看起來(lái)可能會(huì)比較吃力。不過(guò)，請(qǐng)相信我，下載一個(gè)翻譯輔助軟件，慢慢看還是可以的。另一方面，就是這些文檔編寫者，通常是技術(shù)界大牛，他們編寫文檔有時(shí)候是基于他們自己的技術(shù)認(rèn)知水平，跳過(guò)了很多基礎(chǔ)概念，也增加了閱讀難度。不過(guò)，這個(gè)我們也可以通過(guò)多查資料，慢慢看來(lái)解決，并且通常會(huì)帶來(lái)額外的學(xué)習(xí)收獲。

2.比官方文檔更重要的是源代碼

看源代碼 1）意味著你可以看到以及學(xué)習(xí)優(yōu)秀的代碼；2）意味著即使源代碼有坑，你也會(huì)提前在大腦有回路更容易找到問題所在。

看不懂源碼意味著不同的幾點(diǎn)：

1）你對(duì)這個(gè)庫(kù)或者代碼的功能不熟悉 (知道某段源碼的功能及特點(diǎn))

2）你不會(huì)用 Debug

3）你的算法基礎(chǔ)薄弱?

4）源碼太過(guò)混亂

你需要反思自己屬于哪一項(xiàng)。針對(duì)其中某一類下藥上來(lái)直接從頭看源碼學(xué)東西一般是不可行的。你需要從上層入侵到下層。先用這段代碼才能看懂源碼。而不是在上層都不熟悉的基礎(chǔ)上開始。任何重復(fù)的代碼/重復(fù)的類似代碼。意味著你框架設(shè)計(jì)有問題，或者開發(fā)語(yǔ)言的表達(dá)能力不夠。

Java 的固定設(shè)計(jì)模式就是 Java 本身表達(dá)能力不夠的表現(xiàn)。流程意味著生命周期，即你不僅需要抽象已知的流程。還需要在未提及的點(diǎn)留下一個(gè)坑 (函數(shù)/接口/鉤子)。往往這些坑在以后的需求變更和項(xiàng)目擴(kuò)展和維護(hù)中是救命的點(diǎn)。日志非常重要，日志環(huán)境也非常重要，debug 是基礎(chǔ)技能，對(duì)應(yīng)的是開發(fā)狀態(tài)。日志則對(duì)應(yīng)穩(wěn)定的線上狀態(tài)。而不能重現(xiàn)的 bug 占整個(gè)開發(fā)的非常多的時(shí)間。所以錯(cuò)誤日志記錄詳細(xì)的環(huán)境意味著你可以更快的重現(xiàn)這個(gè)錯(cuò)誤。

3.提升 debug 的能力

從高層往底層找錯(cuò)

科學(xué)方法

很多新手遇到程序執(zhí)行結(jié)果不對(duì)（尤其是圖形程序員），先認(rèn)為是機(jī)器毛病（浮點(diǎn)精度、硬件故障），然后認(rèn)為是驅(qū)動(dòng)有錯(cuò)，再認(rèn)為是系統(tǒng)有錯(cuò)，最后才開始排查自己的程序。其實(shí) 99% 的情況下是自己程序有錯(cuò)，然后那 1% 里面的 99% 是系統(tǒng)有 bug，再接著那 1% 里的 99% 是驅(qū)動(dòng)有 bug，最后到硬件問題，已經(jīng)微乎其微了。

應(yīng)該從高層往底層查，而不是反過(guò)來(lái)。debug 一般來(lái)說(shuō)是知道現(xiàn)象，但原因未知。這一點(diǎn)和很多自然科學(xué)的情況一樣，所以完全也可以用科學(xué)的方法來(lái)：提假說(shuō)->根據(jù)假說(shuō)做出預(yù)言->做實(shí)驗(yàn)肯定或否定預(yù)言。對(duì)應(yīng)于 debug，那就是假設(shè)是某個(gè)地方有問題，那么推斷它一定會(huì)導(dǎo)致除了你看到的現(xiàn)象之外的其他現(xiàn)象，運(yùn)行程序看你的推斷是否成立。掌握這個(gè)方法后 debug 不在變成瞎找瞎試，而是有跡可循有系統(tǒng)可依賴的方法。

4.重構(gòu)是程序員的主力技能

好多設(shè)計(jì)模式不是提前就設(shè)計(jì)出來(lái)的，而是重構(gòu)出來(lái)的。很多情況是我們?cè)谧鲈O(shè)計(jì)的時(shí)候考慮不到的，是寫代碼時(shí)也考慮不到的，只有在項(xiàng)目上線后，客戶使用過(guò)程中才會(huì)反應(yīng)出來(lái)，這個(gè)時(shí)候就需要對(duì)項(xiàng)目進(jìn)行擴(kuò)展，版本升級(jí)，這時(shí)就體現(xiàn)老程序員實(shí)力的時(shí)候了，就是根據(jù)已有的情形，結(jié)合新的客戶需求，使用合適的設(shè)計(jì)模式，使得代碼能夠優(yōu)雅的擴(kuò)展。

5.先用 profiler 調(diào)查 才有臉談優(yōu)化

如果做.net 代碼的優(yōu)化，也有對(duì)應(yīng)的 Profiler 工具，這個(gè)可以幫我們快速的定位瓶頸在哪里。找到了瓶頸才有接下來(lái)的優(yōu)化工作。

6.一行代碼一個(gè)兵

這里說(shuō)的一個(gè)關(guān)于函數(shù)的規(guī)范問題，有一種說(shuō)法是一個(gè)函數(shù)的內(nèi)容不應(yīng)該超過(guò) 7 行，如果超過(guò) 7 行，那么肯定是把多個(gè) Function 合并到一個(gè)函數(shù)中的，應(yīng)該拆分成多個(gè)函數(shù)。這個(gè)要求可能有點(diǎn)高，很難做到。不過(guò)上百行，上千行的函數(shù)那是不應(yīng)該的，必須拆分！

7.?最好的工具是紙筆 其次好的是 markdown

紙和筆只適用于在 Face 2 Face 的交流過(guò)程中，交流后頂多拍照留存，根本無(wú)法建立有效的知識(shí)庫(kù)，以后想到之前的討論，怎么檢索？怎么修改？。寫 Wiki 才是王道，Markdown 只是一種寫 Wiki 的方式罷了。

8.寧可多算一周 不可少估一天

程序員在估計(jì)工時(shí)的時(shí)候總是太樂觀。隨便開口就是一個(gè)小時(shí)就能搞定，半天就能做完。完全沒有想到該修改對(duì)其他模塊的影響。一個(gè)修改后的單元測(cè)試，可接受測(cè)試，UAT 環(huán)境測(cè)試，再到上線，很多地方都得花時(shí)間的。一旦某個(gè)測(cè)試不通過(guò)，然后又得調(diào)試，修改，再進(jìn)行單元測(cè)試，可接受測(cè)試~~~~，好吧，誰(shuí)能保證每次修改都是一次通過(guò)呢。

9.安裝一個(gè)調(diào)試器（OllyDBG 或者 WinDBG） 并設(shè)置為實(shí)時(shí)調(diào)試器

一但有程序崩潰就攔下來(lái)，除了可以搶救一些數(shù)據(jù)以外，還可以順手分析下崩潰的原因，找找代碼中的壞味道，反省下自己的代碼中哪些設(shè)計(jì)可能會(huì)導(dǎo)致同樣的問題。

10.編碼不要畏懼變化 要擁抱變化

Embace Change 常被許多新手、XPers 和極端主義者當(dāng)作老要不停改代碼（code and fix）、重構(gòu)的一個(gè)偉大借口——擁抱變化，其實(shí)真實(shí)原因是因?yàn)樗麄兊慕?jīng)驗(yàn)不足，分析設(shè)計(jì)能力弱，預(yù)見、預(yù)構(gòu)能力差，導(dǎo)致需求和代碼不穩(wěn)定。

11.注釋是稍差的文檔 更好的是清晰的命名 讓代碼講自己的故事

結(jié)構(gòu)清晰、可讀性好的代碼當(dāng)然很重要。然而對(duì)于許多復(fù)雜系統(tǒng)軟件，常常只有代碼注釋還不夠，更好的文檔其實(shí)是可視化的程序模型，其中包括各種清晰的命名。

12.在動(dòng)手寫代碼前先通過(guò)循環(huán)不變式證明程序正確性

對(duì)待 Bug 絕不能想當(dāng)然, 實(shí)際工程中, 當(dāng)你修正 1 個(gè) Bug, 很有可能會(huì)引起另一系列 Bug 的產(chǎn)生, 類比于雪崩效應(yīng). 再優(yōu)秀的程序也會(huì)有 Bug, Bug 埋藏越久越是致命的, 這就是為什么要先證明正確性以減少潛在 Bug 的出現(xiàn)的可能, 同樣地, 在編碼-調(diào)試-編碼的過(guò)程當(dāng)中修正 Bug 很可能會(huì)導(dǎo)致新 Bug 產(chǎn)生, 致使開發(fā)效率急劇下降. 另外性能也算是 feature. 不達(dá)標(biāo)也算是 Bug. 二八原則在性能上同樣適用, 20% 的代碼決定著程序的總體性能 (Profile 的時(shí)候要記住)。

13.盡量利用語(yǔ)言特性來(lái)保障代碼可靠 避免讓自己產(chǎn)生過(guò)大的心智負(fù)擔(dān)

例如養(yǎng)成用 const 的習(xí)慣，養(yǎng)成多下斷言的習(xí)慣。這個(gè)小 trick 可以讓很多新手程序員快速擺脫「總感覺自己寫的東西哪兒有問題」的感覺。

14.爭(zhēng)取不寫超過(guò) 40 行的程序 如果超過(guò) 20 行 準(zhǔn)備把一些邏輯抽出來(lái)當(dāng)函數(shù)

為何 20 行，為了一些 quick and dirty 的修改做準(zhǔn)備；

這樣 quick and dirty 之后同樣，避免有很多 prop 的 class；

避免不了的話應(yīng)該申請(qǐng)加工資相對(duì)于 forloop，用 index 做遞歸會(huì)稍微易讀一些泛化是好的，只要泛化之后你寫的測(cè)試不超過(guò)百行即可有時(shí)候，你發(fā)現(xiàn)相對(duì)于寫庫(kù)，不如寫 boilerplate 和 snippets 方便 curry 一般只為了一件事情，就是為了調(diào)整參數(shù)次序，讓 default par 在 一些沒有 default value 的 par 前面；

其他時(shí)候主要為了填一些語(yǔ)言設(shè)計(jì)不好的坑。

15.提交代碼之前 diff 回顧一下自己的所有修改

提交之前，用 diff 每一行修改都確認(rèn)清楚是為什么要這樣做，回想一下整個(gè)功能是怎么實(shí)現(xiàn)的、BUG 是怎么解決的。日子久了就會(huì)感覺到自己的每次提交越來(lái)越靠譜了，同時(shí)，版本庫(kù)記錄里面諸如「去掉一行注釋」、「去掉一行調(diào)試代碼」等等也就不會(huì)出現(xiàn)了。

16.避免踩坑

1）不符合 kpi 的需求不接，一個(gè)資深碼農(nóng)是懂得刷選需求的?

2） 一定要搞好監(jiān)控和異常主動(dòng)發(fā)現(xiàn)，監(jiān)控不是那種讓 sa 看看的花架子，資深碼農(nóng)懂得如何刷選監(jiān)控中的有效信息并指導(dǎo) bug 主動(dòng)修復(fù)?

3）對(duì)上下游做到代碼級(jí)別掌握，這樣在甩鍋上可以立于不敗之地，再牛逼點(diǎn)的，可以做到指導(dǎo)上下游開發(fā)的方向，讓上下游來(lái)配合自己完成開發(fā)目標(biāo)?

4）搞好自動(dòng)化測(cè)試和集成測(cè)試，很多老鳥的自動(dòng)化測(cè)試寫的非常有才，場(chǎng)景覆蓋全，業(yè)務(wù)分析清晰，看一份牛逼的代碼，推薦從集成測(cè)試和自動(dòng)測(cè)試入手

來(lái)源：程序人生

總結(jié)

以上是生活随笔為你收集整理的给新手程序员的16个工作必备小妙招，省下时间去LOL吧！的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。