ここから 1 年くらい経ったので振り返ってまとめてみました
結果
まず最初に執筆 ( 2025/03/14 ) 時点でのパッケージ数とパッケージ化済ファイル数は以下の通りです
- 64 [packages ]
- 1184 [ files ] ( ※テスト含む )
イメージ的には 1 [ package / 週 ] くらいのペースで新しいパッケージ作られていて、テストを除くと平均 10 [ files / package ] くらいの粒度でパッケージ化されてますね
テストやドキュメント含めて 150 [ files / 週 ] くらい変更されているので、1 割くらいがパッケージに関する変更になりそうです
個人的には 1 年で割と浸透した印象ですね
感想
次にパッケージ化している最中やパッケージ関連での個人的な感想です
よかったこと
巨大な機能が把握しやすい
全体の方針としては、パッケージ統合は分割に比べたら楽なので、極力小さな単位でパッケージ化するようにしています
これにより、パッケージにまとめてみたら意外とファイル数が多かったり、いくつものパッケージがないと成り立たない機能などが浮き彫りになったりするので、大き過ぎる機能がわかりやすくなりました
機能の大きさがわかることで、リファクタの対象にしたり、機能追加の時に見積もりやすかったりなど、いろいろなメリットがありました
開発者が認知してなかった依存に気付ける
すべての依存を検知してくれるわけではないですが、検知対象の依存関係でも十分に有益でした
ToDo を解消している時、認知していない依存に気づき、その依存関係や仕様を理解することで、考慮漏れでバグるみたいなことが防げていると思います
まれに依存が循環している場合もあるので、これらに気付いて修正することで質は上がっていると思います
パッケージの責任者にレビュー依頼されるのが楽
GitHub のコードオーナ機能を使ってパッケージのディレクトリには必ず責任者を設定するルールにしているのですが、これがとても便利です
対象のパッケージの依存関係に変更があると機械的にレビュー依頼されるので、依頼漏れがなくなります
また、パッケージ単位だと細かすぎず荒すぎないくらいなので、設定ファイル自体もシンプルで管理しやすいです
気になったこと
パッケージ化には時間がかかる
新規でパッケージを作る場合は依存も少ないのでさほど気になりませんが、既存のファイルをパッケージ化する場合、依存関係の量次第ではかなり時間がかかります
パッケージに含めるか、パッケージの粒度を変更するかなどを判断する必要があるので、その分パッケージ化しないよりは時間がかかります
個人的にはいつか払うコストなので、完全にパッケージ化だけに伴うコストではないかなと思っています
ToDo が残り続ける
RuboCop の ToDo でもそうだと思うのですが、計画的に対応するなどしないと同じように増え続けます
また、package_todo の解消は設計を変えなければ解消できないことも多々あるので、さらに難しく時間がかかる印象です
すべてを今すぐに解消すべきとまでは思っていませんが、健全だと思える状態までも長い道のりになりそうです
もし今から packwerk を導入するなら
素の状態だとファイル移動やディレクトリの作成が手間だったので、ツールを最初から作ってハードルを下げるべきだなと思います
弊社の場合は VS Code ユーザが多かったので tasks.json で新規パッケージ作成用タスクを定義しました
あとはパッケージの命名規則は決まっていたので、1 つ 1 つにコードオーナを設定するのではなく、命名規則にのっとってワイルドカードで指定してもよかったかなと思います
弊社の packwerk 関連記事
Discussion