菜鳥慢飛，融入開發生活中

開發團隊有了新的成員加入了，讓他和團隊既有的成員建立足夠好的人際關係，絕對是重要的第一步。先將重心擺在讓他融入既有的人際網絡及團隊文化，絕對勝過於急著將他推入戰場，參與實際的開發工作。軟體開發產業是人的產業，人沒有問題了，其他問題就小多了。無論如何，總是要讓新成員開始參與正式的開發工作。

加入的新成員可能有兩種類型，一種是沒有實務開發經驗的菜鳥，這一類通常是學校剛畢業，知道如何寫程式、但僅限於作業，對於如何透過一個既定的開發流程，以及和其他成員間的合作來最終得到軟體，並沒有具體的概念。而另一類型的新成員，可能有一定的實務開發經驗，甚至可能十分的豐富。讓這兩類的新成員開始融入實際的開發工作，方法也會有所不同。

培養新人的第一步
從菜鳥程式員到能征善戰的猛將，通常需要一段不短的時間。即戰力當然很好，但是現實的情況往往是，好用的即戰力並不那麼容易招募。因此，找到有潛力的菜鳥，然後好好的加以培養，也是另一個補充實際戰力的好途徑。只不過，需要花費較多的時間罷了。因此，對團隊來說，通常都會將這類型戰力的補充，列為中長期的計畫。

菜鳥就像一張白紙，要在紙上呈現出美麗的圖畫，需要花費更多的心力去著墨。不過，白紙也不全然是壞處，雖然在技術面和觀念層面上可能需要重新帶領，但是，因為對開發沒有既定的成見，在開發的習慣及文化上，反而容易避免一些可能會有的衝突。

要能讓菜鳥程式員上手開始正式的開發，會有很多的前置工作，主要是開發流程、開發的慣例（像是命名慣例）及守則（像是程式碼版本控制的守則），當然還有會運用到的工具、開發環境、以及基本的程式庫。

大多學校剛畢業的菜鳥對於開發流程，以及在開發中需要遵守的慣例及守則，通常沒有概念。即使資訊科系的學生，或許有上過軟體工程之類的課程，不過請相信我，在沒有經歷真正的實際參與開發，大多數的菜鳥其實是很難體會的。

從投入實際開發來加速適應
當然，我們可以提供一些簡單的課程，讓菜鳥程式員了解到團隊所使用的開發流程為何？流程的精神是什麼？有那些慣例必須遵守？為什麼這些慣例很重要？

不過，除此之外，讓他在實際的開發工作中運用，才會遭遇到實際的挑戰，而這些挑戰及困難，也才能進一步幫助體會流程究竟是如何的被落實，這些慣例又是如何的被應用。而這是一個漸進式的過程，菜鳥程式員會愈來愈了解、也愈來愈能夠融入這個早就被其他成員所熟悉的運作方式。最後當這些活動對他來說，就像呼吸一樣自然時，他已經成功的融入這個團隊。

所以，當菜鳥程式員對開發流程、慣例守則，以及各種工具，還有基本程式庫，都有一定的認識之後，便可以開始讓他參與實際的開發工作。

究竟應該選什麼樣的工作，來交付給菜鳥程式員執行呢？

剛開始，我們喜歡選一些獨立性高、涵蓋範圍小、技術難度不高的工作，讓菜鳥程式員來習作。之所以選擇獨立性高，是因為讓他的工作不致於對其他人造成太多的影響，相反的，也不會讓別人對他造成太大的影響。涵蓋範圍小，需要的設計時間就短，比較能快點看到一個具體的成果。而技術難度低，可以確保菜鳥程式員有較高的機會順利完成，同時得到一定的成就感。

導師該扮演的角色
當然，通常類似mentor的角色是免不了的，而且最好是專職的mentor。這樣的人可以和菜鳥程式員一起完成同一個任務，也可以站在旁觀者的角度，看著菜鳥程式員撰寫程式，並且在適當的時候給予指導。這個角色的責任，除了引導菜鳥程式員能夠依照既定的開發流程進行開發之外，也要指導他遵守各種慣例及守則。而在工具、環境或既有程式庫上的使用，也負起教導的責任。此外，關於程式設計上的各種觀念，mentor最好也能夠在適當的時機予以灌輸。

一般常見到的情況是，菜鳥會寫程式，但寫不出和大家一樣風格的程式。

在團隊開發中，若程式碼無法分辨究竟是何人撰寫，代表所有的成員都用一樣的風格在撰寫程式，這是很好的情況。這意謂著，所有的人都使用同樣的程式編寫慣例、運用同樣的設計方式。每個人都可以輕易讀懂每一段程式碼、理解為何程式碼會呈現那樣的結構、以及為什麼會那樣的來解決問題、倘若要做修改，應該如何的著手──不論那段程式碼是誰寫的。在這種情況下，團隊成員可以說是完全的融合成為一體了。

而mentor帶領菜鳥程式員的這個階段，最重要的目標並不是讓他完成什麼太重要的工作，工作中所產出的程式碼只是這個階段的副產品，而這個階段最重要的目標，就是讓菜鳥程式員的設計方式及風格，也慢慢融入到團隊之中，和整個團隊愈來愈像是一體的。

同時，藉由提供團隊中現成的範例程式，mentor可以做為菜鳥程式員模仿的對象。模仿是很好的學習方式，而且學出來就跟模仿對象一樣，而這正是我們想要的。

mentor應該帶領菜鳥程式員，讓他能和團隊中成員踩著相同的開發步調，像是，閱讀規格書及設計書，然後審閱後提出修改意見。待確認可編寫程式後，進行程式的撰寫。例如，每天早上到辦公室之後，就更新版本控制系統上內容，而在下班前，把能編譯、運作的程式碼送進版本控制系統中。

mentor可以透過審閱菜鳥程式員所撰寫的程式碼，藉以了解他所撰寫的程式碼是否符合相關的編寫規範，例如變數、類別、函式的命名是否遵守命名慣例，以及排版方式究竟有沒有符合規定。除了必須符合規範之外，mentor也可以關心菜鳥程式員的程式碼在設計上是否有可以改進的地方。一般的新手，比較不會注意設計的問題，而會把撰寫程式碼的重心放在問題本身的解決之上。這時候，mentor可以利用機會引導他，讓他重視設計，也利用機會讓他明白好的設計其實是很有幫助的。

此外，mentor在審閱程式碼時，也可以檢視是否存在需要重構的問題。剛入行的菜鳥，所寫下的程式碼時常都會有重構的需要。告訴他們程式碼中所藏有的壞味道，可以幫助他們理解同樣都能達到作用的程式碼也有品質高下之分，對日後程式碼的演化也會有所影響。日後，他們就會愈來愈重視品質。這會是在觀念上一個很重要的進展。

審閱程式碼時，有時候也能順便發現程式臭蟲。mentor如果只是告訴菜鳥程式碼中何處藏有程式臭蟲，讓菜鳥程式員逕行解決，那就太可惜這樣的機會了。mentor可以利用這的機會，讓菜鳥程式員知道mentor究竟是如何透過審閱的動作，察覺到臭蟲的存在。如此一來，菜鳥程式員累積愈來愈多的經驗，就會知道在撰寫程式碼的同時可以運用同樣方式而主動避免的臭蟲。

有些mentor會透過查看菜鳥程式員在版本控制系統的簽入記錄，來輔助程式碼的審閱，這是個不錯的方法。在mentor的帶領下，菜鳥程式員反覆多做幾個此種類型的工作，就容易漸漸的融入和大家一樣的開發生活中，進到開發的常軌之上。