今天看了《布道之道》，裡面有些提到的很多經驗的確很實用。不僅又想起了，在剛剛參加工作時，在第一家公司裡就進行了如何提高溝通效率的培訓。當時很多都以自身的經歷，說明了溝通的重要性，也分享了一些溝通技巧。前幾天，有新同事加入到專案中，來參與其中乙個日誌分析軟體模組的開發。這次，我並沒有親自給他講解，而是讓之前參與到這個專案的另外乙個同事給他講解。我只是在一旁靜靜地聽他們之間的交談，同時我也在思考如何可以讓新同事快速地融入到專案中。
新同事的學習和領悟能力自然是非常重要，然而乙個好的「師傅」能夠帶他進門，也會極大降低學習的門檻。在這裡，分享一點自己的心得，我一般按照下面幾步進行介紹，而我自己在進入到乙個新專案中一般也是按照這幾步進行學習的。
在這個環節，我會介紹為什麼會有這個專案，專案的目標是什麼，當前的狀態以及專案組的組織結構等。這裡，一定不要忘記把當前的產品展示新同事，使其有乙個直觀的印象。
雖然我們都是搞技術的，但是對於乙個新同事，一上來就直接深入細節而拋開專案背景，顯然是不合適的。因為，乙個人是否可以把事情做好，除了取決於他的技術能力；還和他是否對專案或者業務方向有認可度，是否願意投入精力去用心讓專案成果。如果乙個人對專案本身的目標都不認可，怎麼可能會做好呢。
介紹了專案的相關情況以後，對於有經驗的開發者來講，一般都會在腦海基於原來的經驗有乙個大致的實現思路。那麼這個時候，就可以介紹專案開發用到的技術有哪些，這些技術大概都用在什麼地方。
以上兩個方面都是從巨集觀的角度進行總覽，下面就要深入到細節中了。
在這裡，我可能會開啟工程目錄，介紹工程的組織結構，每個資料夾以及某些重要檔案的作用。對於有過類似專案經驗的同事來說，相對比較容易理解，而對於經驗相對缺乏的同事來講，可能只是有乙個簡單的印象，還需要在以後的工作中不斷的加強印象。
雖然很多專案大致相同，但是還是有很多細微差別之處。這個時候，我就會拿乙個具體的功能，從頁面到控制層，再到服務層，在到資料層，最後到資料庫，完完整整地講解一遍，把相關的**檔案都串起來。在這裡，尤其要告訴新同事，如果新增乙個新功能時應該新增、修改哪些檔案，這些檔案之間的對應以及呼叫關係是什麼樣的。
經過這一步，即使經驗不是很豐富的新同事，也可以照貓畫虎，做出乙個簡單的功能。
功能完成以後，自然是要上線測試的。一般情況下，在專案中都會生產、演練和測試等幾套環境同時執行，本地編寫和測試完成的**，還需要發布到測試和演練環境中進行測試，確保更改有效。於是就需要，告訴他打包、發布和測試的步驟。
在上面的五步中，肯定會有一些問題積累下來，這個時候就可以對這些問題進行深入討論，加深對某些部分的深入理解。如果有些問題，我無法解答，就會帶他找到這個方面比較有經驗的同事，進行請教。
作為當代的程式設計師，我們不但要會寫**，更要能夠把我們的經驗傳播出去，那麼溝通能力的提高就是很緊迫的了。
另外，作為過來人，我想對這些過來人說一句，多給新同事機會。在幫助新同事的同時，也是提高我們自己能力的時候。
如何有效地幫助新人融入專案中
今天看了 布道之道 裡面有些提到的很多經驗的確很實用。不僅又想起了，在剛剛參加工作時，在第一家公司裡就進行了如何提高溝通效率的培訓。當時很多都以自身的經歷，說明了溝通的重要性，也分享了一些溝通技巧。前幾天，有新同事加入到專案中，來參與其中乙個日誌分析軟體模組的開發。這次，我並沒有親自給他講解，而是讓...
如何有效地報告Bug？
simon首先列舉了一系列拙劣bug報告的例子，包括 接著，他點出了報告bug的目的 在bug報告裡，要設法搞清什麼是事實 例如 我在電腦旁 和 xx出現了 什麼是推測 例如 我想問題可能是出在 如果願意的話，您可以省去推測，但是千萬別省略事實。然後，simon針對bug報告的不同問題分別提出了自己...
如何有效地報告Bug？
作者 崔康 發布於 十月 08,2012 自由軟體開發者simon tatham針對如何有效地報告bug發表了自己的看法，他列舉了一系列拙劣bug報告的例子，並提出了改正建議。simon首先列舉了一系列拙劣bug報告的例子，包括 接著，他點出了報告bug的目的 在bug報告裡，要設法搞清什麼是事實 ...