我是一名移動端程序員，目前已經工作六年多了。

六年的職場生涯，讓我從一個職場小白，到現在從容面對各類工作挑戰。

不禁感歎，時間真是過得飛快，我現在還清晰記得六年前我剛入職時的茫然無措。

最近在讀《程序員的38堂成長課》，感觸頗多，這本書分為五部分：

這五部分每一部分單獨拿出來自成一體，連在一起又相得益彰，覆蓋了大部分程序員成長過程中遇到的問題。

的确，程序員的成長并不是一蹴而就的。它是一個循序漸進的過程，結合此書，我想和大家聊一聊我對于程序員成長的一些看法。

編程乃餘事

編程是一名程序員的本職工作，同時也是最基礎的工作。

但不同程序員對于代碼有不同看法：

• 初級程序員專注于功能實現，堆砌代碼；
• 高級程序員兼顧功能實現與代碼的健壯性，以便後期維護和拓展；
• 架構師則從全局出發，搭建項目架構，制定編碼規則。

可以這麼說，越往上走，你操心的事兒就越多，也更容易開始關注自己的發際線。不過從另一個角度看，如果一個發量不是很樂觀的程序員去面試，很可能被面試官當做專家。

在編碼的過程中，有幾個值得我們注意的地方：編碼規範、測試、bug追蹤、架構演進。處理好這幾方面，對于提升我們的技術工作很有幫助。

1、編碼規範

每一門編程語言都有自己的編碼規範，每個互聯網公司内部也會有自己的編碼規範。

當你入職新公司的時候，首先要做的，就是通過具體的文檔或者項目中現有代碼，來熟悉當前公司的編碼規範，然後盡量與之靠攏并保持一緻。

當然，如果你感覺自己的編碼規範更加合理，也可以提出來，和同事讨論決定，最終使得編碼規範一緻。

2、測試和bug追蹤

艾茲格·迪傑斯特拉說過：“如果調試程序是移除bug的過程，那麼編寫程序就是把bug放進來的過程。”

這裡的測試是指自測，而不是測試人員進行的測試。程序員如果沒有自測，或者敷衍自測流程，那就代碼價值就會越來越低。

保持良好狀态可以防止破壞和犯罪，這就是典型的破窗效應。

《程序員的38堂成長課》給出了多種bug追蹤方案，我覺得還是比較實用的，比如異常捕獲（使用斷言和日志）、二分法、軟件考古（查詢版本控制系統中提交的曆史記錄）、排除法、迂回策略（放空一下再回頭看、說給别人聽）等等。

3、架構演進

架構不是一成不變的，或者說沒有什麼東西是一成不變的。

就像公司的組織架構一樣，有的互聯網公司半年或者一年就會進行一次調整，以便适應公司的發展策略。

項目架構同樣如此，随着業務的驟增或者驟減，原先的架構支撐現有業務已經很吃力，這個時候不可避免就需要進行架構演進。

刻意練習，成就卓越

作為一名程序員，日常工作中，我們或許需要注意這三個方面，以便讓我們工作起來得心應手，事半功倍：

1、刻意練習

作家格拉德威爾在《異類》一書中提出了一萬小時定律。“要成為某個領域的專家，需要10000小時（1.1415525年），按比例計算就是：如果每天工作八個小時，一周工作五天，那麼成為一個領域的專家至少需要五年。這就是一萬小時定律。”

刻意練習是指的是堅持做一件事情，比如每天堅持閱讀優秀源碼并進行總結，想想代碼這樣寫有哪些好處，長此以往，當你再回首看你以前寫的項目代碼時，發現你現在可以僅用三分之一原先的代碼即可完成功能開發，并且更高效，更簡潔、更安全，這就是一個成長的過程，成就卓越的過程。

2、版本控制

版本控制是代碼的時間機器，使得軟件考古更加容易，同時提供了中央備份。它同時支持可逆性，如果發現項目曆史中的任何更改是錯誤的，則可以通過撤銷回滾它。

版本控制系統的演進：

版本控制提交信息應當是清晰、簡潔、明确，這樣便于其他人以及自己以後查找回溯。

3、軟件發布

軟件開發流程就像是一個有機肥料的管道，但又不太正确，因為它不是一個線性過程 。

但實際開發中，這樣是不可取的，主要問題出在程序員開發過程和QA之間的協作，正确的做法應該是緊密結合，程序員開發出一個功能模塊，QA就立馬進行測試，及時反饋，這樣開發人員可以盡早安排修複，以至于在最後期限前交付完美軟件。

束身修行

更聰明而不是更努力的工作。

程序員最好做好如下幾點，保障工作順利進行下去：

1、自測

比如單元測試的開展，即使沒有單元測試，也要有實際測試，避免一些眼高手低的問題

2、明确發布意圖

不要直接把打包的内容發給測試人員，然後随便說一句“看看這個怎麼樣？”應該明确說明此次發布更新了哪些内容，或者修複了哪些bug。讓測試人員可以更好的抓住測試重點，避免做無用功。

3、欲速則不達

不要急于構建發布版本，因為匆忙之下做的決定大部分是不完善的，要做到心中有數。

4、自動化

你可以通過創建一個腳本來自動簽出代碼、進行構建、運行所有單元測試、創建安裝程序和部署到測試服務器，并将構建結果及其版本說明上傳到服務器，這樣就可以消除多個步驟中出現人為錯誤的可能性。

使用自動化來避免人為錯誤，有助于每次都能創建可以正确安裝且不包含回歸的版本，QA人員會因此而感激你。

5、尊重

不要直接将未經測試的軟件交付給測試人員，以免出現尴尬局面。

6、正确看待故障報告

QA人員發布的故障報告，被領導不經意見看到了，這個時候開發人員心理難免會犯嘀咕，你這不是故意找我茬嗎？改變這樣的心态~

計日成功

預防壞習慣比改掉壞習慣要容易得多。

拒絕成為荒島式開發，沒有哪個開發人員應該成為孤島，這樣做太過危險，也太過狹隘，過于拘泥于一個角度看問題，以至于看不到問題的全貌，更不用說去解決它了。

那麼如何解決孤島式開發呢？

• 結對編程，定期與其它程序員進行回顧和代碼評審，以求改進。

• 适當放低個人姿态，勇于和别人交流，接受别人善意的援助。

有時候一個人很容易走進死胡同，這個時候一定要站起來休息一下，喝杯咖啡，然後找個人訴說一下你目前的想法，然後像過電影一樣，這樣子自己很容易就可以找到問題所在，如果實在找不到人，那麼對着辦公桌上面的玩具訴說也是可以的，這個還是它是你的傾訴對象。

多角度思考問題，有時候你想到的第一個方案往往不是最優的，可以發散一下思維，想多種解決方案，從中再選取最優解。

我們解決問題的态度應該是這樣：最有效的解決問題，并且克服本能，不要一個人在那裡低頭蠻幹，走入死胡同而不自知，這個隻會距離解決問題越來越遠，有時候要學會利用團隊的力量。

尋找良師益友

我們是所處環境的産物，就像植物需要土壤和水分，需要一個良好的氛圍健康成長，我們也一樣。

優秀的程序員能夠與同事愉快的合作共事，如果你想變得優秀，那一定要學會和别人通力合作，更要學會取長補短，從善如流。

近朱者赤近墨者黑，要刻意讓自己融入到一群傑出的程序員當中，每天耳濡目染、簡單而又影響深遠，這使得每天都能在編程技巧和态度方面有所積累。

溝通也很重要，與機器溝通，讓機器能夠看懂你編寫的代碼，與評審你代碼的人溝通，代碼就是溝通的橋梁，不要讓你的代碼成為你個人的專屬代碼。

以上就是我讀完這本書之後的一些感悟，共勉！

好書推薦

幽默诙諧，提煉方法和技巧

38個話題，提升你的代碼感