一読してみて、これならば新人研修に使えるかもしれないと思いつつ、同時に研修に使うときには「元ネタ」を明確にしないとミスリードっぽくなるだろう。と思われたので、そのメモ書き。
参考文献のほうに
- リファクタリング
- デザインパターン
- Unit Test
が書いてあるので、XP のプラクティスに合わせてもいいと思われる。
コードの品質とは何か？
日本語でいうとこの「品質とは」に関係してくるので、「高品質なコード」と「低品質なコード」の比較や、「1.2 コードの品質にゴール」に書かれている４つの箇条書きのように漠然としてくると、新人（特にコードを書く前の新人）にはちょっと困った自体に陥るんじゃないかな、と思う。
ここでいう「正しく動くコード」というのは、動くべき仕様書に対応するコード、という隠れた意味がある。細かく言えば、動くべきことを記述した「仕様書」と、実際に顧客が想定している「動作」とは乖離があるわけで（あの例の顧客が求めていたものの図）漠然と、「正しく動くコード」あるいは「正しく動作し続けるコード」が先にでてくると、混乱するのではないか？
たとえば、建築で言えば、「正しく動くコード」というのは、家の屋根に相当する。
雨が降っても部屋が濡れないように屋根を付ける、という要望を出したとしよう。屋根があればいいので、実は柱が１本でもいい。傘のようなものでもいい。雨の量はここでは問わないので小雨をしのげるだけでもいいかもしれないし、台風に耐えるような屋根にする必要もあるかもしれない。
だから「雨に濡れないように屋根をつける」ようにコードを書くこともできる。エラー処理をつけないようなコードや、例外を受け付けないようなコード。ある程度の範囲は許容するけど、極値では落ちてしまうかもしれない。でも99%のデータは、中央値にまとまっているから、たいていの場合は「正しく動くコード」として扱うことができる。たまに、極値が来ると正しく動かないコードに陥ってしまう。
だから「正しく動く」の部分は範囲が広い。もう少し修飾するならば、「おおむね正しく意図的に動くコード」というべきだろうか。
「おおむね」というのは、画面からの入力はおおむね大丈夫な感じとか、マイナンバーカードを入れたときに氏名に外字が使われていない限りは大丈夫とか、半角カナが入ってない場合は大丈夫とか、そんな感じで、「おおむね」正しく動いている状態。
プログラマから言えば、この「おおむね」正しく動いている状態というのは、到底「正しく動く」の範疇に入らないように見えるのだけど、少なくとも、想定している数字やひらがなを入れたときにデータベースにきちんと保存されているね、ぐらいの気持ち、いわゆる「正常系」がきっちりと動いているのを「正しく動くコード」と緩い形で決めてしまってもいい気がする。
でも、プログラムというものは正常系だけで済むものではない。コードのほとんどは異常系や例外をうまく処理するためのものが多い。その部分が「正しく動き続けるコード」にあたる、と思われる。
正常系でうごいていても、何かの異常系で動かないことがある。これは正しいコードと言えるか問えわれれば、言える。だって、正常系が動いていて、顧客の要望もおおむね動いているわけだから、入力するときにちょっと注意を払えばだいたい正常に動くわけだから「正しく動くコード」といってもいいだろう。しかし、「正しく動き続けるコード」とは言えない。
そう、雨をしのぐための傘のような屋根を付けて、正しく雨がしのげる住宅、と言っていいようなきもするし駄目のような気もするのだが、少なくとも「雨をしのぎ続ける」ことはできない。そういう意味では、ちょっとした小雨のような雨ならばしのげる正常系かもしないがい、横から吹き込むような雨には無力な屋根だ。少なくとも壁をつけないと雨をしのぐという住宅の意味をなさない。これが「正しく雨をしのぎつづける」住宅と言えるだろう。
だから「正しく動くコード」でキーポイントになるのは、顧客の要求を正常に処理ができるか、緩い基準になる。コードという視点から言うと発散してしまいそうだが、仕様書とか要件定義という意味においては、まず第一に正常系の要求をきちんと処理できること、ひとまず例外などを除いた機能要件が満たされることが正しく動くコードというよりも「正しく動くソフトウェア」あたると思う。
ただし、このままだと品質工学的な意味での「品質」に達しない。低品質ということになる。
では、正しく動き続けるコードあるいはソフトウェアは何に気を付ければいいのか？ということになる。少なくとも、ちょっとした例外処理（外字を使うとか、半角カナとか）は対処しないと品質が高いとは言えないだろう。それは、ある程度の例外を許容して正常に動くというものがある。「ある程度の例外」というのがキーポイントになると思われる。
