成長總是很痛苦的，每天總是不舒適的，尤其是被問到一層又一層的點時，很多人總是說自己精通這個精通那個，實際飄的很，最表面的東西，誰都想得到，能在表象之上想通一個區域性，也是很費功夫，如果能從系統上和全域性上考慮的認少之又少。每一行程式碼的用意的揣摩，每一個細節的深挖，都是需要很痛苦的折騰。你不去深入理解，只是淺層次的實現某個功能，在很多時候，並不能得到別人的認可。因為任何東西寫出來後，希望以後儘量都是少的改動，這樣才有時間做其他事情，否則永遠陷入在惡性迴圈中，Bug永遠解不完，程式碼永遠是那樣千瘡百孔。修也修不過來，下個來維護的人，只能是重寫。所以，如果你在程式碼非常苛刻的公司，恭喜你，你是幸運的。因為當下你確實很痛苦，心也累。但是長遠看，你是受益的。因為你的程式碼可以承受住各種壓力和併發測試。這樣的程式碼會永遠保留下去，而那種一次性程式碼，不到幾天就到垃圾站去了。優秀的程式碼總是驚人的相似，不好的程式碼有是不謀而合。學習優秀程式碼本身就是很費功夫的事。優秀程式碼有它的思想，原則，界限，範圍。能做什麼，不能做什麼。什麼可以暴露，什麼不可以暴露，函式/方法的命令，規範及風格。很多人在進度的壓力下潦草應付，只要測試通過就算搞定。表面上看，開發速度很快，進度有保障；但實際上，這樣的程式連開發者自己都很難讀懂，一旦有bug，很難除錯，將來維護升級都非常困難。這樣的程式碼多半隻能重寫，浪費自然嚴重。如果每個人寫程式的時候當藝術品來寫，寫每行都認認真真、乾乾淨淨的，雖然速度略微慢了一點，但綜合的開發成本會低很多。如何寫像詩一樣美的程式碼呢？雷布斯曾用到過幾個方法：

一、買幾本經典的程式設計書，把書上所有例程全部重新寫一遍，逐個比較和書上範例的差距，一步一步改善自己程式設計的風格和技巧。時間長了，自然就能寫出象書上例程一樣的程式碼，甚至可以比書上寫得好。

二、基礎紮實後，多看看Linux 等系統級的原始碼，看看高手是如何寫的，就有感覺了。

三、通讀一下MSDN中所有的資料，這樣，“讀書破萬卷，下筆如有神”。

還有，一定要牢記軟體工程的鐵律：可能出錯的地方一定會出錯。每個變數都做初始化，引用每個引數都會做有效性檢查，在可能出錯的每個地方都會做邊界條件檢查，這樣開發出來的程式一定會穩固很多，就是出錯也會很容易修改。野路子出來的高手，一般開發速度很快，但做完後bug很多，經常需要很長時間修改。而真正的高手，追求的境界是 bugfree code（零缺陷程式碼）。

我也有一些總結如下：

1、看那些Bug很少的人程式碼，他們的程式碼，每行逐字的讀，用了什麼技巧？有哪些思想？我自己來寫，會想到這些麼？想不到的原因是什麼？基礎不夠紮實？還是有知識黑洞？為什麼要用某個API，而

不用另外一個相近的API？if條件裡的判斷是否也可以想到？重複程式碼巧妙用過變數或求同存異的方式抽離走了。

2、記下別人review後批評點，做人有韌性。批評你的程式碼恰恰說明要有很多要改的地方。當時儘管不爽，過一段時間，review你的程式碼，問題越來越少了，說明你也得到提高了，但是我知道很多公司很少有人逐行逐字程式碼review，出現問題，還是由寫程式碼的人去修。隱式隱藏了潛在的問題以及可能會遇到的問題。

3、對於一個簡單系統API，如Android或是C++庫函式，要去搞清楚侷限，場景，包括引數的邊緣測試。正常邏輯往往不會出問題，都是一些邊緣性導致，如nullptr,越界，單元測試方法健壯性，至少傳入4種以上不同場景引數。有時還伴隨多例項，併發等。是否能順利通過。這樣寫出來的才有自信。系統的API，沒有理解背後的侷限和優缺點，也可能誤用而出問題。

4、字字如刺，每一步都是一步一步淬鍊，成長也是一刀一刀削在心底。然後不斷變得更好。