レガシーコードとテンプレートの物語 - 現場からの考察 • AQZ Tech Chronicles

先日、あるレガシーシステムの改修を依頼されました。コードを開いた瞬間、目に飛び込んできたのは無数の「<?php echo $hoge ?>」という記述と、 HTMLを出力する大量のecho文でした。同じようなコードブロックが幾度となくコピー＆ペーストされ、条件分岐の中にHTMLが埋め込まれ… まさに「レガシー」という言葉がぴったりのコードベースでした。

現状の課題 - 混沌としたコードベース

コードを読み進めていくと、問題点が次々と明らかになっていきました。 HTMLとPHPのロジックが密接に結合し、同じようなスニペットが数十箇所にコピーされ、ループ処理すら手作業でコードを複製することで実現されていました。保守性という観点からすれば、まさに悪夢のような状況です。これこそが典型的なレガシーコードの例です。こうしたコードは、単に「古い」だけでなく、他の人が簡単に理解できないため、結果的に保守作業が困難になります。

改善の可能性を探る - テンプレートエンジンという選択肢

「これは何とかしなければ」という思いから、まず頭に浮かんだのは現代的なテンプレートエンジンの導入でした。テンプレートエンジンは、HTMLなどの見た目に関する部分と、プログラムロジックを分離するためのツールで、PHPやPythonなどで広く利用されています。 WordやGoogleドキュメントで差し込み印刷のテンプレートを選ぶ感覚に近いですね。この手法を使えば、表示とロジックを綺麗に分けられるため、コードの見通しが良くなり、保守性が向上します。

特に、同じページデザインを複数の言語や条件で切り替える必要がある場合、テンプレートエンジンは非常に役立つツールです。しかし、この段階で気づいたのは、レガシーコードをテンプレートエンジンに移行する際には多くの課題が伴うということでした。

しかし、その前にちょっと立ち止まって考えてみましょう。そもそも「テンプレート」とは何なのでしょうか？

テンプレートの本質を探る - 歴史からの学び

テンプレートという概念は、プログラミングの世界で実に興味深い進化を遂げてきました。 1970年代初期、単純なマクロによるテキスト置換から始まったこの概念は、現代のクラウドネイティブアプリケーション開発に至るまで、形を変えながら発展し続けています。

初期のテンプレート機能

1970年代、テンプレートは本質的にテキスト置換のメカニズムでした。当時のUnixシステムでは、sedやmなどのツールを使って、定型的なコードパターンを生成していました。これは原始的ではありましたが、コードの再利用という考え方の重要な第一歩でした。

C++時代の革新

90年代に入り、C++が本格的なテンプレートプログラミングの概念を導入しました。私自身、この時期にWin32プログラミングを通じてテンプレートの威力と、同時に低レベルプログラミングの苦労を身をもって体験しました。例えば、単純なグラデーションを描画するだけでも、GDIを使って数十行のコードを書く必要がありました。

そんな中、STL（Standard Template Library）の登場は衝撃的でした。特にMFCでは、CWndやCDialogといった基本クラスが再利用可能なテンプレート的な設計となっており、煩雑なWin32 APIの処理を大幅に簡略化しました。ただ、実際の業務ではテンプレートそのものを書く機会は少なく、主にこうしたクラスを活用する立場としてその恩恵を受けていました。

その後、.NET Frameworkの登場で、C#ではグラデーション処理が数行で書けることに驚き、悔しい思いをしたものです。これは、抽象化の力を如実に示す例でした。

Webテンプレートエンジンの台頭

2000年代に入ると、Web開発の分野で新しい形のテンプレートが生まれます。 PHPのSmartyやRubyのERBなど、HTML生成に特化したテンプレートエンジンの登場です。これらは、プレゼンテーション層とロジック層の分離という、現代のWeb開発における重要な原則を確立しました。

モダンフロントエンドの革新

さらに興味深いのは、ReactやVueなどのモダンフロントエンドフレームワークによるテンプレートの再解釈です。 JSXやVueのテンプレート構文は、従来のテンプレートエンジンとは異なり、コンポーネントベースの再利用性を実現しました。これは、Win32から.NET Frameworkへの進化と似ています

既存の基盤の上に、より抽象度の高い新しい概念を構築していくアプローチです。

クラウド時代への進化

現代では、Infrastructure as Code（IaC）やクラウドフォーメーションテンプレートなど、インフラストラクチャレベルでもテンプレートの概念が活用されています。 IaCは、ネットワーク、仮想マシン、ロードバランサーなどのインフラストラクチャを、コードとして定義・管理する手法です1。手動設定を避け、一貫性のある環境を実現するものです。これは、テンプレートという概念が単なるコードの再利用から、システム全体の構成管理にまで発展したことを示しています。

現実との向き合い方 - できることとできないこと

しかし、目の前のレガシーコードに話を戻すと、状況はそれほど単純ではありません。コードベースがあまりにも複雑に絡み合っており、テンプレートエンジンの導入は予想以上に困難であることが分かってきました。

ロジックとHTMLが密結合している箇所を分離するだけでも大きな工数が必要で、さらにその作業自体が新たなバグを生む可能性も高い。完全な改善を目指すことは、現実的ではないかもしれません。

実際、PDF出力機能の追加時には、当初Bladeの導入を提案されましたが、 Laravelなしでは使えないという制約があり、代わりにPlateを採用しました。また、UIの改善にはJavaScriptを使わないシンプルなCSSフレームワークであるBulmaを選択しました。これは、レガシーシステムへの導入のしやすさを重視した判断でした。

結論 - 負債との付き合い方

テンプレートは確かにその歴史の中で役割を広げ、強力なツールとなってきました。しかし、それは万能薬ではありません。時には、段階的な改善を受け入れ、古いコードと新しいコードの共存を許容することも、現実的な選択肢となるのです。

大切なのは、理想と現実のバランスを取りながら、持続可能な改善の道筋を見つけることではないでしょうか。すべてを完璧にしようとするのではなく、必要に応じて部分的な改善を重ねていく。それこそが、実践的なソフトウェア開発の知恵なのかもしれません。

「負債は一度に返済しなくてもよい」という気づきは、テンプレートについての歴史的な考察から得られた、意外な収穫でした。技術は確かに進化し、より良いツールや手法が次々と生まれています。しかし、それらを適切に活用するには、現実的な判断が必要なのです。

レガシーコードは地雷と同じ

正直に言えば、このレベルで仕事している人は少なくないだろうと思うと、少々落ち込みます。ただ、別の案件ではもっと深刻な状況に遭遇したこともあり、相対的に見ればまだマシな方かもしれません。

そう思っていた矢先、レスポンシブ対応のCSSが書けないためか、モバイルかどうかでCSSが分かれており、その上、モバイルのときしかビューポートを設定していないことに気づきました。認証やセッション、DBの扱いも…思い出すだけで怒りが込み上げてきます。

こうした状況に直面すると、心が折れそうになることもあります。それでも、小さな改善を積み重ねるしかありません。完璧を目指すのではなく、現実に向き合い、まずは動く仕組みを少しでも良くする。それが、この仕事の本質なのだと思います。

数年前、このコードを書いた人と話をしたとき、「シェルの使い方がわからないので、 FTPで一度ローカルにダウンロードしてから別のフォルダにアップロードする」と言われたことがあります。たった一行のcpコマンドで済む作業を、わざわざ手間のかかる手動操作で行う姿に、技術的なギャップの大きさを痛感しました。

そのとき、このシステムには関わりたくないと強く思ったのですが、気づけばここまで関わってしまった以上、仕方がありません。これが現実であり、向き合うしかないのです。