將您介紹給項目的最佳方式是什麼？

Question

我現在正處於一種情況，我需要擔任當前項目的新開發人員的導師。

什麼是您快速進入項目的最佳方式 - 無論是技術上，特定領域的項目還是社交。

我已經閱讀了不少有關TDD編程的專業人士，他們開始與有經驗的團隊成員編寫測試和新人員實現實際代碼 - 然後再進行切換。

什麼最適合你？

Answer 1

有技術的組合：

首先，他們需要了解應用程序的功能。我知道這聽起來很古怪，但我曾在交易應用程序中工作過，並且可能需要很長時間才能讓人們瞭解做市商的情況，因爲這是建立在關於金融市場如何運作以及如何運作的衆多知識之上的。他們是這樣。只是像「傳播」這樣的術語有各種假設的知識。

這應該交互式地完成，而不是交給某人教程或用戶手冊。另外，這非常重要，用戶用戶應該驅動。使用鼠標和鍵盤而不是觀看是建立肌肉記憶和根深蒂固的反應。你會以這種方式獲得更好的保留率。另外，不要說「現在點擊這裏」，而是讓他們現場問問他們「你會在這裏做什麼」。

因爲新人沒有受到您和您現有團隊的所有歷史的影響，您通常可以通過這種方式瞭解應用程序的可用性。

你不能教給別人一切，只要讓他們看到足夠的東西，他們就可以瀏覽應用程序並完成簡單的任務。其次，給他們一個架構概述。如果這需要一兩個多小時，你會進入太多的細節。他們會忘記它。我覺得最好把這個當作是面對面的談話，而不是把建築設計文件交給他們（這通常只是讓人眼睛眩光）。

最後，給他們一些小的，相對容易的錯誤來修復那些不是時間關鍵的錯誤。這將使他們熟悉檢查代碼，構建代碼，部署代碼，運行代碼等的基礎知識。重要的是它很簡單，因爲新代碼總是出錯。您可能需要設置正確的環境變量來正確構建代碼或其他內容。給他們一個複雜的問題，如果出現問題，他們會在弄清楚自己的環境，是否因爲他們做錯了事等而迷失方向。

這不言而喻，你不能讓他們在角落弄清楚這一點。有人傾向於留意他們，以確保他們不會陷入困境。這也會讓你很好地洞察他們的個性：當他們陷入困境時會發生什麼？他們凍結了嗎？他們是否要求幫助？他們是否嘗試並堅持下來？他們是否放棄過於輕鬆？

與此同時，他們正在瞭解代碼。

Answer 2

是否有任何使用與主項目相同的平臺創建的內部工具？如果是這樣，一個好的平臺介紹將讓新人對你想要的工具做一些改進。

Answer 3

當我在現有的項目，我覺得它更容易進入，如果：

• 有人表示我的應用程序的工作，解釋什麼是應該做的，什麼是做了，回答我的最初的問題。

• 我得到很好的文檔，所以我可以自己找出項目的基本知識。

• 我有人可以隨時回答我的任何問題。

Answer 4

讓新手修復代碼中的錯誤。

這是一個雙贏。你可以讓他們在角落裏按自己的節奏工作。他們有一個目標。您可以在5分鐘內設置任務。

Answer 5

我想做到以下幾點：

• 給系統的演示
• 給予高度概括，伴隨流程圖/設計
• 給開發者一個特定的更詳細的解釋區。
• 給他們一些工作（簡單的工作）在該地區。
  解決一些錯誤是一個很好的方法來做到這一點。

一旦他們熟悉的那個區域，展開它，並開始給他們的小功能等

這一切的重點是爲他們的產品熟悉，並環境。

Answer 6

啤酒！

從社會的角度來看，我總是喜歡整個團隊出去喝點新鮮啤酒。或者，如果你不是一個啤酒傢伙，那麼打保齡球或搖滾樂隊什麼的。

在你們放鬆一下之後，他們會感覺舒適得多，提問和適應。

Answer 7

• 給他們所需的KT一天 或兩個。
• 獲取反向演示文稿
• 讓他們修復幾個
  天的錯誤。

或

將新joinee作爲備份資源的模塊。逐漸取決於他表現出來的信心，請他開始主要的核心工作。

Answer 8

自然的傾向是開始廣泛和深入，這導致了很多長篇介紹性談話。新人幾乎不記得任何一件事。不要浪費你的時間在項目的歷史，高層架構等等。

將他們與經驗豐富的人員配對以解決單個問題。及時解釋正在進行的工作。當你這樣做時，通過向他們展示哪裏可以找到歷史/背景信息來教他們釣魚。當人們從內核建立理解時，人們學習得最好。人們並沒有保留很多先期的「腳手架」信息。

Answer 9

我剛剛在12月份開始一份新工作，所以這個過程在我心中還是新鮮的:)。

下面是我碰到了問題：

這是什麼東西做？

• 我正在處理的 應用程序的目的是什麼？
• 誰是其目標用戶，它解決了什麼問題？
• 我該如何使用它？

我該怎麼做我的工作？

• 我們用於源代碼管理的是什麼？
• 我們使用什麼來進行錯誤跟蹤？
• 我會每天與誰進行互動？ （其他開發人員，質量保證，文檔等）
• 我還需要了解其他任何工具或流程嗎？

我該如何構建它？

• 我在哪裏可以找到源代碼中需要的源代碼？
• 我需要採取哪些步驟來建立這個東西？ （理想情況下，它應該是一步，但它幾乎從來沒有！）

什麼是所有這些東西？

• 什麼是系統架構的高層次概述？ （沒有太詳細的說明，只是主要玩家的基本描述）
• 源代碼的目錄結構如何設置？什麼去哪裏？

一旦所有這些問題都得到解答，我就可以開始工作了！

加速新代碼庫的最佳方法是處理定義明確的，獨立的任務，這些任務的構建方式逐漸暴露給越來越多的組件。此外，如果我遇到困難或需要更多信息，讓人們隨時回答我的問題至關重要。

在這裏，我的經驗是偉大的，到目前爲止，這是我一直在努力的事情的順序：

1. 修復了幾個小錯誤的
2. 重新設計兩種不同的對話框，卻是可怕的設計
3. 寫的示例代碼與產品的COM API
4. 交互寫從地上一個全新的模塊了，然後將其融入產品