萬事開頭難，無論是科班還是非科班出身的程序員，最難熬的是最初的半年，畢竟從一個門外漢轉化成一個真正的程序員最難的就是過渡期。
不管是科班、非科班（自學、培訓），剛入行大家心中都是忐忑的，工作時刻處於崩潰邊緣，晚上下班回家自顧自的惡補基礎知識，好讓自己挺過了試用期。
那我們應該無論通過試用期呢？我們知識點可能不能做到面面俱到，但是絮叨問題要有自己的解決思路，比如：
即使我們不知道 profiler 這個東西，通過搜索"代碼 每一行 時間"也可以很快知道有這樣的工具叫做 profiler，並且學會怎麼使用；
即使不知道 rand 這個函數怎麼加速，通過搜索引擎也可以找到別人寫好的現成代碼；
……
我們要的是，站在巨人的肩膀上，事半功倍。以下的幾點方法技巧，請別客氣的全部收下喲~
萬事開頭難，無論是科班還是非科班出身的程序員，最難熬的是最初的半年，畢竟從一個門外漢轉化成一個真正的程序員最難的就是過渡期。
不管是科班、非科班（自學、培訓），剛入行大家心中都是忐忑的，工作時刻處於崩潰邊緣，晚上下班回家自顧自的惡補基礎知識，好讓自己挺過了試用期。
那我們應該無論通過試用期呢？我們知識點可能不能做到面面俱到，但是絮叨問題要有自己的解決思路，比如：
即使我們不知道 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 調查
先用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 每一行修改都確認清楚是為什麼要這樣做，回想一下整個功能是怎麼實現的、BUG 是怎麼解決的。日子久了就會感覺到自己的每次提交越來越靠譜了，同時，版本庫記錄裡面諸如「去掉一行註釋」、「去掉一行調試代碼」等等也就不會出現了。
16.避免踩坑
1）不符合 kpi 的需求不接，一個資深碼農是懂得刷選需求的；
2） 一定要搞好監控和異常主動發現，監控不是那種讓 sa 看看的花架子，資深碼農懂得如何刷選監控中的有效信息並指導 bug 主動修復；
3）對上下游做到代碼級別掌握，這樣在甩鍋上可以立於不敗之地，再牛逼點的，可以做到指導上下游開發的方向，讓上下游來配合自己完成開發目標；
4）搞好自動化測試和集成測試，很多老鳥的自動化測試寫的非常有才，場景覆蓋全，業務分析清晰，看一份牛逼的代碼，推薦從集成測試和自動測試入手。
17.心態擺正
企業的程序員是要解決實際客戶的問題，面對實際的問題首先要能解決而且還要不留下後遺症，要學會任務管理，先做好該做的事。
遇到問題先不要慌，大膽假設，小心求證，認真幹；工作之餘，給自己充充電，手不釋卷，方得成長。
我自己是一名從事了多年開發的java老程序員，辭職目前在做自己的java私人定製課程，今年年初我花了一個月整理了一份最適合2019年學習的java學習乾貨，從最基礎的javase到spring各種框架都有整理，送給每一位java小夥伴，想要獲取的可以關注我的頭條號並在後臺私信我：java，即可免費獲取。