メンタリングノート
メンタリングで最大の助けの一つになるのは、自分がメンタリングする演習ごとにノートを保管しておくファイルを持つことです。
多くの解答には同じ提案が役立つことに気づくでしょう。ノートに残しておけば、同じ提案を毎回思い出しながら書き出す必要はありません。
また、提案を一か所にまとめておけば、時間をかけて磨いて、より分かりやすくしていけます。
ノートの書き始め方が分からないときは、exercism/website-copy/tracksにある自分のトラックの演習のmentoring.mdファイルが参考になるかもしれません。
それが存在すれば、妥当な解答の例や、さらなる議論を促すよくある提案・話題が載っていることがあります。
存在しない場合は、その演習について自分のノートファイルを作ったあとで、改めてそれを作りたくなるかもしれません。
また、今は一つの言語しかメンタリングしていなくても、将来はもっとメンタリングするかもしれません。
同じ演習でもトラックごとに必要な提案は変わる可能性が高いので、メンタリングノートは演習名ごとだけでなくトラックごとにも整理するとよいでしょう。
メンタリングノートは、その演習を頻繁に担当しても、たまにしか担当しなくても便利です。
頻繁に担当するなら、ノートからコピー＆ペーストするだけで、ゼロから打ち込む手間が大きく省けます。
たまにしか担当しないなら、前回担当してから数週間、数か月たつうちに忘れてしまった提案を思い出させてくれます。
メンタリングノートはメンターごとに違ってかまいません。
構成の一例を挙げますが、これが_唯一_の方法ではありません。
テストに合格したこと（合格した場合）をメンティーに伝えてねぎらいましょう。
演習が数日間キューに置かれたままなら、次のようにそれに触れるとよいかもしれません。
返信が遅くなってすみません。
現在、Resistor Color Duoを担当できるアクティブなJavaScriptメンターが足りていません。
メンティーの解答について、良いと思った点を箇条書きにします。
たとえば：
次に、よく使う提案を書くとよいでしょう。
新しく紹介する言語機能には、リンクを添えるとメンティーにとってとても助かります。
たとえば：
この演習には必要ありませんが、関数をアロー関数に変換することも考えてみてください。
解答そのものを渡したくはありませんが、メンティーは例から学ぶのがいちばんよいこともあります。
折りたたみの詳細セクションにコードの断片を入れておけば、メンティーが開くかどうかを自分で選べる例を提供できます。
たとえば：
<details><summary>Spoiler Example</summary>
<pre>
export const decodedValue = ([firstColor, secondColor]) =>
COLORS.indexOf(firstColor) * 10 + COLORS.indexOf(secondColor)
</pre>
</details>
ノートの終わり近くには、提案をすべて盛り込んだ公開済みの解答へのリンクを載せてもよいでしょう。
ノートのいちばん下には、メンティーからときどき求められる詳しい説明を置いておきたくなるかもしれません。
こうした説明は頻繁に出てくるものではありませんが、最初に使ったときに記録しておくとよいでしょう。そうすれば、数週間後や数か月後にまた必要になったとき、一から説明を考え直さずに済みます。
たとえば、Resistor Color Duoで黒が先頭のバンドで先頭のゼロを表す場合、掛け算の方法がどう働くのかをメンティーが尋ねることがあります。
先頭のバンドが黒というのはよい指摘なので、考えてみましょう。
抵抗のカラーコードは抵抗のオーム数を表すもので、
複数バンドの抵抗器では先頭にゼロは使いません。
つまり黒が先頭のバンドになることはありません。
そのうえparseIntやNumberも先頭のゼロを取り除きます。
メンタリングノートに残しておくとよい、任意のカテゴリの情報として、さまざまな解答や方法のベンチマークの記録があります。
ベンチマーク
メンティーがよく気にするのは、自分の解答の性能です。
これは特にC、C++、Go、Rustのような「低レベル」言語でよくあります。
ほかの言語のメンティーも、自分のコードがどれだけその言語らしく書けているかに加えて、効率を気にすることがよくあります。
ベンチマークは、メンターが_求められる_ものではありません。
ただ、自分の解答のベンチマークがほかの方法とどう比べられるかを見せると、メンティーは特に感心してくれることがよくあります。
Goはベンチマークをとりわけ扱いやすいトラックで、テストファイルにベンチマークが含まれていることがよくあります。
ほかの言語では、どの方法が自分に合うかを調べるのに少し手間がかかるかもしれません。
たとえばオンラインエディターしか使っていないなら、オンラインでベンチマークを実行できる場所を探すことになるでしょう。
たとえば、JSBench.meはJavaScriptのオンラインベンチマーカーです。
コードをローカルで実行するなら、自分のマシンで動かせるベンチマークソフトをダウンロードするという選択肢があります。
たとえばRustならCriterionや、ベンチマークテストと合わせたcargo benchが使えます。
ベンチマークを記録する方法は少なくともいくつかあります。
一つは、ベンチマークしたものをすべて一覧にしておく方法ですが、数が増えると扱いにくくなります。
もう一つは、方法ごとに代表的なベンチマークを一覧にしておく方法です。
メンティーは速い方法のコードを見たがることがよくあるので、速い方法が公開されていれば、そのリンクを渡すとたいへん喜ばれるでしょう。
ベンチマークした解答へのリンクを渡すときは、メンタリングセッションではなく公開された解答へのリンクであることを確認してください。
メンタリングを受けた解答がすべて公開されるわけではありません。
演習に固有ではないメンタリングノート
言語の機能の中には、複数の演習で扱っていることに気づくものがあるかもしれません。
あるファイルから別のファイルへ提案をコピー＆ペーストしようとしているときは、それを独立したファイルにまとめることを考えてみてください。
繰り返しになりますが、提案を一か所に置いておく利点は、時間をかけて磨きやすくなることです。
まだ使ったことのない演習で使うときにも見つけやすくなります。
以前どの演習でその提案を扱ったかを思い出そうとする代わりに、その提案のファイルに直接たどり着けます。
メンティーから質問があったとき
メンティーは、メンタリングセッションで何を得たいのかを明確に伝えるよう促されています。
それはしばしば質問の形で表されます。
答えが分からず、自分も興味がない質問なら、そのメンタリングリクエストは別のメンターに任せてかまいません。
答えが分からないけれど自分で調べたいなら、答えを見つけるまではそのメンタリングリクエストを引き受けないほうがよいでしょう。
その間にリクエストがなくなってしまっても、少なくとも自分は何かを学べたわけで、メンティーを待たせずに済みます。
これの例外は、メンタリングリクエストがすでに数日以上キューに残っている場合かもしれません。
その場合はそのリクエストを引き受けて、できる範囲のフィードバックを返し、
質問については後で改めて連絡するとメンティーに伝えるとよいでしょう。
もちろん、その後きちんとフォローするのは大切で、答えを伝えるにせよ、見つけられなかったと伝えるにせよ、連絡しましょう。
答えが見つからなかったなら、どんな方法で探したかを説明するとメンティーの助けになるかもしれません。
メンティーが、ほかの探し方を返してくれるかもしれません。
二人でなら、答えが見つかるかもしれません。
自分が知っている探し方をすべて試し尽くしたなら、メンティーにこのディスカッションを終了してリクエストを出し直すよう提案してみてもよいでしょう。
別のメンターが答えをくれるかもしれません。
メンティーが望むなら、終了したディスカッションに、答えが分かった時点でそれを投稿して教えてくれます。
同じように、自分が後から答えを知ったときは、終了したディスカッションに戻ってメンティーに伝えられます。
答えが分かっていてそれに答えたければ、解答の良いと思ったところを伝えるのと、別の方法の提案をするのとの間に書くのがよいでしょう。
失敗するコード
コードが失敗するのは、すべてのテストに合格していないからか、コンパイルやインタプリターの条件を満たしていないからです。
失敗するコードへの向き合い方や我慢強さはメンターによって異なり、それは提示のされ方にもいくらか左右されます。
失敗するコードはいつも同じように提示されるとは限りません。
メンティーが、別の方法を試したがうまくいかなかったとして、なぜうまくいかないのかを尋ねることがあります。
コードはそもそも示されていなかったり、イテレーションではなく、ほとんど読めないコメントに貼られていたりすることもあります。
ウェブエディターでテストした解答は、すべてのテストに合格していなければメンタリングリクエストとして提出できません。
その理由の一つは、メンターがすでに動いているコードに対して、改善案や別の方法の提案に集中できるようにするためです。
コードの_デバッグ_は、メンターが必ずしもやりたいことでも、期待されることでもありません。
ただし、CLIで提出された失敗する解答は、メンティーが助けを求めていればメンタリングリクエストとして提出できます。
失敗したコードが示されておらず、説明された失敗した方法が良いものに思えないなら、その失敗した方法ではなく、失敗した方法でも合格した方法でもない別の方法を提案するだけで十分かもしれません。
あるいは、失敗した方法にどんなバグがあったかの詳細には立ち入らず、自分が使った方法が失敗した方法より優れている理由を説明するだけで十分かもしれません。
たとえばよくあるのは、Robot Nameでつまずくメンティーです。
テストがタイムアウトするか、十分な数の名前を生成できず、どう直せばよいかを知りたがっています。
向き合う気と我慢強さがあるなら、もちろんコードを分析して問題の直し方を提案してもかまいません。
あるいは、ランダムに生成した名前を確認すると、名前が増えるほど衝突が増えることを説明し、
名前を順番に生成してからシャッフルする方法もあると提案してもよいでしょう。
失敗したコードがほとんど読めないコメントに貼られているなら、
合格している解答に対してできる範囲のフィードバックを返し、
そのコメントのコードを別のイテレーションとして提出するよう提案するとよいでしょう。
さらに、失敗したイテレーションのエラーを確認して、問題がどこにあるかの手がかりにするよう伝えてもよいでしょう。
コードが失敗しているイテレーションにあるなら、テスト実行のエラーを確認するようメンティーに案内すると助けになります。
言語によっては、エラーやテスト結果の読み方にもう少し手引きが要ることもあります。
エラーの一部を引用して、それが何を意味するのかをメンティーに説明すると助けになるかもしれません。
最終的に、メンティーの失敗するコードを直すのはメンターの責任ではありません。
ただし、メンターが望むなら、メンティー自身が直せるよう方法を提案することはできます。
キューの連続体への向き合い方
あるトラックのメンタリングに登録したのに、そのキューに担当できる演習がまったく現れないことがあります。
何かおかしいと思うかもしれませんが、これには少なくともいくつか理由があります。
一つは、そのトラックでは今のところメンタリングを希望する人がいないことです。
トラックには活動が停滞する時期があることがあります。
もう一つは、自分が気づく前に別のメンターがリクエストを引き受けていることです。
活発なメンターが多い人気のトラックでは、よく起きます。
キューにリクエストがたくさんあるなら、いくつかの進め方があります。
古いものから新しいものへと進めて、いちばん長く待っている人の対応を先にするのもよいでしょう。
あるいは、新しいものから古いものへと進める、特に古いものがすでに長く待っている場合には、そうしてもよいでしょう。
そうすれば、最近活動している人が、たまった分の処理を待たずに済みます。
同じ演習のリクエストが複数あるなら、集中力を保つために同じ演習をまとめて続けて処理するのがよいかもしれません。
演習Aから演習Bへ行き、また演習Aに戻る、という進め方ではなく。
自分があまり興味を持てない演習のリクエストが、何日も何週間も置かれたままになっていることがあります。
別のメンターが引き受けてくれることを期待してそのままにするもよし、これを機に自分でその演習を解いてみるもよしです。
役立つことの一つは、提出された解答を見てみることです。
自分が思いつかなかった方法を使っていて、その方法のおかげでその演習を解くのが魅力的に感じられるかもしれません。
しかし、コードを見てもその演習を解きたいと思えなければ、何も問題はありません。
メンタリングリクエストを見たからといって、「Start mentoring」ボタンを押さなければならないわけではありません。
