コード読んでる時間のほうが長かった。自分のプロジェクトではない以上、どういうふうに書かれているか、どういう方向で書こうとしているかを読み解く必要があるし、そうでなくてもファイル配置あたりから、どこに何がっていうのを最初に把握しないといけない。コード内で使われている名前が実際にサービスに出てくるような名前でないこともあるし、フレームワーク自体も内製のものだから、そっちの機能を把握しないと、どこにどこまでのことを書くかっていうのが、感覚的にわかるようにならない (あとあとメンテを少しでもするなら、余裕があるうちに、慣れをつくらないといけない)。

とにかく、時間を決めてその中で、というのを考えて、いじる範囲を狭くして、絶対に必要になるだろうファイルだけ作って、読むほうを優先した。全部の機能を把握しとかないと、そもそも処理をまとめた機能クラスを作れないし、今回の場合、既に機能はどっかにあるのに、自分で実装してしまうとテストが一段増えてしまう。編集範囲を広げたりファイルを無闇に増やす (設計を細かくわける) と、バグったときに見るべき、辿るべきパスが多くなってめんどうくさく、各レベルでテストを書かないといけなくて書かなければならないコード量が増えすぎる。

今回のは、DB 設計も、モデルロジック書きもしていないし、API 自体の設計も互換と最初に決めた時点で考えることは殆どなかった。テストは単純なテストをとにかく書きまくっただけだ。開発環境とかデプロイとかはすごくよくできていて、余計なことは考えなくてすんだ。でも、もっと早くできたかはわからない。

時間制限をかけて緊張感をそこそこに持続させつつ開発をしてみたけれど、それでもリリース直前とか直後になんか起こったりする。「なんか起こる」って思っているから起こるのかもしれない。