今はどちらもいまいちという結論に落ち着いています。
コメント不要主義者は、コメントに割く労力はコードの可読性を高めるために使うべきだと説き、コメント頼みの読みにくいコードや、コードの変更に追従できず内容が古くなりがちなコメントの性質を非難します。コメント必須主義者は、コードによってとらえることのできない情報や意図があると主張し、それらをコメントとして文書化すべきだと訴えています。
コメントとコミットログ
一見すると、この論争はドキュメントを書くのを億劫がる横着なプログラマと、神経質で几帳面なプログラマのいがみ合いであるかのように映ります。
実際のところ、それはあまり正しくありません。コメント不要主義者も、ある種のドキュメントは案外丁寧に書くのです。そうしたドキュメントの一つがコミットログ です。コメント不要主義のコードベースで仕事をしている筆者は、開発者が丁寧なコミットログを書く様子をたびたび目にしてきました。ドキュメントとしてのコミットログにピンと来ない読者は、WebKitのコミットログ を覗いてみてください。詳しく書かれたソースコードコメントに匹敵する事細かな説明を見ることができるでしょう。
コメント嫌いの開発者たちが、コミットログの必要性は認めている。これは興味深い事実です。コメント不要主義者の多くはドキュメントを書きたくないのではなく、コメントを書きたくないのです。なぜコミットログは書くのにコメントは書かないのでしょう。コメントとコミットログの違いはどのように説明できるのでしょうか。
メディアの違い、レンズの違い
コメントは、ソースコードのある瞬間を説明しています。言ってみれば写真 のようなものです。一方、コミットログはある状態から別の状態への変化をとらえた動画 です。またコメントはクラスやメソッドなどの細かい単位で物事を説明するのが主流なのに対し、コミットログは変更全体を一望します。コメントはズームやマクロ撮影 のようなもの、一方のコミットログは広角(ワイド)撮影 です。
ドキュメントを載せるメディアの向き不向きは、開発スタイルと関係があります。反復的で漸近的な開発スタイルでは、ある瞬間のスナップショットはありがたみが大きくありません。あとに続く変化のせいですぐに古びてしまうからです。むしろその変化自体を追いかけた動画のほうが理解の助けになるでしょう。一方、前もって念入りにデザインを決めるなら、解像度の高い写真的なメディアが役に立つでしょう。
ドキュメントを写すレンズの違いはコードのデザインの影響を受けます。クラス単位の働きより複数のオブジェクトをまたぐ協調と役割分担を重視するなら、広角で景色を収めたくなります。オブジェクト同士の位置関係を一目で見渡せるからです。一方で個々のクラスの完成度を重視して丁寧に磨き上げるなら、その細部をとらえる力があるのはマクロ撮影です。
反復的な開発スタイルをとる若いプロジェクトや、部分的な再利用を気にしないアプリケーションソフトウェアほど、コメントよりコミットログを好むのが自然な成り行きに思えます。逆によく理解され成熟したソフトウェアや再利用を意図したライブラリのコードはコメントを好む傾向がありそうです。プロジェクトやデザインの違いがコメント不要論争の火種だった。そう考えることはできるかもしれません。
より良いメディアとカメラワーク
ところで、そもそもメディアやレンズの違いを受け入れる必要はあるのでしょうか。これらはメタファに過ぎません。メタファの対象が実際のメディアより大きな不自由に甘んじる必要なんてあるのでしょうか。私たちは高解像度の動画を自在なカメラワークで撮影したいのです。
メタファを離れて具体的に書いてみましょう。コメントは空間的解像に偏り過ぎ、時間的解像を損ねていました。コミットログはその逆です。双方を満たすドキュメントは可能なのでしょうか。コメントに相当する粒度のドキュメントが、日々コミットされるソフトウェアの変化をとらえることはできないのでしょうか。そして異なる粒度のドキュメントを自由に渡り歩いてはいけないのでしょうか。
たとえば、クラス単位、関数単位でコミットログが書けたらどうでしょう。それらのコミットログが、コメントと同じくらい簡単にエディタから参照できたら? GitやSubversionのblame機能はこうした方向性の芽生えだと見ることができます。しかしとても十分とは言えません。コメントとコミットログ双方の利点を備えたツールが現れたとき、コメント論争は歴史の影に消えていくでしょう。
コメント論争は一例にすぎません。多くの論争は、その外側に答えが隠れています。答えそのものがわからなくても、喧騒から離れて静かに考えを巡らせれば答えの輪郭や匂いに気づくことくらいはできるはずです。論陣の一方に肩入れしてその正当性を声高に唱えたり、他方の粗探しに終始していると、答えの行方を見失ってしまいます。
論争の解決には時間がかかります。何らかの論争の中で今まさに選択を迫られている人は、答えを見つける前に異議をはらんだ決断をするほかありません。あなたを責める人もいるでしょう。けれど10年後に振り返れば、どちらも間違っていたと笑っているはずです。論争の中で下す決断は答えの見えない問いをはぐらかすその場しのぎ。そう思うと、少しは気が楽になりませんか。
答えを探す
運良く即断を迫られていないなら、答え探しの旅に出ましょう。
まず最初の準備として、今持っている答えは保留しましょう。それはきっと間違っています。愛着のある正当化一式も、箱に詰めてしまいましょう。その代わり苦痛 に目を向けます。どんな苦痛が、あなたを論争に導いたのでしょうか。メモリの解放漏れをデバッグする絶望感。あちこちにジャンプするソースコードを追いかけるストレス。間違いだらけのコメントが招いた混乱。何があなたを苦しめたのか、よく思い返してください。
今度は同じように、論敵の苦痛を探り出しましょう。彼も何らかの苦痛に突き動かされ、時に受け入れがたい主張を叫んでいるのです。その主張に同意する必要はありません。しかし苦痛には共感できることがあるはずです。喉まで出かけた買い言葉を飲み込み、彼の苦痛を聴き出してください。じっと目を見て、その苦しみに耳を傾けてください。
論争を招いた苦痛のリストは出そろいましたか。「 面倒くさい」「 イライラする」「 遅い」「 怖い」「 わからない」……生々しく身も蓋もない訴えほど問題をよくとらえています。トヨタの「5つのなぜ」と同じように「何がつらいのか」を繰り返し問い、建前の皮を剥ぎましょう。苦痛のリストは、隠された問題によって引き起こされている症状です。その隠された本当の問題を片付けるのが、私たちの探す答えというわけです。
答えのパターン
さて、論争は単なる問題解決に姿を変えました[2] 。その問題に挑むテクノロジを想像するのが次のステップです。ソフトウェア開発における問題解決にはそれなりのパターンがあります。冒頭に紹介した過去の例からパターンを考えてみましょう。
Malloc/Free論争はGCの普及によって意味を失いました。GCのように、面倒な作業を自動化 するのはソフトウェア技術が得意とするパターンの一つです。GCは自動化の中でも特に込み入った部類に属します。日々の小さな論争の種はもっと素朴な自動化で片付くものも多いはずです。自動化の恩恵はコードの中身にとどまりません。たとえばプロジェクトのルールに関する論争は、プロセスを自動することで片付くものも多いことでしょう。
Goto害悪論争は、例外機構の登場によって廃れました。例外機構は、大局的脱出という強力過ぎる機能にわかりやすい意味、抽象 を与えました。気の利いた抽象を編み出すのも、ソフトウェアが得意なアプローチの一つです。プログラマの仕事のうち大きな比重を占める作業でもあります。
コメント論争は、おそらく文書化のための優れたメディアの 登場によって姿を消すでしょう。ソフトウェア開発が社会的な営みである以上、コミュニケーションの手段であるメディアが持つ力を無視はできません。ベンチマークやユーザ動向などさまざまなデータをうまく可視化して見せるのもメディアの仕事に数えてよいでしょう。
自動化、抽象、メディア。網羅的とは言えませんが、出発点にはなりそうです。これらは互いに関連し合っています。抽象は自動化のきっかけになります。抽象によってまとめられた雑多な仕事を自動化によって片付けるのは良いアイデアに違いありません。自動化はメディアのコンテンツを作り出し、その流通を支えます。
妥協のベクトル
正しい答えを追い求めるときは、実現の手間や苦労をいったん脇によけて考えを巡らせましょう。すでに問題が山積みですから、それ以上悩みを増やすことはありません。目先の制約に気を取られ過ぎると理想が歪んでしまいます。
それでもアイデアが形になってきたら、いよいよ実現について考える必要があります。アイデアをそのまま実現できることもあるでしょう。とはいえ現実には何らかの妥協が必要になるほうが普通です。妥協をしてしまったら、結局問題は解決しないかもしれない、そう思うかもしれません。けれど振り返ってみると、進んだ歩みに気づくはずです。
論争に決着をつけようとしていたときも、何らかの妥協案が頭をよぎったことでしょう。その妥協は、自分と論敵の間のどこかにありました。第三の答えはふつう、その直線上にはありません。相手との間で綱引きをしても、ちっとも本当の答えには近づかないのです。答えを見つけたあとの妥協は答えにたどり着けないにせよ近づけはします(図1 ) 。
図1 第三の答え
多くの論争は直線上を探索するこの誤りに陥って終わるため、行く末は退屈なものがほとんどです。論争から身を引くことで、違う方向に目を向けられるようになります。
自分が今いる場所以外のどこかに、自分の知らない答えがあるかもしれない。世の論争は、そう気づくきっかけを与えてはくれます。論争にはそんな価値があります。しかし論争それ自体を追いかけても答えは見つかりません。答えは対立の軸を外れたどこかにあります。それを探す旅がソフトウェアエンジニアリングの進歩であり、エンジニアの成長なのだと思います。
さて、積年の論争に決着をつける論点を示す力は本連載にはありません。それでも少しだけ向こうにある正しい答えを探そうと一年間試行錯誤してみたつもりです。その試行錯誤も今回が最終回。お付き合いいただきありがとうございました。