前回のスピーカのコメントのなかで、(まっちゃさんから)「業務アプリは数パターンのロジックで全部かける！」というのが有りました。
OOP世界では、GOFのデザインパターン23種類が有名ですが、これは、デザインレベルで抽象化されていて、心を理解していないと、綻びがでます。
パターン化という姿勢は、昔からある考えで、工業化の手順とも言えます。クリエイティブ部分が残るか否かは別問題です。製品の品質とクリエイティブ仕事も別問題です。
汎用機アプリ(コボル等)の業務開発の現場では、抽象化パターンよりも、実ソースのテンプレートとなるパターンをベースにすることが多いようです。
同列には言えないのですが、(職場限定の)パターン文化と言う意味で確立しているので、パターンを習得していれば、職場内では仕事がこなせます。
対象となる、修正箇所は、項目名称や計算式、帳票レイアウト、コントロールブレークなどで、半固定されます。
作成工程は、定型化され流れ作業化され、テスト項目も粗方決まります。
テンプレート化すれば、その部分は既製品になるので、テストが軽減されます。テンプレートで変更した箇所のテストとなるので、テスト項目が限定されます。パターン外の要素が入ると、テスト項目が増えるので、ソースが短くなるメリット以上の、テスト項目等のコスト増になるとされます。
この思想は、オープン系開発にも取れ入れられて、開発フレームワークとして、テンプレートを提供する現場も増えているようです。
ソフトを工業製品とみなすならば、このような製造方式も有意義だと思います。
工業的には上記工程は是とされますがソースのスマートさや品質面では非する人もいます。両立は難しものです。
テンプレート化で気を付けなければ、ならないのは陳腐化です。技術進歩が早いので、定期的に、テンプレートの見直しが必要です。頻繁に見直すとテンプレートにならないという矛盾がありますね。
汎用機開発は、スタイル変化がユックリなので、テンプレートパターン文化が成り立つのでしょうね。
開発者の職人的満足度と工業製品生産過程とのギャップは、実在するので、どこで調整するかも、重要な課題です。