ブログトップ

公開日:

更新日:

13 min read

技術革新

レガシーコードの地雷：反面教師に学ぶエンジニアリングの重要性

レガシーコード エンジニアリング MVC AJAX システム設計 セキュリティ 保守性 Webアプリケーション
レガシーコードの地雷：反面教師に学ぶエンジニアリングの重要性のイメージ

他人が作ったウェブシステムのレガシーコードと格闘しています。これ、プログラマーが一人で作ったのかな？ウェブシステムをプログラマーとデザイナーが仕事を分担していれば、一般的にはMVCモデルにより、デザインとレイアウトとコントロールは分離されます。これは2000年代初めには実現されていました。ただ、このころはまだAJAXが無かったような気がします。調べてみるとAJAXが普及したのは2000年代後半でした。

はぁ…、基本的なエンジニアリングについておさらいしたい気分です。

Webアプリケーション開発の基本原則

関心の分離(SoC:Separation of Concerns)

ページを作るのに必要なことは、各要素の役割分担です。

HTML

  • 文書構造の定義
  • テキストコンテンツの管理

CSS

  • レイアウトの制御
  • スタイリングの担当

JavaScript

  • 動作や振る舞いの実装
  • インタラクティブな機能の追加

この分離により、各技術の役割が明確になり、コードの管理や保守が容易になります。また、それぞれの関心事を適切に分離することで、より柔軟で拡張性の高いWebアプリケーションを構築することが可能になります。

これは「関心の分離」（Separation of Concerns、SoC）と呼ばれ、これはWebアプリケーション開発における重要な設計原則です。

MVCモデルによる役割分担

まず、ページを作成する技術を考えます。

  • html: フロントエンド
  • javascript: フロントエンド
  • css: デザイン
  • php: バックエンド
  • sql: バックエンド

つまり1つのページを作るのに3つの職種が必要です。

  • フロントエンド担当
  • デザイン担当
  • バックエンド担当

これを詳細に落とし込むと次のようになります。

Model（モデル）：バックエンド

  • データベースとのやり取りを担当
  • ビジネスロジックの実装
  • データの取得、更新、保存を行う

View（ビュー）：デザイン

  • ユーザーインターフェースの表示を担当
  • HTMLの生成を行う
  • ユーザーからの入力を受け付ける

Controller（コントローラ）：フロントエンド

  • ModelとViewの仲介役
  • ユーザーからのリクエスト処理
  • 適切なModelの呼び出しとViewへの指示

これをMVCモデルと呼びます。

メリット

  • 役割分担による効率的な開発が可能
  • 各コンポーネントの独立性が高く、変更への対応が柔軟
  • チーム開発における分業が容易

MVCモデルは、アプリケーションの規模が大きくなるにつれて重要性を増し、コードの保守性と再利用性を高める効果的な手法として広く採用されています。

つまり、デザイナーとプログラマーが分業できるようになります。 これは、後々の保守性に大きくかかわります。 初期開発ではプログラマーがおざなりなページデザインで済ませても、そのあとデザイナーがCSSできれいにできるからです。ウェブシステムあるあるですね。

反面教師としてのレガシーコード

AJAXの誤った使用法

ところが、今回のレガシーシステムでは、次々と変化球、いや、ビーンボールというか、暗器というか、反則というか…そう、トラップです。保守をさせない、ベンダーロックインならぬプログラマーロックインをするかのような罠が、システムのあちこちに仕掛けられてるのです。

発見されたアンチパターン

問題のコードはこういう流れになっています。

  1. ページにセレクトボックスがあります。
  2. セレクトボックスの内容は動的に変化します。
  3. ページがAJAXでサーバーにセレクトボックスの内容を問い合わせます。
  4. JavaScriptで受け取った内容をセレクトボックスに追加します。

一見、フローは問題ないように見えます。しかし、実装方法に深刻な問題があります。

データとプレゼンテーションの混在

一般的にサーバーから送られてくるのはデータです。この「データ」は、セレクトボックスに追加する内容のメタデータです。

本来のJavaScriptの処理は：

  1. ページにセレクトボックスを追加
  2. 追加したセレクトボックスにデータを追加

このような流れになるはずです。

しかし、このシステムではセレクトボックスのHTMLコードそのものをAJAXで受け取っているのです！

    	echo '<input type="hidden" id="spid'.$trows.'" name="spid'.$trows.'" value="">';
	echo '<select name="proid'.$trows.'" id="proid'.$trows.'" onchange="updatesellingprice(this.value,'.$trows.')"><option value="">- 選択 -</option>';
	...データベースからデータを取得
	while(データが尽きるまで){
		$pid = $data["pid"];
		$pproname = $data["pproname"];
		echo '<option value="'.$pid.'">'.$pproname.'</option>';
	}

	echo '</select>';

なるほど、ajaxでhtmlまで生成して渡してしまえば、受け取る側は何も考えなくていいですね！ おまけに認証らしいコードも書いていないので、誰でも呼び出せて便利です。 素晴らしい、なんて斬新なコードなんでしょう！

んなわけない！！！！突っ込みどころが満載です。

深まる謎

このシステムは、英語で使用される可能性が皆無なのに、インターフェースが英日切替可能となっていて、 それがさらに保守性を3段くらい悪くしています。 それくらいこだわった英日切替機能なはずですが、ここでは日本語がハードコーディングされています。

なぜ？？？

ajax部分は違う人が担当したのだろうか…。

深刻な問題点

いやいや、私は10年も現場から離れていたのだ。それにphpを使うのも1年ぶりだ。 AIに客観的な意見を求めようじゃないか。

このコードには以下の問題点があります：

  1. セッション確認がない（セキュリティの問題）
  2. HTMLとPHPのロジックが混在している（関心の分離ができていない）
  3. レスポンスがHTMLを直接出力（APIとしての設計になっていない）
  4. CSSのための構造化やクラス名などが不十分（メンテナンス性が低い）
  5. コードのドキュメント化がされていない（可読性・保守性の問題）
  6. MVCモデルに従っておらず、ビジネスロジック（M）、表示（V）、制御（C）が単一ファイルに混在している

現代的なアプリケーション設計の観点からすると、このコードは完全にリファクタリングが必要な状態です。

結論

だよね？そうだよね？私は間違ってないよね？

ふざけるなああああああああああああああああああ！！！！ （魂の叫び）

せっかく、本体側をイベントリスナーに変更したのに…のに（涙）まさか、動的追加の要素がインラインだなんて…（涙）

それはいいよ。そういう方針なんだとしてもだよ？それを説明するドキュメントがないんだよ！！！！！ コメントも書いてないんだよ！！！！もちろん、Gitなんて使ってないんだよ！！！！！

ねえ、AIさん、どう思うよ？？

この実装の問題の本質は、エンジニアリングの基本が抜け落ちていることです。 MVCモデルを無視したコードは、ビジネスロジック、 データ処理、プレゼンテーションの分離を完全に壊してしまいます。 結果として、保守性もテスト性も崩壊。これでは誰が引き継いでも苦労します。

おっしゃる通りでございます。今、まさにその苦労を味わされています。

コ・ノ・ウ・ラ・ミ・ハ・ラ・サ・デ・オ・ク・ベ・キ・カ

インラインとイベントリスナー

インラインJavaScriptとは、 HTML要素に直接JavaScriptを記述する方法（例：onclick="function()"）です。 一方、イベントリスナーは、JavaScriptファイル内でイベントを登録する方法 （例：element.addEventListener('click', function)）です。 イベントリスナーを使用することで：

  • JavaScriptとHTMLの分離が可能
  • 同一要素に複数のイベントを設定可能
  • イベントの動的な追加・削除が容易
  • コードの保守性が向上

という利点があります。 それなのに、動的に生成される要素にインラインJavaScriptを使用するという、まさに改善の真逆を行く実装だったのです。

良い子の皆さんは真似しないでね

HTMLやJavaScript、CSSはプログラミングです。 MVCモデルやSoCはエンジニアリングです。

どうです？エンジニアリングを一切考慮していないコードが、どれほど破壊的な威力を持つか、少しは理解していただけたでしょうか？

コードは「動けばいい」では済まされません。「動くこと」は最低条件であり、その上で「他の人が見てわかる」「修正できる」「長期間メンテナンスできる」ことが重要です。それを実現するのがエンジニアリングです。そして、それを無視した結果が、この反面教師のようなコードです。

独学でプログラミングを学んだ人が陥りやすいのは、エンジニアリングを軽視してしまうことです。プログラミングスクールではコーディング技術を教えるかもしれませんが、設計や保守性といったエンジニアリングの基本は疎かにされることが多いのです。その背景には、「とにかく動けばいい」「できるだけ安く済ませたい」といった現代的なニーズがあるのかもしれません。

しかし、人を苦しめるのに刃物は要りません。ぐちゃぐちゃなコードは、それ以上に人を追い詰めることができるのです。「動けばいいや」という安易な考えで書かれたコードは、知らないところで誰かの人生を台無しにしてしまうかもしれません。

だからこそ、肝に銘じてください。エンジニアリングの重要性を無視してはいけません。それは、あなたの書くコードが未来の誰かにとって悪夢にならないための最低限の配慮です。