首先是讀文檔。計算機方面有個著名的黑話叫做RTFM，什麼意思呢？按字面翻譯就去“去讀他媽的文檔”，這是在新聞組或者論壇裏可能常見的回覆，一些人嬌滴滴的說“我是妹妹，能指導一下這個問題麼”或者賤兮兮的”跪求某某問題答案”。當然，同事之間不可能搞這些，不過也經常碰到有人問一些感覺非常簡單問題，這些問題實際上都在項目文檔或者軟件規範裏就明白寫着。
一個新人加入某個項目，或者轉換到一個新項目，都會感覺到手足無措，就像老虎吃刺蝟不知如何下嘴。領導不會讓這樣的新人去完成一些複雜模塊的開發或者修改一些相對困難的bug，基本上都是先分一些界面上的小改動，或者是讓他開發耦合程度低一些、相對獨立一些的功能作爲練手，這個時候作爲一個新人就要儘快的掌握整個項目的大概，然後泛讀一下項目的重要文檔。如果要開發某個業內標準的實現軟件，那這個標準的相關文檔至少要通讀一遍，不需要投入很長時間，可以快速掌握一下大概，做做簡單的筆記，不懂的地方先記下來以後有空再說。讀文檔不要作爲一個整體任務完成，可以用一些零碎時間來讀，以免很長時間沒有什麼進展，領導看了還以爲在磨洋工呢。
**注意事項一，儘管有這樣那樣的軟件支持，一支筆一個本子仍然是最方便最快速最實用的學習工具，我幾乎每年都要寫掉八九個大筆記本，裏面寫着項目開發的心得、文檔書籍的感受、領導指示的一些開發問題等等，不需要有什麼文章格式，先寫下來就可以了。
如果是第一次進入公司，項目組長會分一個任務作爲對新人水平的考察，就好比網遊中的新手任務。我們公司大多數的新手任務都是半個月一個月左右的時間，注意要儘量趕在期限結束前完成所有的編碼和單元測試，而且最好完成代碼清理和代碼註釋工作，注意命名規則，這樣看起來比較專業一些。
**注意事項二，接到一個項目第一個要問的就是這個項目結束期限（dead line）是什麼，這樣心裏比較容易對進度有個估計，免得最後無法完成任務。領導可能會反過來諮詢老程序員對分到的項目難度估計。一般來說，估計一個大概的編碼時間，然後把估計時間乘二，留出一定餘量比較好。
讀文檔不要作爲一個整體任務完成，可以用一些零碎時間來讀。實際上接手一個新任務，必須要做的就是理解需求。一個開發人員如何不理解他想做什麼，基本上這個任務一定會失敗。我們高考時候都會寫一篇大作文，對題目的理解非常重要，偏題跑題就沒法拿到高分，開發也是如此。對需求的理解需要反覆的進行，定期和項目組領導或者客戶進行溝通，以免自己做了無用功。但是溝通之前一定要注意，自己先掌握一定的背景知識，比如前面提到的規範文檔，或者是讀一讀已經有的代碼，跑一跑成型的產品，免得問的都是不必要的問題。
搜索一下可以找到一篇題爲”提問的智慧“的文章，裏面介紹如何在網上問問題。其實項目組內溝通也是如此，要注意問有意義的問題。打個比方說，有時候自己會有一種感覺，跑到別人面前，把問題說了一遍，還沒等人回答，突然拍着腦袋說”啊我明白了“，也許是反應挺快，可是還是耽誤了別人的功夫，像這樣的問題，自己組織組織語言或者寫出來，答案就很容易發現。另外也有的人，總是這是怎麼回事那是怎麼回事，其實到搜索引擎一搜或者是把動手做做就知道結果，但是非要張嘴問，這樣的人說得難聽點就是問題不經過大腦，其實一思考就能得到答案了。問問題之前也可以試着理清一下思路，看看前因後果，簡化一下問題模型，也許經過這些方式，自己就能找到答案。有同組的同事問問題，很多時間我反問幾句，把思路理清，他自己就知道答案是什麼了。忘記在哪有看到一個軼事，在某個著名軟件公司裏，開發組的桌上會放着一隻小熊，大家互相問問題之前，先對着小熊把問題說一遍，看能不能把問題描述的清晰，基本上說的比較有條理以後，答案也就隨之而來了，大家可以試試這個辦法。
**注意事項三，提問之前，自己先試圖看看能不能找到答案，我建議的尋找順序是文檔、google，最後纔是張嘴問，問之前最好已經積累了一些材料，比如關於這個問題自己做了什麼研究，搜索了什麼關鍵字等等，這樣問的有誠意，回答纔能有誠意。
另外，對於一個新人，需要多跟老同事溝通，瞭解項目的關鍵點是什麼，比如開發一個通訊程序，用了什麼協議，哪個網站比較有用，哪個文檔需要精讀，都是非常有意義的問題，這些問題可以少走一些彎路。早上到了公司，第一件事是接收業務郵件，然後記下一些需要回復或者要做的工作。郵件閱讀以後，可以跟項目組長做個簡單的溝通，瞭解一下哪個任務或者功能需要快一點完成，交流一下自己的想法，時間花費不多但是可以把一天的任務明確下來。
如果比較努力而且有一定的開發能力，兩三個月以後應該開始接觸到項目比較核心的東西了，這個時候需要做的工作就是讀代碼。一個項目最重要的東西就是代碼，至於文檔、註釋、測試，其實都是保證代碼質量以及代碼可維護型的一種輔助手段，作爲一個開發人員，不熟悉代碼就是致命的錯誤。
讀代碼我這裏有一些簡單的體會。
讀代碼要注意的第一條是從界面開始，深入到功能。打個比方說，一個桌面軟件，其中有個格式轉換功能，可以從菜單選擇”格式轉換“進行操作（注意，所謂格式轉換就是一個例子，沒有實際意義），那麼就可以搜索菜單裏的”格式轉換“，找到相對應的界面函數，這就是一個相對獨立的功能入口點了。然後從這個入口點順藤摸瓜，就可以搞清楚格式轉換這個功能需要的一系列界面函數以及邏輯實現函數。
讀代碼的時候注意要隨時做筆記，可以用word或者是powerpoint這樣的軟件做記錄，搭配一個抓屏軟件抓取界面變化、程序運行棧或者是一些關鍵數據就更好了。
一個相對獨立的功能基本上是由幾個數據類或者數據結構，加上幾個比較重要的邏輯函數實現的，抓住了這些關鍵就抓住了這個功能的核心。比如說一個通訊軟件，重要的就是通訊數據格式和通訊協議實現。經過我的體驗，這個小竅門還是很有用的。一般經常出現問題的也就是這些相對來說複雜一些的函數。
閱讀代碼的同時還要經常問自己一些問題，比如這個地方爲何這樣實現，有沒有其他的方案，哪個方案更好一些等等。這些問題可以讓自己更好的理解當時開發人員的一些想法思路，另外也是將來代碼進行重構的一個鋪墊。
**注意事項四，作爲一個開發人員，多思考是非常必要的一個特質。
一個新人，經過這些階段，基本上可以成爲項目組的中堅力量了，希望每個入行的新人都能成功晉級成爲老手。