今も尚使われているMVCフレームワーク当時のエンジニアは活発にこのフレームワークを作る事に専念していました。
MVCとは
M＝モデル＝データベース操作
V＝ヴュー＝出力先のテンプレート
C＝コントローラー＝〇〇.com/index.php?edit 見たいな奴ですね。
コントローラーから送られてきた引数により、モデルを動かし、ビューで出力するという流れです。
editという文字列が送られてきた場合、index.phpがeditを認識し、edit.phpに飛ばし、edit.tmpで出力するだけの話です。これがMVCモデルの原型であり、単純だったりもします。
ただこれを一つのパッケージとして使うとなるとそういう訳にはいきません。
基本のMVC分離は保ちつつ、その中でSessionをどう持つか？そしてクロスサイトスクリプティングやSQLインジェクションなどの最新対策が出た場合にいかに簡単に対応できるか？
このパッケージの中にどれだけ機能を持たせ、必要のない機能を使わないようにするかが重要となってきます。
20年も昔ですが、私の作ったMVCフレームワークの構成はこうなってました。
incフォルダはこのパッケージの中核なので基本はいじらずバージョンアップさせるフォルダ。
initフォルダは設定ファイルなのでその案件に合わせた柔軟な機能を利用する設定ファイル。
まあ利用しないものをコメントアウトするだけのファイル群。
classフォルダがDB操作を含めた、WEBで使う物が集められたモジュール群。（人が作った物を流用しない）
Vにあたるtmpl デザイナーがいじるだけで良い場所となる。テンプレート用の簡略化コードの埋め込みで済むように作ってはいた。
DB操作において簡単なSQLを自動生成できるようにしたコードがある。
そしてコードを後の人も解るようなコードを書いている。
テーブル名とハッシュにカラム名と値を入力することにより、Insert Updete select の3つのSQL文が自動生成される内容である。
そしてこちらのクラスへSQL文を投げ込めば実行することになる。
Mモデルの説明になってしまったが、
実際にコードを書く時も、だれでも解るようなコメント付けも必要だと思う。
中間コードに書くコメントは
/***************
*INSERT文生成
***************/
のような程度で良いと思う。
良く見るコメントは、そのコードを書いた言い訳をコメントで残す人がいる。
MVCフレームワークも理解が必要。MVC分離にする意味から、フレームワークをこの形にした理由。
フレームワークが既に用意してあるクラスモジュールを使わず、CpanやPearなどから引っ張ってきて入れてしまっては元も子もない。足りないモジュールであれば入れてもいいのだが。
PerlのCatalistなんてフレームワークは昔の話ではあるがCpanモジュール群（全部ではないと思う）をダウンロードしてくるという力業。①コメントはつける事により後から見る人が見やすくなる。不用コメントはいらない。
②大規模開発以外ではほぼ設計書などないので、コメントで設計書変わりにするのもあり。
勝手に設計書を書いてもいいと思う。
③ドキュメントは大事です。今回の場合はMVCフレームワークの話だったので、
私はこのフレームワークにきちんと使い方が解るようなドキュメントを残しています。