レガシーコードから学ぶ構造化プログラミング入門：エンジニアリング視点での実践 • AQZ Tech Chronicles

前回は、32行の翻訳処理コードを例に、構造化による段階的な改善プロセスを見てきました。

今回は、より身近な例として、HTMLフォームのPOSTデータを処理するコードを取り上げます。

このシンプルな例を通じて、エンジニアリング的思考の本質に迫ってみましょう。

プログラミング教育の現状と課題

現代のプログラミング教育には大きな課題があります。プログラミングを学ぶ過程で、エンジニアリングの視点が欠落しているのです。

かつては、プログラミングをマスターした人材が企業でエンジニアリングを経験することでスキルアップする道筋がありました。しかし、実装現場の海外移転により、国内でエンジニアリングを経験する機会が激減しています。さらに、教育機関の講師の多くが実務経験を持たないため、エンジニアリングの本質を教えることができません。

エンジニアリングを知らないプログラマーの特徴

この状況は、独特の特徴を持つプログラマーを量産する結果となっています。最も顕著な特徴は、コードの再利用性を考えないことです。同じようなコードを何度も書き直し、似たような機能なのに画面ごとに異なる実装を行います。「動けばいい」という発想が先行し、保守性への考慮が欠落しているのです。

また、システム全体を見通す力も不足しています。目の前の課題だけを解決しようとし、変更の影響範囲を把握できません。その結果、将来の拡張性を考慮しない実装が積み重なっていきます。

さらに深刻なのは、言語機能の本質的な理解が不足していることです。プログラミング言語の機能を表面的にしか理解せず、既存のコードをコピー＆ペーストで流用する傾向があります。なぜその実装方法を選んだのか、技術的な根拠を説明できないケースも少なくありません。

実務での影響

これらの問題は、実際のプロジェクトで深刻な影響を及ぼしています。開発効率の面では、同じような機能を何度も実装することによる時間の浪費、共通化できる処理の散在、コードの重複による保守コストの増大などが発生します。

品質面では、バグ修正が一箇所で完結しない、似て非なる実装が混在する、テストが複雑化して漏れが発生するなど、多岐にわたる問題が生じています。

チーム開発の観点では、コードレビューが困難になり、知識の共有が難しくなります。技術的な議論が成立しないケースも増えており、組織としての成長を妨げる要因となっています。

悪循環の発生

さらに深刻なのは、このような状況が悪循環を生み出していることです。「動くコード」を書く経験は積めても、「良いコード」を書く経験が得られません。改善の機会が失われ、エンジニアリングの視点が養われないまま、設計力や技術的な判断力の向上も停滞します。

組織としても、技術的な負債が蓄積され、ノウハウの継承が困難になっています。プロジェクトの持続可能性が低下し、長期的な競争力の維持が危ぶまれる状況です。

このような状況は、次に示すPOSTデータ処理の例のような、日常的なコーディングの場面で如実に表れています。一見単純な処理であっても、エンジニアリングの視点があるかないかで、実装の品質は大きく変わってくるのです。

より単純な例：POSTデータの処理

構造化の効果を示すより単純な例を見てみましょう。

以下は、あるフォームのPOSTデータを処理する実際のコードです。

if (isset($_POST['orslipnumber'])) {
    $orslipnumber = xHsc($_POST['orslipnumber']);
}
if (isset($_POST['orvenderid'])) {
    $orvenderid = xHsc($_POST['orvenderid']);
}
if (isset($_POST['ordate'])) {
    $ordate = xHsc($_POST['ordate']);
}
if (isset($_POST['ordeliveryplandate'])) {
    $ordeliveryplandate = xHsc($_POST['ordeliveryplandate']);
}
if (isset($_POST['ordeliverydonedate'])) {
    $ordeliverydonedate = xHsc($_POST['ordeliverydonedate']);
}
if (isset($_POST['ordeliveryplace'])) {
    $ordeliveryplace = xHsc($_POST['ordeliveryplace']);
}
if (isset($_POST['ormemo'])) {
    $ormemo = xHsc($_POST['ormemo']);
}
if (isset($_POST['orstatus'])) {
    $orstatus = xHsc($_POST['orstatus']);
}
if (isset($_POST['orpayamount'])) {
    $orpayamount = xHsc($_POST['orpayamount']);
}
if (isset($_POST['orpaydate'])) {
    $orpaydate = xHsc($_POST['orpaydate']);
}

このコードは、以下のたった2行で同じ機能を実現できます。

$vars = array_map('xHsc', $_POST);
extract($vars);

この改善は、必ずしも「構造化プログラミング」の教科書的な例ではありません。

しかし、これは実務における重要な原則を示しています。

同じパターンの認識
- 元のコードでは、同一パターンが10回以上繰り返されています
- このような繰り返しは、コードの保守性を著しく低下させます
言語機能の適切な活用
- array_mapによる配列操作
- extractによる変数展開
- これらはPHPの言語機能を理解した上での選択です
実用的な判断
- より厳密な方法（例：クラス化やインターフェース設計）も考えられます
- しかし、この場合は単純な解決策の方が適切です
- 必要以上の抽象化や構造化は、かえってコードを複雑にする可能性があります
既存の設計方針との整合性
- extractの使用については前回の記事で説明したように、システム全体の設計方針に基づいています

これは「良いコード」が必ずしも複雑である必要はないことを示す良い例です。

時には、言語機能の適切な活用こそが、最も効果的な解決策となることがあります。

このような改善は、一見単純なテクニックのように見えます。

しかし、これは「コードの本質を理解し、最適な解決策を選択する」というエンジニアリングの重要な側面を示しています。

必要以上に複雑な解決策を避け、シンプルかつ効果的な方法を選択する―これもまた、エンジニアリングの重要な技能なのです。

エンジニアリング教育の本質

この事例は、プログラミングとエンジニアリングの本質的な違いを浮き彫りにしています。

プログラミング教育は「どう書くか」を教えます。

ループ文の使い方、関数の定義方法、変数の宣言方法など、言語の文法や機能を学びます。

一方、エンジニアリングは「なぜそう書くのか」を考えさせます。

コードの冗長性、再利用性、将来の変更への対応、チーム開発での協力方法など、より本質的な視点を養います。

このような視点は、実際のコードを改善する経験を通じてこそ身につきます。

プログラミング教育だけでは、「動くコード」は書けても、「良いコード」は書けないのです。

結論：構造化がもたらす真の価値

構造化プログラミングの価値は、単なるコードの整理整頓にとどまりません。

それは、ソフトウェア開発における思考方法の体系化であり、チーム開発を可能にする共通言語でもあります。

本記事で示した例は、初期の冗長なコードから、段階的な改善を経て、最終的にクラスとして完全にカプセル化されるまでの過程を示しています。

各段階での改善は、それぞれ異なる構造化の原則を体現しています。

ループによる簡潔化：基本的な構造化の第一歩
関数化による共通化：モジュール化と再利用性の実現
クラス化によるカプセル化：データと処理の一体化、完全な抽象化の達成

この段階的な改善プロセスこそが、エンジニアリング的思考の本質を示しています。

単に「動くコード」を書くのではなく、継続的に改善を重ね、より良い構造を目指す。

それが真のエンジニアリングであり、現代のソフトウェア開発に不可欠な視点なのです。