成長總是很痛苦的，每天總是不舒適的，尤其是被問到一層又一層的點時，很多人總是說自己精通這個精通那個，實際飄的很，表面的東西，誰都想得到，能在表象之上想通一個局部，也是很費功夫，如果能從系統上和全局上考慮的認少之又少。每一行代碼的用意的揣摩，每一個細節的深挖，都是需要很痛苦的折騰。你不去深入理解，只是淺層次的實現某個功能，在很多時候，并不能得到別人的認可。因為任何東西寫出來后，希望以后盡量都是少的改動，這樣才有時間做其他事情，否則永遠陷入在惡性循環中，Bug永遠解不完，代碼永遠是那樣千瘡百孔。修也修不過來，下個來維護的人，只能是重寫。所以，如果你在代碼非常苛刻的公司，恭喜你，你是幸運的。因為當下你確實很痛苦，心也累。但是長遠看，你是受益的。因為你的代碼可以承受住各種壓力和并發測試。這樣的代碼會永遠保留下去，而那種一次性代碼，不到幾天就到垃圾站去了。的代碼總是驚人的相似，不好的代碼有是不謀而合。學習代碼本身就是很費功夫的事。代碼有它的思想，原則，界限，范圍。能做什么，不能做什么。什么可以暴露，什么不可以暴露，函數/方法的命令，規范及風格。很多人在進度的壓力下潦草應付，只要測試通過就算搞定。表面上看，開發速度很快，進度有保障；但實際上，這樣的程序連開發者自己都很難讀懂，一旦有bug，很難調試，將來維護升級都非常困難。這樣的代碼多半只能重寫，浪費自然嚴重。如果每個人寫程序的時候當藝術品來寫，寫每行都認認真真、干干凈凈的，雖然速度略微慢了一點，但綜合的開發成本會低很多。如何寫像詩一樣美的代碼呢？雷布斯曾用到過幾個方法：
一、買幾本經典的編程書，把書上所有例程全部重新寫一遍，逐個比較和書上范例的差距，一步一步改善自己編程的風格和技巧。時間長了，自然就能寫出象書上例程一樣的代碼，甚至可以比書上寫得好。
二、基礎扎實后，多看看Linux 等系統級的源代碼，看看高手是如何寫的，就有感覺了。
三、通讀一下MSDN中所有的資料，這樣，“讀書破萬卷，下筆如有神”。
還有，一定要牢記軟件工程的鐵律：可能出錯的地方一定會出錯。每個變量都做初始化，引用每個參數都會做有效性檢查，在可能出錯的每個地方都會做邊界條件檢查，這樣開發出來的程序一定會穩固很多，就是出錯也會很容易修改。野路子出來的高手，一般開發速度很快，但做完后bug很多，經常需要很長時間修改。而真正的高手，追求的境界是 bugfree code（零缺陷代碼）。
我也有一些總結如下：
1、看那些Bug很少的人代碼，他們的代碼，每行逐字的讀，用了什么技巧？有哪些思想？我自己來寫，會想到這些么？想不到的原因是什么？基礎不夠扎實？還是有知識黑洞？為什么要用某個API，而
不用另外一個相近的API？if條件里的判斷是否也可以想到？重復代碼巧妙用過變量或求同存異的方式抽離走了。
2、記下別人review后批評點，做人有韌性。批評你的代碼恰恰說明要有很多要改的地方。當時盡管不爽，過一段時間，review你的代碼，問題越來越少了，說明你也得到提高了，但是我知道很多公司很少有人逐行逐字代碼review，出現問題，還是由寫代碼的人去修。隱式隱藏了潛在的問題以及可能會遇到的問題。
3、對于一個簡單系統API，如Android或是C++庫函數，要去搞清楚局限，場景，包括參數的邊緣測試。正常邏輯往往不會出問題，都是一些邊緣性導致，如nullptr,越界，單元測試方法健壯性，至少傳入4種以上不同場景參數。有時還伴隨多實例，并發等。是否能順利通過。這樣寫出來的才有自信。系統的API，沒有理解背后的局限和優缺點，也可能誤用而出問題。
4、字字如刺，每一步都是一步一步淬煉，成長也是一刀一刀削在心底。然后不斷變得更好。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
