成为导师需要什么条件？
我可以在学习一门语言的同时指导这门语言吗？
我可以指导多门语言吗？
我应该试着指导队列里的每一个解答吗？
如果一个解答已经在队列里放了好几天，甚至好几周，该怎么办？
如果我对一个解答没有任何建议，该怎么办？
我应该指导一个自己从未解过的练习吗？
我应该指导一个自己解过、但用的是另一门语言的练习吗？
看过一个解答后，我就一定要指导它吗？
如果我解释了好几次，学员还是不理解，该怎么办？
如果学员对我的建议产生抵触，我该怎么回应？
即使我认为学员错了，也应该让学员说了算吗？
怎样措辞一条建议最合适？
我应该强制要求格式、注释和命名规范吗？
成为导师需要什么条件？
要指导一门语言，你不需要成为这门语言的专家。
你只需要比被你指导的人多懂一点点就行。
如果你觉得解答里有什么地方可以用不同的方式来做，你就可以提出来。
它不一定非得是_更好_的方式，只要是一个同样地道的替代写法就行。
这样，用不用这条建议，选择权还是在学员手里，
但至少学员有了更多可选项。
我可以在学习一门语言的同时指导这门语言吗？
理想情况下，一门语言你永远学不完，即使是已经掌握的语言。
有些语言每隔几周或几个月就会发布一个新版本。
不仅可能有新的语言特性要学，也可能有一些你还没了解的已有特性。
有时候学员会用到某个特性，那会是你第一次见到它。
所以，指导也可以是深入了解一门语言的好办法。
我可以指导多门语言吗？
只要你觉得自在，想指导多少门语言都可以。
指导多门你擅长的语言没问题，指导一门你还在学的语言也没问题。
我应该试着指导队列里的每一个解答吗？
如果当时你想不出对这个解答有什么实质或有建设性的话可说，
把这条指导请求留给别的导师，对学员可能反而更好，
即使那位学员要等更久才能得到回复。
如果一个解答已经在队列里放了好几天，甚至好几周，该怎么办？
如果学员问了一个你回答不了的具体问题，你可能还是想把它留给能回答这个问题的人。
否则，这个解答可能来自一个对你来说很难的练习，你可能没解过，
或者解过，但觉得自己解得不太好。
这种情况下，你不妨仔细看看这个解答，看能不能从中学到点什么。
如果能，你可以谢谢学员，说清楚你从他们的解答里具体学到了什么。
或者，你也可以请学员向你解释他们的解答。
这有点像“反向指导”，但有些学员在被礼貌而尊重地询问时，
会很乐意解释自己的解答。
然后你可以问他们有没有考虑过另一种思路，以及为什么选了现在这种。
又或者，你整体上还是看不懂这个解答，但能看到一些可以谈的地方。
比如，如果函数形参只用了n或m，你可以指出，可以考虑给形参起有意义的名字。
如果以上这些你都不太愿意做，把这条请求放着不回复也没关系。
指导是自愿的。
你指导一门语言，并不意味着你必须指导那门语言里的每一个练习。
如果我对一个解答没有任何建议，该怎么办？
说说你喜欢这个解答的什么地方，完全没问题。
事实上，具体说出你喜欢一个解答的哪里，是开启任何一次指导的好方式。
说完之后，如果你没有关于其他解题思路的建议，
直接对学员说一句“做得好！”就行。
如果学员提交了不止一个迭代，
你也许能指出最近这个迭代在哪些方面有所改进。
我应该指导一个自己从未解过的练习吗？
有时候，看学员的解答会激发你自己去解这个练习，
尤其是当解答用的思路让你觉得这个练习比你之前考虑过的思路都简单时。
解完这个练习后，如果那条启发了你的指导请求已经不在了，
至少下次你就准备好了。
我应该指导一个自己解过、但用的是另一门语言的练习吗？
考虑到一门语言里地道的写法在另一门语言里可能并不地道，
最好还是在被指导的那门语言里解过这个练习。
如果两门语言的解答非常相似，而你对两门语言都足够熟悉，
知道各自什么是地道的，那把一门语言的解答转换到另一门不会花太久。
如果转换完解答后，那条指导请求已经不在了，
至少下次你就准备好了。
看过一个解答后，我就一定要指导它吗？
你可能看了某个解答后，发现因为这样那样的原因自己并不想指导它，包括：
- 学员可能问了一个你不知道答案的问题。
- 代码可能过于啰嗦和/或令人费解，你不知道从哪儿开始点评。
- 代码可能表明学员是个绝对的新手，需要大量基础指导，
而你没有那个时间，也没有那个耐心。
- 学员的留言可能让人觉得，跟他们互动会很累，或者很费劲。
如果你觉得这条指导请求不适合你，没有任何规定强迫你点击“开始指导”按钮。
如果我解释了好几次，学员还是不理解，该怎么办？
有时候，学员看起来几乎是在故意抗拒理解你的解释。
如果你觉得自己知道的解释方式都已经用尽，你可以决定
在结束讨论时建议学员重新提交指导请求，
好让另一位导师来处理，他也许能更成功地解释这些难点。
如果学员对我的建议产生抵触，我该怎么回应？
有时候学员会说，他们用了一个比必要的更费劲的思路，是为了多学一点某个语言特性，
即便那个特性并不最适合这个练习。
既然 Exercism 是一个学习的平台，而不是编程竞赛网站，那这就是一个站得住脚的理由，
可以用来解释他们为什么不用最优雅或最高效的思路。
如果你看出他们本可以把那个思路写得更地道，
你可以就他们使用这个思路的方式提一些建议。
无论如何，你都可以建议他们据此再提交一个迭代，
或者结束这次讨论，腾出一个指导名额。
学员可能坚持一种并不最适合这门语言或这个练习的编程范式。
比如，他们可能总想用面向对象范式，
把一个相对简单直白的解答拆成一堆类，
再用多个方法里迷宫般的控制流把它们串起来。
就学员对这种范式有多教条而言，试图说服他们换个思路通常是徒劳的。
你可以试试，他们也许会对你的建议有所回应，但如果学员很固执，最好还是放手。
学员也可能干脆拒绝一条建议。
比如，你可能建议用reduce代替map和join，
因为reduce只需一次迭代，而map一次、join再一次。
但学员可能会拒绝，因为他们觉得map和join更易读。
你可以同意学员，map和join确实可能比reduce更易读。
你可以建议他们多用一段时间后也许会对reduce更习惯，
而用map和join并没有什么_错_。
学员对的地方，你可以同意他们，
学员表达出的任何误解或夸大，你也可以试着纠正。
即使我认为学员错了，也应该让学员说了算吗？
举个例子，解Clock练习时，你可能建议学员不要用像60和24这样的魔法数字，
而是把它们定义为名字有意义的常量。
学员可能会回答，在这个上下文里，60和24代表什么一目了然。
你已经提了建议，学员也把它驳回了。
为这个争下去，可能什么也得不到，说不定还会伤和气。
怎样措辞一条建议最合适？
要提一个不一定_更好_的替代方案，你可以在前面加上“另一种思路可以是……”。
比如，“另一种思路可以是把every和includes一起用。”
如果要介绍一个学员在解答里没用过的语言特性（比如every或includes），
最好链接到一篇解释它的文档。
另一种引出建议的方式是“不妨考虑……”。
比如，“不妨考虑用展开语法代替 split()。”
如果你强烈认为学员应该改用某个替代方案，你可以去掉“不妨”，直接以“考虑……”开头。
比如，“考虑用一个默认参数。”
一连串建议时，你可能想变换每一条的引出方式。
用项目符号来列出你喜欢一个解答的哪里，很有效。
但用来列建议时，它们可能显得不够友好。
用随意、对话式的方式给出建议，可能会让学员更容易考虑和接受。
提建议时，最好别用的一个词是“应该”。
比如，“你应该用一个默认参数。”
用“应该”或“必须”这样的词，会显得盛气凌人。
我应该强制要求格式、注释和命名规范吗？
对于什么时候提代码格式、注释和命名规范这类事，以及提得有多强硬，
导师们多半会有分歧。
一方面，你可能想趁早借 Two Fer 这样的练习让学员开始思考这些事，
以免他们养成坏习惯。
或者，你又不想拿各种得体与否的讲究去吓到一个新手。
另一方面，做更进阶练习的学员可能早就知道这些规范，却选择在手头的任务上无视它们。
他们可能会反感对规范的持续关注，觉得那是吹毛求疵。
如果一门语言有一个或多个格式化工具或 linter，那选一个练习来介绍它们会不错。
否则，如果对某条规范的违反真的很糟糕，你可能想在它出现的任何地方指出来。
导师们的分歧可能就在于，什么才算“真的很糟糕”。
