Don't Tell, Ask - 求めよ、命じるな

えーと、どんな因果か、レビューされる側よりもする側になることが多くなってしまった。

対象となる生産物の欠点を指摘することは、レビューの大事な役割の一つであるとされている。だが、レビュアーとして一番怖いのは、間違った指摘や無意味な指摘をしてしまうことだったりする。そう、レビュアーもまた間違いを犯すんだよ。恐ろしいことに。

そこで有効なのが、"Don't Tell, Ask."「求めよ、命じるな」の原則。

レビュー対象物の「至らなさそうな点」に対して、なぜそこはそうなっているのかについて答えるよう求める。自分がより良いアイデアを持っていれば、それを伝え、どちらが優れているか判断を求める。「ここは、こうしてよ」のような命令（出す側は「アドバイス」と呼ぶ）は出さない。だって、レビュアーの意見の方が優れている保証なんて、何もないんだからね。

そもそもレビューをするのは、そのアドバイスに黙って従う初級プログラマでレミングスをプレイするためではないし、クソ面倒な仕事が増やされたと机を殴る中級プログラマの被害妄想を育てるためでもない。レビュー対象物の質を上げると同時に、レビュアーが直接作る以上にチーム全体の生産性を向上させることが、レビューの大切な役割だ。そのために、選択肢のどちらを選ぶかだけではなく、それを選ぶ理由も納得する必要がある。

最近はレビューの最初に、気にかかっていることはないか尋ねるようにしている。仕様について何となく不明確な点はないか、コードの構造について「嫌な感じ」がないか、など。聞くと何かしら出てくることが多い。「気になってたならもうやっておけよ」と思うかも知れないが、それを求めるのはクソだ。多くの場合は時間的な制約があるし、「嫌な感じはあるが解決策がわからない」というような能力的な制約もある。「気になることなんてない」と答えるヤツは超人プログラマか、素人か、嘘つきか、だろうね。

さて、"Don't Tell, Ask."は、オブジェクト指向でのプラクティス"Tell, Don't Ask."「求めるな、命じよ」から借用した*1。組織構造はオブジェクト指向的なアイデアが参考になることが多いが、たまに、こういう真逆な構造もあるのが面白い。

ペアプログラミングを実践していれば解決する課題はあるかも知れないが、自分たちのチームでは導入できてはいないので、残念ながら語ることはできない。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

*1:アジャイルプラクティス第6章にある。らしい。未確認。