先生「さて、どうしましたか？」

患者「頭がくらくらして、立ちくらみするんです。」

先生「ほう。」

患者「AジョブとBジョブの間のインタフェースがちぐはぐなんです。」

先生「なんでそうなった？」

患者「Aジョブ担当のAさんとBジョブ担当のBさんが、それぞれ独断で設計してしまったからです。」

先生「それは、まずい。」

患者「その他にも、関連したテーブルの項目桁数がばらばらなんです。」

先生「ほうほう。」

患者「そして、作っている途中で、仕様の不備が発見するんです。」

先生「なぜ？」

患者「エンドユーザに了解を取る前に設計してしまったからなんです。」

先生「以上かな？」

患者「いえ、他にもたくさんあるんですが、にたようなものです。」

先生「ふむ。これは、もう慢性的な鉄分不足による貧血だね。」

患者「どうしたら良いですか？」

先生「そうだね。あなたには、鉄分不足を解消するためにホウレンソウを処方しよう。」

患者「ホウレンソウってなんですか？」

先生「報告、連絡、相談。基本中の基本だ。これを徹底するんだ。今からでも遅くない。」

患者「先生ありがとう。」

というわけで、基本中の基本である、ホウレンソウはとても大事です。

おろそかにしないようにしましょう。

読みやすいコードというと、

「何をしているのか分かりやすい。」

という回答を得る場合が多い。

だが、それだけで果たして本当に読みやすいと言えるのだろうか。

今回は、本当に「読みやすいコード」とは何かを考えていきたい。

まず最初に、コードを読む必要があるケースをあげる。

１．そのコードを保守する時

２．そのコードを利用する時

特に前者の例が多いのではないだろうか。

以前書いたコードをデバッグしたり、他人が書いたコードをデバッグしたり、仕様変更に対応したり。

そして、次になぜコードが書かれているかといえば、

要求されている仕様を実現するため

だろう。

ということは、「読みやすいコード」とは、「どんな仕様を実現しているのかわかりやすいコード」である必要が出てくる。

例えば以下のような断片的な仕様を実現してみよう。

仕様：

商品区分の上2桁が”BB”のものと、”CC”のものはシステム対象外とする。

ただ、「何をしているか分かりやすい」シンプルなだけのコードの場合、以下のようになる。

Private Sub 何らかのメソッド(商品コード As String)
Select Case 商品コード.SubString(0,2)
Case Is = "BB","CC"
'システム対象外とする処理
Case Else
'処理
End Select
End Sub

確かに、上記の例は簡潔だし、そこだけを見ればよいので手っ取り早い。

だが、後々、このコードを見たときに

「何で、”BB”,”CC”の時だけ、この処理を行っているのだろう。」

「この分岐は、どんな仕様を実現しているんだっけ？。」

と、疑問に思わないだろか。

他人のコードだったらなおさらである。

そこで、もし、このコードが

Private Function システム対象(ByVal 商品コード As String) As Boolean
dim システム対象外判断部分 as String = 商品コード.SubString(0,2)
If システム対象外判断部分 = "BB" Then
return False
EndIf
If システム対象外判断部分 = "CC" Then
return False
EndIf
return True
End Function
Private Sub 何らかのメソッド(商品コード As String)
If Not システム対象(商品コード) Then
'システム対象外とする処理
Exit Sub
Endif
'処理
End Sub

だったとしたら、どうだろう。

前のコードと比べると明らかに冗長ではあるが、

「”BB”,”CC”の時はシステム対象外である。」

という仕様がコード上に残っているため、その分岐がどんな仕様を実現しようとしたのか、一目瞭然である。

また、その分岐の詳細仕様に興味が無い場合は、そこを見るだけで充分である。

そして、どんな時にシステム対象外なのか詳細仕様を知りたくなったら、その時に初めてその先のメソッドを見ればよい。

このようなコードは、一見冗長に見え、読む範囲が広がり追いづらくなるように見える。

だが、実際は、目的に応じて詳細レベルをコントロールできることで、より簡潔に目的にマッチした読み方ができる。

ぜひ、一度、

「コードに仕様を残す。」

という事に留意して、コーディングしてみてはどうか。

きっと「読みやすい（保守しやすい。）コード」になるだろう。