コードの修正耐性という視点 - 新人プログラマーへ

こんにちは、シュンです。

俺は専業のプログラマーではないですが、去年新人プログラマーのメンターをする機会に恵まれました。

この時の経験から、経験の浅いプログラマーは「コードの修正耐性」という視点が欠けているのではないかと思うようになりました。

彼が意識していたのは、「速さ」と「可読性」のトレードオフだけでした。

速さと可読性という指標

速さと可読性という指標はよく知られています。

速さを求めたコードというのは例えば、イベントシステムを介さずに処理をべた書きすることなどです。

一方可読性の高いコードとは、他人にとって読み・理解しやすいコードのことです。

我流ではなく一般的なパターンに沿った設計をすることから始まり、変数名も英語としての読みやすさが考慮されたコードです。

これらは言ってみればコードの「今」の価値に重点をおいた「共時的」な視点です。

一方で修正耐性という指標は「未来」に重点をおいた「通時的」な視点です。

修正耐性という指標

「速さ」「可読性」の他に俺が提唱したいのが「修正耐性」という指標です。

「コードが不特定多数に修正された場合のバグの入りやすさ」を表します。

これにより、コードレビュー時に速さと可読性という指標では指摘できなかったものが指摘できるようになります。

修正耐性の低いコードと高いコード実例

修正耐性の低いコードを例を示します。

管理者なら管理バーを画面上部に表示する、というようなC#のサンプルコードです。

if user.IsAdmin()
    ShowAdminBar();

このコードは速度・可読性の点では問題ありません。

これを修正耐性高く書き換えたコードが以下です。

if user.IsAdmin()
{
    ShowAdminBar();
}

この修正でなぜ耐性が上がるのか。

例えばこのコードがリリースされた半年後に新人Aがジョインしたとします。

そこで初めての実践タスクとして、

「管理者なら広告を隠す」

というタスクを行うとします。

新人Aは既存のコードを読み、ここが修正箇所になることに気が付きます。

「ここに1行追加すればいいな。」

if user.IsAdmin()
    ShowAdminBar();
    HideAds();

修正完了。動作確認をします。

擬似的に管理者でログインしてみます。

確かに管理者バーは表示され、広告が表示されないことを確認できました。

さて、この新人Aは後日QAチームや顧客からバグの報告をもらうのです。

「管理者以外のユーザーにも広告が表示されていない」と。

ある程度プログラミング言語をご存知の方ならifブロックが直後の1ステートメントにしか効かないことをご存知でしょう。

しかし新人Aはインデントでブロックが表現されると思いこんでいました。

この場合もともと{ }が明示されていれば、以下のようになります。

if user.IsAdmin()
{
    ShowAdminBar();
    HideAds();
}

バグを生み出すことは無かったのです。

ここで注目すべき点は、速度・可読性に関係ないということです。

また、別段コストはかからないのでトレードオフもありません。

修正耐性の高いコードを書くために

修正耐性の高いコードというのがどういうものか分かりました。

では修正耐性の高いコードを書くために何に気をつけたら良いでしょうか？

可読性をあげる

可読性と修正耐性は正の相関関係にあります。

可読性をあげるには以下のような方法があります。

• チームで使用されていないシンタックスを使わない
• 変数のスコープは極力小さく
• ネストを深くしない

などです。他所でも多く語られているのでこれ以上は列挙しません。

リーダブルコードにほとんど書いてあります。

一度は読んでおいて下さい。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

C#についてここで特筆するとすれば、匿名関数のキャプチャの危険性です。

ローカル変数を意識せず匿名関数でキャプチャしてしまうと、影響が極小であるべき変数の寿命がコントロール不能になり影響範囲が把握しにくくなります。

常に未来の他人のミスを想定すること

今現在コードを書きながら、同時に未来の他者がそのコードを修正しているような２つの視点を持つことが重要です。

チームメンバーのうち誰でも良いので対象を心のなかで決めておくと良いです。

俺はチームで一番不注意なメンバーBさんに改修されることを常に意識してコーディングしていました。

文章も一緒ですよね？

具体的な１人の読み手を想定して書くと格段に文章がよくなります。

• 「Bさんだったらこの変数名の英語のニュアンスは伝わらなそうだな」
• 「Bさんはこの設計の意図に気づかなそうだな」
• 「Bさんはうっかりここの処理の順番を入れ替えそうだな」
• 「この導出は今のメンバーがいなくなったら再現できないな」

などです。

まとめ

コードをより良く書く・レビューするために「修正耐性」という指標を導入しました。

そのために

1. 可読性をあげる
2. 常に未来の他人のミスを想定すること

という方法を紹介しました。

ぜひ現場で使ってみて下さい☆