我發現有幾件事對接受代碼審查有很大幫助：

不要說“您”，或者說您的變體（“您的代碼” ，等等）。

您不會撕毀“他的”代碼或“他的”解決方案。這是我們的代碼，或者是此解決方案，並且我們需要對此進行處理。

有人開始時在談論“您的”代碼時，很多人的自然反應是變得防禦，甚至好鬥-尤其是如果他們對起步不太自信。如果您避免將代碼的所有權暗示給初級開發人員，那麼他們將感覺不到受到攻擊的感覺。畢竟，公司是代碼的所有者。

請使用使團隊清楚地表明團隊正在共同努力以提高產品質量和團隊成員技能的語言。

使用積極的語言，並儘可能避免被消極。

例如，不要談論為什麼初級選擇的命名約定是

與邏輯問題類似，而不是花很多時間談論第一個解決方案有多糟糕，而是快速解決主要問題，而花大部分時間解決問題解釋了一種更好的方法以及第二種方法帶來的好處。

我已經經歷過很多次這種情況了。我通常會說的第一件事是：抱歉。。。

是的，對。。。如果他沒有正確地完成最簡單的事情（如命名約定），則意味著您（或負責任的人）對他來說）在向他們介紹他​​們方面做得不好。

因此，抱歉沒有為他提供足夠的信息來做好他。即使這只是部分正確，這也會使他感到被理解，並且他會看到，您不想為他做錯的事情而責備他，而是要作為一個團隊共同提高自己的學習水平。

當您遍歷代碼時，最重要的是使他理解自己的邏輯缺陷，而不是告訴他什麼地方出了錯。

我個人使用的類似“橡皮鴨”在這種情況下，“調試”：讓他解釋代碼的用途。現在有兩種可能性：

首先：如果他對任務的理解是正確的，但是代碼是錯誤的，那麼請深入研究進入代碼審查。

嘗試讓他意識到-通過詢問“如果……，代碼將做什麼”的問題-代碼有什麼問題，並讓他嘗試解決它他自己。變量也一樣：在教給他正確的命名約定後，問他現在要給他們起什麼名字。

第二：如果他對建議的理解已經是錯誤的，那麼請向他解釋任務確實是關於的，讓他解釋一下他將如何實現。

這樣，您就不會破壞他的解決方案，而是讓他自己進行改進。而且即使在那之後新的代碼與他最初的代碼有100％的差異，這個新代碼仍然是“他的”代碼。

TL; DR：由以下人員對代碼的質量負責道歉，因為他沒有告訴他足夠的操作或期望，然後讓他自己糾正代碼。

換句話說（非常有名的報價）：

告訴我，我忘記了，
教我，我記得，
讓我參與進來，我學習

首先，不要堅持採用一種特殊的方式來獲取反饋並從中學習。

尤其是，沒有在紙上做筆記並不一定表示大三沒有從代碼審查中獲得任何東西。對於大多數“編程風格”的代碼複習，我從未做過紙筆記，因為我寧願專注於討論代碼並思考“規則”及其在那時的好處，在那裡我旁邊有人來討論這個問題，而不是忙著寫下東西。無論如何，我在代碼存儲庫中都有“註釋”！ （至少我應該有！）。將重點放在實際問題上，不僅可以寫下很多東西，然後再將紙片扔到一堆其他便箋上，再也無需多看。如果被迫做筆記，我在會議上所要做的就是我不想和那個年長的人一起工作，因為他正全力以赴。

所以：是的，請建議選項，例如通過詢問大三學生是否需要他的筆記本，但不要強加您的學習方式。相反，要盡可能確保該少年以後仍然可以使用相關信息-例如通過在Wiki的某個地方寫下命名約定供所有人查閱，並將提交在審閱中（或至少是一些示例中）確定的必要更改提交到審閱分支。

如果您目前僅提供口頭的代碼審查，以解釋Junior在對話中的錯，我強烈建議您直接確保提交您在相應代碼中建議的更改，或者讓Junior進行更改，然後重新檢查代碼。在後一種情況下，將每個會話的返工量保持較小，而是執行多個會話。如果您已經做過更改，則會在代碼存儲庫中指出這些更改，以便Junior可以記住這些地方，而不是與日常工作無關的隨機示例。

向他展示他並不孤單，可以公開露面

至於如何使代碼審查公開且不令人生畏，我同意Player One的回答，並且願意再添加一個建議：不要僅僅與他一起進行代碼審查。 使代碼審查流程的正式常規部分，並與所有人一起進行。

此外，如果您認為他有防禦力，請與整個團隊進行代碼審查，但從一些更高級的同事開始，並以與對待他完全相同的方式對待他們：談論他們的代碼，而不是他們。即使是老年人的代碼，也幾乎總有值得討論的東西。而且，如果僅是“是的，因為a），b）和c）這樣做了，但是通過做Z可以使它成為更通用/遵循原則X，但這會帶來缺點Y”。確保對所有人使用相同的語氣和中立性。這表明初中生不是想用自己的愚蠢規則欺負他，而是每個人都受到同樣的審查，這不是“您的”愚蠢規則，而是團隊的共同規則-最好基於團隊的利益整體喜歡。此外，初級人員還可以從他人的錯誤（或出色的設計選擇）中學習。這使他變得不那麼私人化，並為他提供了在必須從事其他業務邏輯領域和軟件原理之前與他們聯繫的機會-因此，他可能有必要的時間來“消化”它們，然後再進行應用/工作。他們。

當某人在初學者水平上陷入嚴重混亂時，這僅意味著他們需要掌握基本知識。我不分析他們的錯誤，而是嘗試以這種方式教導。我已經解決了這些問題，處理這麼舊的新聞可能會有一點咒罵。

我只是詳細介紹了基礎知識。我的意思是約定，程序等。重要的是，我教他如何在開始之前計劃項目，我將檢查下一個項目。如果他們不了解某些內容，他們會把問題帶給我。

我不想給他留下深刻的印象。我希望他學習如何完成工作，而無需我去做其他工作。

• 邏輯中的重大問題，缺乏如何追溯問題的根本原因的知識，以及非常晦澀的命名約定（由於項目的性質，這是非常成問題的）。 / li>

我先從最簡單的開始。

“命名約定”

• 您的公司可能有一個指南。 Code Complete 2這本書也可以是很好的指南。它解釋了原因並給出了清單。
• 我會讓他製作自己的備忘單，然後用膠帶將其粘貼到自己的計算機顯示器上。
• 如果他不習慣遵循公司慣例或自己的備忘單。強迫他維護他以表格格式使用的所有變量名的紙筆詞典。那也應該永遠在他鍵盤旁邊的桌子上。

接下來，我將解決“如何將問題追溯到根本原因”。

這不是一個簡單的問題，可能需要花費多個會話來全面介紹每種技術。你也不能趕他。即使您一次告訴他一切，他也不會一口氣吸收一切。

他甚至可能已經知道該怎麼做，但只是不做那些事情。因此，您應該就這些主題向他提問，看看他如何在實際操作中以最少的指導來解決這些問題。

關於“邏輯中的重大問題”的問題。這些是結果。如果您幫助他修復他使用的基礎流程，那麼結果應該會有所改善。如果願意，您可以解釋他的邏輯錯誤，但不要指望這足以解決問題。

想想自己是一名老師。你不能因過多的糾正而使學生不知所措。相反，您必須幫助該學生專注於解決最容易糾正的錯誤，並解決一些更基礎的錯誤，即使這意味著不能解決其餘所有錯誤。

在連續的代碼審閱中，您可以一直注意他隨著時間的推移所做的改進，慢慢地解決他可能仍在犯的其他類型的錯誤。

情況還不錯，很好。一旦您掌握了這個事實，談話就會容易得多。

• 項目已按時完成。

• 您有時間和專業知識來進一步改進已經完成了預期工作的項目。

在軟件工程中，擁有非最佳架構是很自然的事情。

對於樣式問題（例如命名約定），人們通常在了解樣式後就遵循它們。只需解釋一次，他就可以了。不過要檢查他。

我不會過多地關注您當前的代碼使用經驗。

我認為對於所有初級開發人員而言，最有效的方法是與中級和高級開發人員緊密合作。這可能並不總是可能的。

但是公司至少應該在初級開發人員與中級甚至更好的高級開發人員之間每周定期提供一對一的服務。一對一會議的主題可以是初級開發人員感興趣的所有內容：

• 他們遇到的當前任務
• 他們讀過的博客文章以及
• 不了解
• 關於即將到來的故事的實現的一些提示
• 根據他們的最新拉動請求進行詳細培訓

關鍵是：

• 會議是一對一的。這樣一來，三年級生就可以問所有問題，而不會為他們可能會在別人面前提出明顯的問題而感到羞愧。
• 三年級生主持會議。現在是他們問所有問題的時候了。
• 會議不與他們的經理進行，也與他們的績效無關。有一位對培訓感興趣的資深人士。

通過使用“ 1：1驗屍'代碼審查'”中的引號，我認為這是一個非正式的過程，您可以塑造自己想要的方式。在這種情況下，我建議：

而不是從初級開發人員的代碼開始，而是從頭開始。

這在我的建議中具有以下優點：

• 這不會感覺到任何東西被“撕裂”，因為事實並非如此。
• 您將能夠更充分地展示您想要的良好做法
• 對於初級開發人員做得很好的部分編程，您可以說：“現在讓我們像第一次一樣來完成這一部分”；感覺就像積極因素散佈在聯合代碼構建之中（而在“撕裂”會議中，感覺就像中立情緒散佈在批評之中）。

在旁注中，您是確實試圖指導該開發人員並安裝一些技能，這些技能將在將來使團隊受益。這些技能之一是如何從反饋中學習，並使學習持續到未來。因此，在這種情況下：

明確指導他們如何在反饋會話中做筆記。該技能可以像其他任何技能一樣自覺地學習。 / p>

當然，您希望制定會議框架，以便初級開發人員支持。大概，誠實地說，您的目標是幫助他們提高技能，使他們感到滿意並得到認可，這應該就足夠了。您可以使用的一種成幀技術是：

總是談論成長心態中的技能，也就是說，隨著時間的推移，每個人都需要通過練習，努力和自覺的自我評估來提高技能。相反的是固定的心態：編程是人們可以做或不能做的事情。固執己見的框架和麵對自己的錯誤的結合通常會觸發防禦性和封閉性。但是在成長心態框架中，面對自己的錯誤更容易被視為學習的黃金機會。

最後，作為一般規則：

清晰傳達的期望是涉及多個人的所有過程的重要組成部分。

配對

我將提供與他進行配對編程的方法，而不是代碼審查。不管是在您的項目還是他的項目上，都無所謂，但這對兩者都有幫助。當他打字時，您會注意到可以改進的地方，只需問一些溫和的引導性問題，例如：“您認為有什麼方法可以改善它嗎？”讓他研究一些選項，然後使用提示來指導他解決問題。但是，嘗試分析他提供的每個選項，以幫助解釋其原理和優點/缺點。畢竟，有些選擇比其他選擇更好而不是最好的選擇，並且了解原因很重要。每當他給出一個很好的答案或使您的知識令您驚訝時，就稱讚他，以便在配對過程中獲得一些回報。比您將如何做。如果您知道自己打算做的事情與他在代碼中解決類似問題的方式不同，那麼請停下來，向他徵求建議，討論其他選擇。

最重要的約定是希望由團隊練習和提升。在這種情況下，您應該能夠找到任何人都沒有寫過的代碼，這些代碼可以說明您要提出的要點。查找一些示例並進行討論，以便他可以看到僅閱讀現有代碼是學習的一種好方法，並且他應該從現有代碼中學習。讓他知道複製代碼 style 和模式是一種美德，並且他應該練習直到獲得更多經驗。當然，這意味著他也會復制一些不良的代碼習慣，但這就是學習的代價。

蘇格拉底式方法

通常，當人們感到自己已經找到解決方案時，他們會學得更好，特別是如果他們有“尤里卡！”時刻。因此，與其說：“您應該做X。最好”，不如說：“我注意到您做X。您見過有人以不同的方式解決這個問題嗎？哦，為什麼您認為愛麗絲用Y代替了X？這種情況如何？您認為哪種解決方案更好？”因此，通過提出主要問題，您可以挑戰現狀並引導同事走上更開明的道路。有時，即使您沒有任何方便的代碼示例，您也只需要提供一些真實的場景即可說明為什麼Y比X更好。但是，如果我能使某人到他們說出我所要遵循的原則的程度，我會發現它的堅持要好得多，因為他們是通過自己的答案和推論得出這一點的，這意味著他們同意。

測試

沒有軟件工程師會做的三件事之一就是測試。您的下級伴侶很可能不是單元測試專家。也許您也不是專家。無論哪種方式，花費大量時間編寫單元測試並使用它們來執行代碼都是炫耀特定技術利弊的極好方法。您已經準備好了最小的測試用例，可以輕鬆進行調整以模擬不同的場景。特別是對於邏輯缺陷，顯示如何為測試用例識別良好的邊界條件以及如何執行所有代碼路徑，將極大地幫助他提高代碼的健壯性。您還可以演示運行單元測試如何通過使您對某些方法充滿信心，同時又讓其他人產生懷疑來幫助隔離問題。與用註釋將代碼二等分相比，這通常更容易實現分治。

重要的是，同時進行所有這些操作 ，比做一次“丟失”許多信息的講座要有效得多，因為您的學生沒有做筆記。引入新概念後，請確保給您的伴侶練習的機會，以便您可以就其應用提供指導和反饋。在教學後以及以後要嘗試這樣做，以檢查保留率。成對編寫代碼可以增強您在同一團隊中，朝著相同目標努力的過程，並且該過程是關於學習而不是判斷的。我的猜測是，您將很快提高初級人員的技能，並建立自己的領導和指導技能，這始終是與老闆分享的一項很好的成就。

學習編碼就是寫代碼，或者至少看著別人寫代碼。因此，我認為如果他在屏幕上觀看您的操作會有所幫助（最好是在他喜歡或熟悉的IDE中，即使您使用的是其他方式也是如此），這樣他才能看到更好地執行此操作的過程。讓我們討論一些示例：

邏輯中的主要問題

換句話說，代碼沒有執行應有的工作；它有一個錯誤。向他解釋一個，以及如何發現它，以及什麼代碼可以更正此問題。但是如何嗯...

缺乏有關如何追溯問題的根本原因的知識

與上一點有關，請向他展示如何診斷並解決上述錯誤。

晦澀的命名約定

不要僅僅因為說， “我們想要以這種方式命名的事物”。顯示更改名稱的最佳方法。 IDE使這更容易。根據它要檢測的內容，它可能還會建議甚至自動執行某些更改。如果您設置了這些東西，但他卻沒有，請為他改變這種情況，或向他展示如何做。

請注意，這種方法並不只是帶來您寫給您的長篇幅令人生畏的便條說，“請記住所有這些規則”。這是關於向他展示如何去做他應該做的事情。它教了精明的人。

[我]沒有足夠的時間討論我為&推薦的所有“原因”。 / p>

我認為我所建議的內容也有助於解決此問題。我不需要告訴您的經驗，只要花幾分鐘的時間，這些代碼就可以在旁觀者眼中提高多少。但是，他可能會發現一個令人驚喜的驚喜，這取決於過去幾個月來他被展示了多少根繩索。

他的口語很柔和，有時使&令人振奮。

@PlayerOne的出色回答凸顯了將“需要像這樣加以改進”作為非個人觀察的必要性。這很容易合併到上述策略中。短語“讓我告訴您如何做到”將或多或少地取決於其表達方式，但其高貴的精神是本練習的重點。

我們的老闆對他的表現進行了嚴格的審查。

如果這讓他感到擔心，那麼這可能會激發他同意跟隨您的示威遊行。如果您不知道他擔心它，則無需提出它，也不必基於它來調整上述方法。我敢肯定，如果您按照我的建議去做，還是會以減輕恐懼的方式來做。

他在復習/培訓中似乎並沒有記好筆記，他也當他陷入任務中時，對提出問題不是很主動。因此，我不確定這段代碼審查會真正“粘在”他的大腦中。你是多麼卑鄙或善良。我無法證明看到它的實際效果，因為當我們與代碼所代表的活著的野獸互動時發生的事情會更好地工作。但是這種想法與我的經驗相吻合。邀請他要求您暫停或放慢腳步，以便他寫下自己特別認為有必要的東西。

我還能做些什麼來減輕壓力當我瀏覽一下他在代碼中做錯的事情的清單時，會感到震驚嗎？

您不需要一個洗衣單-無論如何一次也不是全部。他提交的代碼不太正確。很好：他必須首先處理的代碼也不是正確的，至少對於現代需求而言不是。在這個親自演示中，您是從“他的”代碼開始的，這一點無關緊要。它向他展示瞭如何解決遇到的任何代碼。您可能需要多次執行此操作，具體取決於他需要處理多少事情。您可以根據他和團隊的需求來衡量，在他消化了第一部分的幾天之後，雙方將達成共識。但是，請教給他關鍵策略，這一次出現的問題從長遠來看將可以解決。

有什麼方法可以增加這種培訓/複習的影響？ ...我認為除非他真正努力學習團隊其他所有人使用的最佳實踐&方法，否則他不會成功。

我會把它留給你決定您應該邀請他“轉輪”的程度，您希望他可以根據演示的早期部分推斷出該做什麼。除此之外，我有一個建議與該答案的一般前提是分開的：為他推荐一個好的閱讀指南（或觀看，如果您知道非常好的視頻資料）。目前，一個指南，或者可能是兩三個非常簡短的指南。如果這是對您有幫助的指南，那麼其他指南的收益就會遞減，因此請不要使他超載，或者看起來像您可能的那樣。到“生產”。這使得捕獲我上面描述的問題類型變得更加困難。

好，是一個更多想法的時間了。告訴他他可以在您提交代碼之前讓您查看他的代碼，以了解您的想法。如果可以的話，請進行此類代碼審查，即使他們要求拉起椅子而不是使用項目中沒有的東西（在團隊中更常見）也是如此。這不僅僅是關於不單挑他。我工作的最後一家公司認為，所有代碼都應由兩個非作者進行審核，然後再進行推送。也許他可能是某人代碼（甚至您的代碼）的兩個審閱者之一！當然，所有這些都應該逐步引入，因為他可能沒有合適的能力，或者對這些能力沒有信心，因此不能馬上成為這樣的審稿人。

在處理涉及他人工作的重大更正時，很難找到需要幫助的一方來接受更正，而錯誤越嚴重，就越困難。

讓某人接受變化的方法是讓他們自己意識到變化。您可以說您需要檢查代碼並要求程序員逐步執行它，但請嘗試將所有問題作為一個問題。嘗試讓初級程序員自己弄清楚。例如：

  int xj6b7 = 99.2;  

您能看到此聲明有什麼問題嗎？您能看到為什麼另一個程序員可能在理解上有問題嗎？這可以看到常量99.2的任何問題嗎？他不一定會找到它。您一次可以執行一個問題。您可以合理地堅持認為，初中生記得做筆記，以便他們可以回去再做一次。

  x = x / 2; //將x除以2  

您能告訴我為什麼寫該評論嗎？您想向誰解釋此代碼？

是的，這樣更好將其分解，而不是試圖在一個會話中涵蓋此人的代碼的所有問題。給他們一個更簡單的任務，更細粒度，讓他們以較小的增量發展技能，顯然，給他們這麼大的一塊是錯誤的。

這是多麼成功，取決於學習者的個性（以及我在應用它方面的才能）。在這種情況下，我試圖做的是提問而不是發表聲明。

示例：

• “此子程序做什麼？ ……哦，那麼也許我們可以稱其為“ M400”而不是“ M400”了。 ……哦，那可以將它們分解為子程序嗎？”

在我作為開發人員的那段時間裡，我曾遇到過2個具有代表性的語錄，並且在討論這裡涉及的問題時想重複一遍。這種情況需要尊重地解決這兩個問題-您的教練是給業內新手的寶貴禮物，但是您提出的方式會大大改變禮物的價值。

在團隊和更大的生態系統中自我意識並尋求幫助：
“普通開發人員的自我意識與普通噴氣機飛行員相同。”

現在，這裡的兩個角色都是好人，（《 Top Gun》漫畫除外）可能是對其他人的完全尊重。這裡的要點是，他們倆都接受了很多培訓，以發展自己在高度專業化領域中的技能，從而導致他們對自己的能力有許多自信心。

開發人員方面的問題是，我們開始相信我們應該了解所有內容，並且能夠解決任何問題。

，通常是我們自己。我們將花費數小時和數天的時間自行研究和嘗試解決方案，而不是通過向同事尋求他們的投入和領域知識來揭示我們的無知。如果有足夠的時間，我們可能會提出一個很好的解決方案。

但是編碼與個人知識或技能無關，而且絕對與自我形象無關。開發人員獲得報酬以有效解決問題，因此，我們應該不要花3天的時間自己做某事，而不是花兩個小時為他們提供相同的結果，以幫助他們。即使那是我們自己的項目。

開發人員時間是項目上花費最多的時間之一，這是很好地管理自己的時間的一項至關重要的技能。無論是時間拳擊，波莫德羅技術，還是其他任何技術，開發人員都需要學習協作並最大限度地利用時間，而不是最大限度地提高技能。

將自己與工作產品分開： “您不是您的代碼。”

這些年來，有很多關於此的好文章（例如 this或 this）。任何花了很多時間發展技能和建造東西的手工藝人，都會感到自己的價值與最終產品有關。畢竟，它的質量和實用性說明了您自己的情況。

但同樣，代碼對企業和用戶的價值在於代碼的運行狀況，而不是代碼編寫者的聰明或獨立程度。是。 開發人員的價值不是他們已經生產的代碼；是他們將來創建有用代碼的能力。他們與特定技術或業務合作的時間越長，價值就應該越高-但增加價值的唯一方法是投入時間和精力。這意味著可以反饋已完成的工作，並且（希望）更多地了解業務目標，而不僅僅是任務列表。

代碼審查可以改善代碼，是的，但是它們還應該提高開發人員的技能設置和代碼應解決的問題的知識。不要專注於告訴開發人員他們是錯誤的，因為此時他們的價值還沒有得到審查。正在審查那段代碼的正確性和有用性，就像檢查從裝配線中出來的零件的質量一樣，而不是由操作機器的工人進行質量檢查。這就是為什麼它是 code 評論，而不是 developer 評論。

當然，發現裝配線最終產品中的持續缺陷模式可能會指導長期行動（例如，在生產線上進一步進行培訓或調查其他問題），但這完全是近期目標的第二要務-確保可以將已完成的作品運送出去。理想情況下，這也可以幫助開發人員改善自己的工作。

但這只有在審閱者專注於最終產品以及（在適當情況下）如何使用現有工具以及還有哪些其他工具的情況下才會發生。可用。討論 person 濫用或忽略錯誤工具的方式並不能幫助他們做得更好，只會使他們感到尷尬和不滿。

“我也永遠不會忘記大學畢業後的第一份工作。（即使是在大學裡。”）

這是我的建議：

“客觀上，你們兩個都有一個共同點：產生的源代碼。”

而且：

“導致的過程（“讓我們眨眨眼都假裝自己是匿名的……”） Developer-X以響應Requirement-Z產生Source-Code-Y。“

談論作品 product ...源代碼..和工作過程 無關工人。讓它絕對（！）清楚該人的工作不會受到威脅... “如果我們認為您不擅長此事，我們絕對不會僱用您。” 明確表示該公司堅定地致力於現在幫助這個人成長。

完整披露：” [使用BASIC]長八行，[花了六個月的時間才寫了1970年代末]，並且其中有一個錯誤。“ 該死的很難做，” ，我們需要始終清楚地表明我們理解這一點。 “是的，我們知道這很難，而且...我們得到了你的支持。”

確保他將筆和紙帶入代碼審查。

在代碼審查之前，告訴他帶筆和紙，並且希望他做筆記。如果他在沒有他們的情況下出現，請指示他返回辦公桌，收集它們，然後在他這樣做後返回。在他掌握了所需的材料之前，請勿啟動它。確保在每一點之後都在檢查過程中暫停一下，以便他可以記下適當的筆記。

然後，一旦他準備開始，請撕開他的代碼，並說明為什麼不好，以及為什麼您的方法會更好。完全堅持事實；不要猜測他的動機。如果他做得很好，請從這些方面開始和結束代碼審查-“三明治技術”以獲得反饋。如果他開始變得情緒化或防禦性，請停一會兒，並確保他清楚自己沒有在攻擊他，而是在嘗試幫助他。畢竟，如果他不了解自己在哪些領域做得不好，他就無法進步。

分為兩部分：

• 形式部分
  1. 命名約定
  2. 未使用的代碼
  3. 代碼格式
  4. 評論樣式
  ol>
• 體驗/邏輯/體系結構部分

您必須在“抱歉”中解決的正式部分，我是您的老闆/項目負責人”。如果您不這樣做，將會受到紀律處分。告訴我您需要多少時間，我們會為此計劃。

在剩下的時間裡，請他/她向您展示如何實施新代碼的草圖或大綱，然後再與您討論。您。現在聲明某些事情是禁止進入的（涉及到數據結構時，我在一個項目中做到了這一點）。