引導常見問題

什麼樣的人有資格當導師？

我可以在還在學某個語言的時候引導它嗎？

我可以引導一個以上的語言嗎？

我應該試著引導佇列裡的每個解法嗎？

如果某個解法在佇列裡躺了好幾天，甚至好幾週，該怎麼辦？

如果我對某個解法沒什麼建議，該怎麼辦？

我應該引導自己從來沒解過的練習嗎？

我應該引導自己解過、但用不同語言解過的練習嗎？

看過某個解法之後，我就一定要引導它嗎？

如果我解釋了好幾次，學員還是不懂，該怎麼辦？

如果學員對我的建議出現防衛心，我該怎麼回應？

即使我覺得學員說錯了，也該讓他們說最後一句嗎？

建議要怎麼講才最恰當？

我應該強制要求排版、註解和命名慣例嗎？

什麼樣的人有資格當導師？

你不需要是某個語言的專家，才能引導那個語言。 你只要比被你引導的人稍微不那麼新手一點就夠了。 如果解法裡有你認為可以換個方式寫的地方，你就可以提出來。 那不一定得是_更好_的寫法，只要是道地的替代寫法就行。 要不要採用這個建議，決定權在學員身上， 但至少學員多了幾個可以挑的選項。

我可以在還在學某個語言的時候引導它嗎？

理想情況下，學習一個語言是永遠不會停下來的，即使是已經會的語言也一樣。 有些語言每隔幾週或幾個月就會推出更新版本。 不但可能有新的語言特性要學，也可能有些既有的特性是你根本沒注意到的。 有時候學員會用到某個特性，而那會是你第一次看到它。 所以引導也可以是更認識一個語言的好方法。

我可以引導一個以上的語言嗎？

只要你觉得自在，想引導多少個語言都可以。 同時引導好幾個你很拿手的語言，以及一個你還在學的語言，都沒有問題。

我應該試著引導佇列裡的每個解法嗎？

如果當下你想不出對某個解法有什麼實質或有建設性的話可說， 把這個引導請求留給另一位導師，對學員可能反而更好， 即使那位學員得等更久才收到回覆。

如果某個解法在佇列裡躺了好幾天，甚至好幾週，該怎麼辦？

如果學員問了一個你答不出來的具體問題， 你還是可以把這個請求留給能回答他問題的人。

不然的話，這個解法可能出自某道對你來說很難的練習，你或許沒解過， 或者解過，但覺得自己解得不太好。 這種情況下，你可以把解法看過一遍，看看有沒有什麼能從中學習的地方。 如果有，你可以謝謝學員，具體說說你從他的解法裡學到了什麼。

或者，你也可以請學員向你說明他的解法。 這有點像「反向引導」，不過有些學員在被禮貌、尊重地詢問時， 會很樂意說明自己的解法。 接著你可以問他們是否考慮過別的做法，以及為什麼選擇現在這種做法。

又或者，你整體上還是不太懂這個解法，但看到了一些可以著墨的地方。 比方說，如果他們只用了n或m，你可以指出不妨考慮為函式參數取有意義的名字。

如果上面這些做法你都做不來，把請求放著不回也沒關係。 引導是自願的。 你在引導某個語言，不代表你就得引導那個語言的每一道練習。

如果我對某個解法沒什麼建議，該怎麼辦？

說說你喜歡某個解法的哪些地方，是沒問題的。 事實上，具體說出你喜歡解法的哪裡，是展開任何一次引導互動的好方法。 說完之後，如果你對這道練習的其他做法沒什麼建議， 直接跟學員說一聲「做得好！」就可以了。 如果學員提交了不只一個疊代， 你還可以指出最近這個疊代在哪些方面有所進步。

我應該引導自己從來沒解過的練習嗎？

有時候，看著學員的解法會讓你也想自己動手解這道練習， 特別是解法用的做法讓你覺得這道練習比你原本想過的做法更簡單時。 解完這道練習之後，如果當初啟發你的那個引導請求已經不在了， 至少下次再遇到時你已經準備好了。

我應該引導自己解過、但用不同語言解過的練習嗎？

既然一個語言裡道地的寫法，在另一個語言裡未必道地， 最好還是解過要引導的那個語言版本。 如果兩個語言的解法非常相似，而你對兩個語言都熟到知道各自的道地寫法， 那麼把一個語言的解法轉換到另一個語言應該不會花太久。 轉換完之後，如果引導請求已經不在了，至少下次再遇到時你已經準備好了。

看過某個解法之後，我就一定要引導它嗎？

你可能看了某個解法，然後基於以下幾種理由，發現自己並不想引導它：

• 學員問的問題，你不知道答案。
• 程式碼可能又冗長又令人困惑，你不知道該從哪裡開始評論。
• 程式碼顯示出學員是徹底的初學者，需要大量基礎引導， 而你既沒時間也沒耐心。
• 學員的留言讓人覺得，跟他們互動起來可能很不愉快或很費力。

如果你覺得某個引導請求不適合你，沒有任何規定強迫你一定要點下「開始引導」按鈕。

如果我解釋了好幾次，學員還是不懂，該怎麼辦？

有時候學員看起來幾乎是刻意不肯理解你的解釋。 如果你覺得自己知道的所有解釋方式都用盡了，你可以決定 在結束討論時，建議學員重新提交引導請求， 讓另一位導師來處理，也許對方更能把這些難點解釋清楚。

如果學員對我的建議出現防衛心，我該怎麼回應？

有時候學員會說，他們刻意用了比必要的更費工的做法，是為了多學一點某個語言特性， 即使那個特性並不是這道練習最適合的選擇。 既然 Exercism 是學習平台，不是競技程式設計網站，那會是個站得住腳的理由， 說明他們為什麼不用最優雅或最有效率的做法。 如果看得出他們的寫法可以更道地，你可以針對他們怎麼運用這個做法給一些建議。 無論如何，你都可以建議他們根據回饋再提交一個疊代， 或者結束討論，把引導名額讓出來。

學員也可能信奉某個不見得最適合這個語言或這道練習的程式設計範式。 比方說，他們可能永遠都想用物件導向範式， 把一個相對簡單直接的解法拆成一堆爆炸般的類別， 再用錯綜複雜的控制流程穿梭於多個方法之間。 如果學員對這個範式抱持教條式的態度，想說服他們換個做法通常徒勞無功。 你可以試試看，他們也可能接受你的建議，但如果學員堅持己見，最好就此打住。

學員也可能直接否決你的建議。 比方說，你可能建議用reduce取代map和join， 因為reduce只跑一次疊代，而map一次、join又一次。 但學員可能不接受，因為他們覺得map和join比較好讀。 你可以同意學員，map和join確實可能比reduce好讀。 你可以建議他們多用一段時間之後，也許就會對reduce更自在， 而且用map和join本身並沒有什麼_錯_。

在學員說得對的範圍內同意他們，是沒關係的； 學員如果表達了某些誤解或誇大，試著糾正一下，也沒關係。

即使我覺得學員說錯了，也該讓他們說最後一句嗎？

舉例來說，解Clock練習時，你可能建議學員不要用60和24這類魔術數字， 而是把它們定義成取了好名字的常數。 學員可能回應說，在這個情境下，60和24代表什麼一看就懂。 你已經提出建議，學員也駁回了。 再爭下去可能什麼都得不到，還可能傷了和氣。

建議要怎麼講才最恰當？

要提出一個未必_更好_的替代做法時，你可以用「另一種做法可以是……」開頭。 例如：「另一種做法可以是用every搭配includes。」

另一種開頭方式可以是「或許可以考慮……」。 例如：「或許可以考慮用展開語法取代 split()。」 如果你很強烈覺得學員該改用另一種做法，可以把「或許」拿掉，直接說「可以考慮……」。 例如：「可以考慮使用預設引數。」

如果有一連串建議，你可能會想讓每個建議的開頭有些變化。

條列式的重點，用來列出你喜歡某個解法的哪些地方很有效。 但用來列建議時，讀起來可能就沒那麼友善。 用輕鬆、像聊天的方式提出建議，學員會比較容易考慮和接受。

提出建議時，有一個字最好別用，那就是「should」。 例如：「You should use a default argument.」 用「should」或「must」這類字眼，會給人高高在上的感覺。

我應該強制要求排版、註解和命名慣例嗎？

導師們對於什麼時候、以及用多強烈的語氣提起程式碼排版、註解和命名慣例這類事情，往往意見分歧。 一方面，你可能想趁 Two Fer 這類練習，讓學員早一點開始思考這些事， 免得他們養成壞習慣。 或者，你不想拿一堆規矩來嚇跑初學者。 另一方面，做進階練習的學員可能早就知道這些慣例，只是在專注眼前的任務時選擇忽略。 他們可能會覺得你一直盯著慣例不放很吹毛求疵。 如果某個語言有一種以上的格式化工具或 linter，挑一道練習來介紹它們會是不錯的做法。 否則，如果某個慣例被違反得真的很嚴重，你可能想在任何地方看到就指出來。 導師們意見不同的地方，就在於什麼算得上是「真的很嚴重」。