最近僕が途中から参画することになった大規模プロジェクトなんだけど、末端になるとメンバーの練度が足りてなくてわりとつらい。開発プロセスには当然のようにユニットテストをちゃんと書いてカバレッジを計測するとかカバレッジ目標だとかそういうことが定義されているのだが、個人的には完璧に網羅性のあるユニットテストを書いてテストするモチベーションが現時点では起きなくて困っている。
このプロジェクトの独自フレームワークの上で動作するプロダクトなのだけどそのフレームワークのAPIを策定した人たちの言語能力がイマイチだったらしく、定義されているインタフェースがおかしかったりそこに大量のtypoがあったりしているのだ。classやmethodやデータ構造に関する識別子に出てくる英語が悉くおかしいのだ。ファイルパスの意味のpathをpassと書かないといけなかったり、行列の行(row)がlowと定義されていたり、UI要素の縦幅のことをheightではなくvirticalWidthなどという聞いたこともないような識別子でアクセスしなければいけなかったりする(これはきっと「縦幅」をGoogle翻訳にかけたらvertical widthと出てきたからだと思うがそこにtypoが混ざって邪悪さが増している)。このようなおかしなセンスを強要された上にさらにテストを書いてそれの正当性を強化させられるというのはかなりつらい。
今日見た下記のスライドには、たぶん、ちゃんとテストコード作ってテストやろうぜ、それが誠実なんだ。みたいなことが書かれていたのだけど
ソフトウェアクラフトマンシップとプログラマーの誓い - Forkwell Library #8 | ドクセル
今の自分が置かれている環境でちゃんとテストコードを作っていくことは上記のスライドの「約束1: 有害なコードを作らない」に反しているような気がしてしまう。だからといって1000人を超える開発者がよしとしてこれまでやってきているものを新参者の自分が反対して通るような気がしない(実際通らなかったからこうなっているわけで)。いまの開発中のソフトウェアをまともにするためには既に作られたユニットテストたちを一時的に破壊して大幅にいろいろな部分を修正する必要があり、自分としてはそれはやるべきことだと思うのだけど何が正しくて何が悪かは人によって違うのだ。いまのプロジェクトにおける平均的な日本人開発メンバは英単語がおかしいとか、日本人以外から見たときに頭おかしいと思われるくらい、ユニットテストが崩れていることに比べれば大したことないと感じているようで、僕が自分にとって正しいと思う方向の意見を言ってしまうとプロジェクトメンバからは不誠実なやつ扱いを受けてしまう状況なのだ。
うまく文章化できないが「テストコードを二の次にするやつは誠実じゃない」みたいなのを見ると心が痛んでしまう。そんなことより大事なことがいっぱいあって、それができていないことのほうが個人的には大事なのだ(たとえばテストコードがちゃんと通ることより紫色のenum値がREDと定義されていないことのほうが大事だ)。でもここでのKPIはテストのカバレッジやトレーサビリティ、そしてスケジュールだ。ここから逃げるには退職してどっかにいってしまうしかないような気がしてしまう。退職かあ。
