この記事について
「Willgate Advent Calendar 2018」25 日目の記事です。
また、この記事の続きになります。
「バグる余地が無いように『考えて』作る」ことについて
前の記事では「人間の注意力には限界があるんだからバグらないように『気をつける』んじゃなくて、バグる余地が無いように『考えて』作ろうぜ」という旨の内容を書き、一方で最近になってこの考え方について思うところがある、と締めくくりました。
確かに自分のコードを書いている分にはそれである程度うまくいっていたのです。
しかしチーム全体のコードに目を向けるようになったところで問題が生じました。
チームでも極力バグる余地が無いようなコードを書いていくために、良いコードについての考え方をチームメンバーに伝えたり、設計・実装方針を定めてドキュメント化したり、という方法を取りました。
すると、今度はこういった「考え方」「方針」が守られているのか気をつける必要が出てきてしまったのです。
これでは本末転倒です。
とあるプロジェクトマネージャーの話
ここで少し話が飛びますが、私がコードの品質について悩んでいたときにプロジェクトマネージャーから聞いた話について書きます。
プロジェクトマネジメントの観点においては「素早く作ってテストの段階で多くのバグが出る」という作り方と「丁寧に作り込んでテストの段階でバグが出にくい」という作り方では後者の方がリスクが大きいそうです。
曰く、前者の場合は「テストによって見つかるバグの数が増えるペース」と「見つかったバグを解消するペース」からデバッグがいつ頃収束するか早い段階で予想を立てることができます。 一方、後者の場合はテストのタイミングが遅くなるうえに*1、バグが見つかるペースも遅い*2ので、予想の精度も下がります。
これで万が一想定以上にバグが出てしまったら、その時点でプロジェクトの遅延が決定していまう、ということです。
この話を聞いたときは目からウロコが落ちました。
これらから思うこと
これまで「バグが入り込む余地が無いように『考えて』作る」ことを意識しつづけてきましたが、これらを受けて本当に考えるべきことは「バグが入り込んだ際に早い段階で検出できる仕組み」なのではないか、と考えるようになりました。
前の記事に書いた「データを連想配列ではなく、クラス+型で表現する」というのも型不整合によるエラーでバグを早い段階（実行する前）で検出する、という工夫と言えます。
直近関わったプロジェクトでは PHPStan や Phan による静的解析を CI で実行し、引数・戻り値型や PHPDoc の不整合を自動で検出できるようにしました。これは実際にプルリクのレビューの負荷が減ったので、良い方法だと思っています。
チーム開発において、設計・アプリケーションアーキテクトはそれ自体が優れているだけではだめで、それを守るための仕組みも両軸で考えていかなければ価値を充分に発揮できないのではないでしょうか。
おそらくこれについては色々な意見があると思うので、多くの人の意見を聞いてみたいと思います。
