相変わらずの教える系ネタです(「教育ネタ」って書くとなんか違うニュアンスが感じられるので、あえて言い方をホンのわずかにひねってます)。
んと…端的には、例えば「ソースコードレビュー」とかその辺にまつわるお話。
比較的楽なところだと
・コメントがない
・明らかなバグがある
あたりで、この辺は鋭く突っ込んで終わり………ってなわけにもいきません。
「"なぜ"このようなバグを生み出してしまったのか」という、相手の思考ルートに思いを馳せて、可能であれば「その原因を元から滅する」ほうがよりよいです。
ただまぁそれでもなお「これは違うよね？」ですみます。
素晴らしいソースコードやインタフェースであれば、その成長をたたえたり祝ったりほめたり言祝いだりしていけばOKです。
問題は、その中間地点。
つまり「明らかなバグではないものの」「嫌なにおいが漂う(可能性のある)」コード。言い方を変えると「とりあえず、自分の好みからはかけ離れた」コード。
ちなみに「下手糞なソースコードレビュアー」は、このあたりを「間違いである」と断じてしまいます、が、おいちゃん的にはそのリアクションは「いかがなものか」感満載でございます。
実際問題として「自分の好みから外れている」コードには、分岐点が存在します。
一つは「考え方や捕らえ方、切り口の違い」。もう一つは「後で厄介な状況が発生する可能性のある、技術的負債を含む」もの。
後者は、きちんと「こういう状況においてこうなるから、この部分についてはまずいから直しましょう」とか言える…のですが。
問題は「どこまで直させるか」。
「全面書き直し」とかいうのは大変に楽ではあるのですが、下手をすると「学習している子のやる気とか意欲とか」そのあたりを、一式、根こそぎ消滅させかねません。
「適切かつ最小限、ピンポイント」な修正の指示は、非常に難易度の高いものがございます。
んで、より難しいのが前者の「考え方や捕らえ方、切り口の違い」。
まず、それを見た瞬間に「考え方や切り口が違うこと」を認識、その直後数秒で「その思考を噛み砕き」「それによって、とりあえず将来"比較的高確率で"起こる可能性のある事象と、その事象をこの実装にぶつけた場合に問題がないか？ 或いは問題があるか？ のシミュレート」をやる必要があります。
正直なところ、脳みその回路が焼ききれそうになる速度と思考量が、ここで発生します(苦笑
それをやった上で「明らかな問題がある」場合、上述の通り「適切かつ最小限、ピンポイントな修正の指示」を。
問題がない、或いは少なくとも見当たらない場合は「一端修正を飲み込む」必要があるんですね。
…ってなことを心がけてやっていくと、他人のソースコードが本当によい、勉強とトレーニングになります。
書いてあるのは、ぶっちゃけ本当に「無茶レベルの」要求ではありますが。
ソースコードのレビュー、などということをしたり、人様に物事を教えたりするのであれば。
自らにも「ある程度のハードル」を課してみる、ってのも一興かと思うのですが、どんなもんなんですかね？
