いくつも起因するお話はあるのですが、例えば最近おきたおもころいあたりだと、この辺(から、少し発展させた流れ)。
https://corp.gmo-pg.com/newsroom/pdf/170501_gmo_pg_ir-kaiji-02.pdf
P16
通常、コードレビューは、
コーディングを担当していないメンバーで
実施
されるところ、
保険特約料支払
い
サイト
の開発では、オンライン部分の構築
を担当していた
メンバー
がコーディングをしつつ、自らコードレビューも行
っていた。また、
保険特約料支払
い
サイト
においては、
コードレビュー後
に、検証が十分に行えていなかったこともあり、結果的にセキュリティコー
ドが出力されることになった
「自分でコーディングして自分でコードレビュー」ってあたりで色々と駄目感が漂う感じではあるのですが、じゃぁ「ほかの人がチェックしてたら気付けたんだろうか?」ってあたりで、一つ二つ。
で…まぁ今回は(できてなかったとはいえ)「コードレビュー」なので、「ほかの人がちゃんと読んでたらきっと気づいたんじゃないかなぁ」と好意的に考えたいところではあるのですが。
これが「ユニットテストによるチェック(と、ユニットテストコードのコードレビューっつかチェック)」だとすると。
ちょいと憂慮している可能性があって、そこについて、どうやってヘッジしていきましょうかねぇ? というあたりで、割と長々と、考えていたりしたので、思考整理かねてBlogってみようか、と。
例えば。それはもぉドドド簡単な関数ですが、以下の関数があって、それをテストしたいと考えます。
関数仕様
・関数名は f_add
・引数は2つ。intを想定。処理は「二つの引数を算術加算した結果をreturn」
・引数の「int以外のケースのエラー処理」は未想定。stringなら「PHPのデフォルトの変換に従う」とかしておく
例えばPHPUnitだと、こんなテストコードになると思われるのですざっくりですが。
public function testHoge() { $this->assertSame(f_add(1, 0), 1); $this->assertSame(f_add(1, 1), 2); $this->assertSame(f_add('a', 'b'), 0); }
これでテストコードが通れば、まぁとりあえず「実装はよいかなぁ」になるケースが多いのかなぁ、と思うのですが。
が。
が。
function f_add($i, $j) { if ( $i === 1 and $j === 0) { return 1; } if ( $i === 1 and $j === 1) { return 2; } if ( $i === 'a' and $j === 'b') { return 0; } }
って実装になってたら、どうすんだべさなぁ??? っと。
上述は些か「わかりやすく駄目すぎるコード」ではあるのですが。
実際に、これに近いような「駄目」コードを拝見した記憶が全くないわけではないような記憶が闇と深淵の彼方にわずかばかりに確認されている事が否定しきれない事実でありまして*2。
持ちろん「コードレビューしろ」って話にはなるかと思うんですが、「コードレビューしっかりしているうちはやらかさないんだけどだんだんコードレビューを薄くしていくと途端にやらかし始めるケース」なんてのも見受けられるわけでして……いやまぁぶっちゃけ「どうしたもんかなぁ?」と。
多分問題の根っことしては「"テストが通る事"は二次目標のはずなんだが一次目標としてとらえられて苦労するケースをどうするか(一次目標等は http://d.hatena.ne.jp/gallu/20101101/p1 参照)」ってあたりなんだろうなぁ、と。
で、これが「エンジニア間」であればまだ色々となんとかなりそうなのですが、発注側が「受け入れの検収タイミング」でこれに近い事をやらかされると「研修OK、いさ実際に使いだすと問題がじゃかすか」って話になって。
ここに「契約でがっちんがっちんに"テストが100%通る事"」になってると、発注側的に困るシーンもあるんじゃないかなぁ、などというあたりで、冒頭のPDF関連のお話にも少し絡んできそうな気がするわけですよ。
最終的にはまぁもちろん「受発注ともに、お互いとお互いのビジネスに敬意を払いましょう」ってお話にはなると思うのですが「払えない輩がいるからこその法的束縛」が必要なのですが……この辺って、どんなもんなんですかねぇ色々と。
なんてな事を、定期的に考えたり思案したりしています。