テーブルを追加したらコンパイルエラーでビルドできなくなった話

こんにちは、サーバエンジニアの池脇と申します。
今回は私が実際に経験した失敗談とそこから得た学びについてまとめようと思います。
どなたかの参考になれば幸いです。

テーブルを追加しただけでコンパイルできなくなった！？

JavaのSpringBootを使って新規テーブルを追加する作業は開発者にとって日常的な作業です。
しかし、ある日新規テーブルを追加し、いつものようにコードの自動生成を走らせてビルドを行ったところまさかのコンパイルエラーに直面しました。
エラーの内容は

パラメータが多すぎます。(too many parameters)

というものでした。

なぜコンパイルエラーが起きたのか

上記エラーの内容と発生箇所から、これはコンパイラが受け付けるコンストラクタのパラメータ数が上限を超えていることが原因ということはわかりました。
しかしなぜエラーが発生したのか……？

エラーの発生に至った背景を探ると次のことが明らかになりました。
私のプロジェクトでは、マスタデータのキャッシュを暖気するためのクラスを自動生成していました。このクラスは private final xxxDaoといったfinalフィールドをテーブルの数分自動生成によって宣言し、@RequiredArgsConstructorの特性を利用してコンストラクタの生成を行なっていました。

@RequiredArgsConstructor
public class CacheWarmUpController {
    private final FooDao fooDao;
    private final BarDao barDao;
    // ...
    private final BazDao bazDao;

しかし、新しいテーブルを追加したことで、このxxxDaoの数が255個を超えてしまい、生成されたコンストラクタのパラメータ数がJavaの上限を超えたためにコンパイルエラーが発生しました。

どう対処したのか

今回は各マスタデータ用のxxxDaoを直接ApplicationContextからgetBeanする方法を選択しました。
これによりコンストラクタ内で大量のxxxDaoを直接受け取る必要がなくなり、コンパイルエラーを回避することができました。

@RequiredArgsConstructor
public class CacheWarmUpController {
    private final ApplicationContext applicationContext;

    public String warmUpMasterCache() {
        FooDao fooDao = applicationContext.getBean(FooDao.class);
        BarDao barDao = applicationContext.getBean(BarDao.class);
        // ...
        BazDao bazDao = applicationContext.getBean(BazDao.class);

今回の失敗から得た学び

• 動的に変化する要素に対する注意
  自動生成の際に動的に増減する要素（今回であればテーブル数）が上限を超えないよう、慎重に設計と管理を行う必要があります
• 使用しているアノテーションの詳細について把握
  @RequiredArgsConstructor等のアノテーションを使用する場合は、そのアノテーションが何をするものなのか把握した上で影響範囲をしっかりと確認しなければいけません

まとめ

今回の失敗からは普段使用しているものの制限や上限等を把握しておくこと、またそこに抵触する際の対処法を検討しておくことの大切さを学びました。
特にコード自動生成の領域では、プロジェクトの規模や複雑さが増すにつれて思わぬところで上記のような問題が発生するかと思います。今回のような失敗談は決して珍しくなく、他の開発者たちも同様の課題に直面することもあるでしょう。この経験を共有することで、より良いプログラム設計や問題解決のアプローチにつながることを期待しています。