同僚プログラマーの機嫌を損ねずにミスを指摘できる“魔法の質問”

プログラミングで重視すべき項目や、より良いソースコードをチームで作り上げるこつは何だろうか。エンジニアの実体験を基に解説する。

公開 2022年02月04日 05時02分

著者

Joseph Ottinger

[TechTarget]

印刷する連載新着通知を受け取る

　幾つものメディアやブログが、プログラミングで何を重視すべきかを解説している。例えばネイサン・マーツ氏は、同氏のブログ「thoughts from the red planet」の「Suffering-oriented programming」というエントリ（投稿）で、

プログラムが正しく機能すること
ソースコードが美しいこと
プログラムの処理速度が速いこと

という順番でプログラミングの目標を設定するように勧める。「機能すること、美しいこと、速いこと」はまさに本質を突いた名アドバイスだ。その言葉を初めて見たときから、私は心に刻んできた。

　「機能すること」が最も重要なのは、ソースコードを解釈してもらう最も重要な「相手」がCPUだからだ。2番目が「美しいこと」なのは、CPUの次に重要な相手が、ソースコードを読み、保守する同僚プログラマーだから。「プログラミングの相手はCPUと同僚プログラマーだ」というのは、私もかつて主張したことがある。

　ソースコードがCPUを相手とする要件を満たし、かつ一緒に仕事をする人にも理解可能であるという要件を満たして初めて、プログラムのパフォーマンスを高める仕事に取り掛かることができる。美しいソースコードは改良もしやすい。おおよその場合、ソースコードを美しくすることは、小さな関数に分割することだ。

対立を起こさず穏便に対処する“魔法の質問”とは？

併せて読みたいお薦め記事

プログラミングのテクニック

　最近友人が、あるトラブルについて話していた。私も似た経験のあるトラブルだ。友人は、あるチームが何の監督も受けずに作成したソースコード群を結合する立場にあり、そのソースコードの不備に悩んでいた。テストが不十分で、サイロ化（ソースコードやプログラムごとに運用管理）されており、メインプロジェクトのコーディング基準に従っていなかったという。

　これは頭を抱える事態だ。そのようなソースコードを結合するには、本来ならテストで示すべきエントリーポイント（プログラムを実行し始める場所）を探さなければならない。本来ならそのソースコードが要件を満たしているかどうかもテストで分かるはずだ。だが、そもそもテストが存在しないため、要件を満たしているものだと信頼するしかない。

　このような場合、どのようなアドバイスをしたらよいのだろうか。

　先に述べたように、私も似たような経験があった。人は、その相手が誰または何であれ、対立を嫌がるものだ。そこで私は「相手のソースコードに悩まされている」人の役を演じることにした。ソースコードそのものに対する批判は口に出さず、「ソースコードについて分からない点があるから教えてほしい」と、同僚プログラマーに頼んだのだ。

　「この機能のテストはどこにあるのだろうか」。テストが存在しないことは分かっていたが、同僚プログラマーにあえてそう尋ねた。こう質問することで、テストが必要だということを相手に穏便に伝えることができる。相手が自分で判断する余地を与えることにもなる。