WEBシステム引き継ぎについてメモ

対応の悪さから発注元が見限ったり、交渉決裂して手を引いたりして、　他会社が受託開発したPHPのWEBシステムを引き継ぎ運用し、その後の改修対応などを行うことがあります。
手がけている案件の２割ぐらいはそんな感じでしょうか。
既存システムの仕様方針を壊さず対応する必要がある為、新規開発とはまた違った難しさがあると感じてます。
ここ最近そういった案件が続き、~~ストレスが溜まったので、~~問題を感じることが多かったので、下記に記します。

WEBシステムの傾向

そもそも、発注元と開発請負会社の関係がしっかりと構築されていてない動けばいいよで丸投げしたケースが多い。
その為か「セキュリティ関連の処理が甘い」「COBOLや10数年前のVBを彷彿とさせるプログラム」「PHP4で時間が止まっている」ものが散見される。

あとCakePHPも多いです。

対応要件例

1. 表示件数や表示条件を変えて欲しい
2. 項目を新規追加したい
3. カテゴリーを新規追加して、現状のCRUD機能と似たものを追加して欲しい
4. 表示速度が遅いのでなんとかして欲しい
5. 別のサーバーにシステムを移行したい
6. セキュリティチェックをお願いしたい

引き継ぎやすいWEBシステム

1. 一般的なルール。ファイルや関数などの適切な記名など。
2. 標準にならった適切な日本語コメント。独自ルールの場合、IDEの恩恵を受けられない。
3. 不要なファイル（大量のバックアップファイル）や不要な処理を含まない。
4. 仕様書はそもそもまともなものが残っているケースが少ない。また、システム規模が小さければ、仕様書保守がむしろコストとなる為、なくても構わない。
5. 非推奨機能は利用しない。サーバー移行時のPHPバージョンアップでネックになる。
6. テンプレートやライブラリがバラバラの場所に置かれていると探しにくい。
7. 呼び出し階層が浅いもの。ファイル分割が少ないもの。

MVCフレームワーク

前述したようにCakePHPが採用されているケースが多いのですが。
例えば、実行ファイル(Controller的)＋テンプレートファイル(View的）が同一フォルダにあるという至極単純な構成に比べると、一般的なMVCフレームワークは扱いにくいです。
理由は改修対象が複数フォルダにまたがることが多い為。
認識外のルールがあるという点で、オレオレMVCフレームワークは更に扱いにくい。

入力チェック

幾つかのMVCフレームワークは入力チェック(Validate)をでmodel側処理として持たせてます。
ただ、入力チェックは画面と密接に連動しており、ほぼ1対1の関係の為、複数処理から呼び出される可能性のあるmodelに持たせるのは懐疑的です。改修の複雑さを増大させる方向にしか働いてないと考えてます。

共通ライブラリについて

共通ライブラリを修正する場合、依存関係（呼び出し元）を一通り調べ直しての対応になります。
これは責務ベース分割に若干反しますが、実行ファイルと1対1のロジックは分割せずにそのまま含んでもらったほうが改修作業負荷は下がります。
テンプレート部分についても、似たような方針がとられることがありますが、同様の理由から分割しないほうが望ましいと思ってます。

DBアクセスについて

ORMライブラリ、或いはPDOのプリペアドステートメントを採用してくれるのがよいのですが、

SQL記述が一つのファイルにまとめられている

以下は単純な例ですが、実行ファイルや共通処理にSQLを含まず、一つのファイルにSQL記述がまとめられているケースがあります。

def_sql.php

const SQL_GET_USER_INFO = "SELECT id, name, age FROM users WHERE id = ?"
const SQL_GET_TEAM_INFO = "SELECT id, name, number FROM teams WHERE id = ?"

国際化対応や共通文字列といった必要性を除けば、文字列を同一ファイルで一括定義するというのは改修の作業負荷が増えるだけで、意味がないと考えてます。

呼び出し元でのSQLエスケープ

呼び出し元でのSQLエスケープが前提の処理もたまにあります。

$param = array(
  'name' => addslashes($name)
);
$db->query("SELECT * FROM user WHERE name = ?", $param);

SQLインジェクション対応の調査を行う場合、こういった処理は作業負荷増大の影響を与えます。
なお、PHPの場合、各DBに対してエスケープ処理が準備されているが、「エスケープ処理を知っている場合、より簡易なプリペアドステートメントも知っている」状況が殆どだと思うので、目にする機会はあまりないです。

"SELEC * FROM" について

データ取得SQLの記述で、、SELECT id, name FROMといったフィールド個別指定形式ではなく、SELECT * FROMの形式の場合、テンプレートファイルの修正だけで済むことが多く、改修作業負荷が下がります。
ただし、動作環境によっては、パフォーマンスに影響を与えることがある為、若干の注意が必要です。

DB固有SQLの利用

DB固有SQLの利用ですが、そもそもDBを別の種類に変えるだけ、という状況が殆どない為、利用してもらって構わないと考えます。
フルリニューアルぐらいの規模になると、別DBに変わることがありますが、その場合プログラムも大幅に変更する前提の予算となる為、「だけ」という状況にはなりません。

１つのWEBシステムに複数のフレームワークが同居

おそらく「引き継ぎの引き継ぎ」で発生していると思われますが、１つのWEBシステムに複数のフレームワークやライブラリが同居しているケースがあります。
ここの方針を意識しながらの改修の為、作業負荷は極めて大きいです。
コスト面から既存システムへの適用が困難な為、新方式のシステムを混在させることはあるとは思うのですが、そこは例外的な対応と割り切り、せめて１フォルダ内で完結する仕組みにして欲しいとは思います。

別のWEBシステムに統合させる

同居の理由として「サーバを１つにしたいので、システムの統合作業をお願いします」というケースもあります。
別ドメインを切るなどすれば、DocumentRootを別にして…、といった対応になるのですが、切れないケースがあります。
URLルーティングを細かく制御しているシステムの場合、問題になることがあります。
過去のケースでは、CakePHPを移行しようと思ったら、統合先でZendフレームワークがあった為、index.phpがぶつかってしまうといことがありました。
システムを改修構築する程の予算がない為、ドメインを分けることで対応したのですが、注意が必要です。

セキュリティチェックについて

セキュリティ関連で大きな事件が起きると、それを契機に、既存システムのセキュリティチェックが行われることがあります。主に以下２点が多いです。

1. SQLインジェクション
2. XSS対応

「XSS対応」についてですが、テンプレートエンジン側でデフォルトエスケープで対応しているのが望ましいです。対応されていない場合、全ての変数表示について確認を行う必要があります。