寫在前面：

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

1.多看看「官方文檔」

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

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

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

看源代碼

1）意味著你可以看到以及學(xué)習(xí)優(yōu)秀的代碼；

2）意味著即使源代碼有坑，你也會提前在大腦有回路更容易找到問題所在。

看不懂源碼意味著不同的幾點：

1）你對這個庫或者代碼的功能不熟悉 (知道某段源碼的功能及特點)

2）你不會用 Debug

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

4）源碼太過混亂

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

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

3.提升 debug 的能力

從高層往底層找錯

科學(xué)方法

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

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

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

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

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

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

6.一行代碼一個兵

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16.避免踩坑

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

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

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

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

最后，再說幾點

把覺得不靠譜的需求放到最后做，很可能到時候需求就變了~

如果擔(dān)心坐太久，正確的做法是多！喝！水！

不要相信產(chǎn)品經(jīng)理不改需求這種鬼話！

一定要寫注釋！！

用谷歌不用百度

來源：程序人生

總結(jié)

以上是生活随笔為你收集整理的给新手程序猿的16个必备小妙招的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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