寫在前面：

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

1.多看看「官方文檔」

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

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

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

看源代碼

1）意味著你可以看到以及學習優秀的代碼；

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

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

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

2）你不會用 Debug

3）你的算法基礎薄弱?

4）源碼太過混亂

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

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

3.提升 debug 的能力

從高層往底層找錯

科學方法

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

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

4.重構是程序員的主力技能

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

5.先用 profiler 調查，才有臉談優化

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

6.一行代碼一個兵

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

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

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

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

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

9.安裝一個調試器（OllyDBG 或者 WinDBG），并設置為實時調試器

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

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

Embace Change 常被許多新手、XPers 和極端主義者當作老要不停改代碼（code and fix）、重構的一個偉大借口——擁抱變化，其實真實原因是因為他們的經驗不足，分析設計能力弱，預見、預構能力差，導致需求和代碼不穩定。

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

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

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

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

13.盡量利用語言特性來保障代碼可靠，避免讓自己產生過大的心智負擔

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

14.爭取不寫超過 40 行的程序，如果超過 20 行 準備把一些邏輯抽出來當函數

為何 20 行，為了一些 quick and dirty 的修改做準備；

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

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

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

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

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

16.避免踩坑

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

2） 一定要搞好監控和異常主動發現，監控不是那種讓 sa 看看的花架子，資深碼農懂得如何刷選監控中的有效信息并指導 bug 主動修復 ；

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

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

最后，再說幾點

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

如果擔心坐太久，正確的做法是多！喝！水！

不要相信產品經理不改需求這種鬼話！

一定要寫注釋！！

用谷歌不用百度

來源：程序人生

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。