同僚プログラマーの機嫌を損ねずにミスを指摘できる“魔法の質問”：プログラマーにうまくアドバイスする心理的テクニック【前編】

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

[Joseph Ottinger，TechTarget]

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

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

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

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

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

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

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

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

• Javaの「変数」「メソッド」「定数」名の“ひんしゅくを買わない”付け方
• Javaで「ケバブケース」はなぜ駄目？　「参照型変数」「パッケージ」の命名規則
• その変数は「パスカルケース」「キャメルケース」「スネークケース」「ケバブケース」のどれなのか？　命名規則の違い

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

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

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

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

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

TechTarget発　先取りITトレンド

米国TechTargetの豊富な記事の中から、最新技術解説や注目分野の製品比較、海外企業のIT製品導入事例などを厳選してお届けします。