MS_DevSupportToolCodeGen

開発支援ツールの自動生成方式

• 戻る（開発支援ツール）
  • 開発支援ツールの種類
  • 開発支援ツールの自動生成方式

概要

本ページでは、種々の自動生成方式について纏める。

なお、ソフトウェア開発生産性の向上の取り組みは、

• コーディング・レベル
  • 自動生成
  • フレームワーク
  • テンプレート
  • .etc

以外にも広く行う必要がある。

この理由は、以下の技術要素も重要な生産性の変動要因であるためである。

• 提案（業務・技術面）
• フィージビリティ分析
• アーキテクチャ設計、処理方式設計
• 標準化
• 問題対応
• テスト
• 障害対応
• .etc

移行メモ（誤字）: 移行元の「ソフトウェア開発生産生の向上」を
「ソフトウェア開発生産性の向上」に修正した。

自動生成の用語定義

生成方式

リポジトリ型

各種リソースからリポジトリに情報を取り込むこともあり、仕組みは複雑になる。

• デザイナ操作型
  デザイナ操作で設計した画面項目やインターフェイスなどの情報を
  一旦リポジトリに取り込み、プログラムを生成する。

• スキーマ定義型
  画面項目や DB スキーマなどの情報を一旦リポジトリに取り込み、プログラムを生成する。

設計情報型

リポジトリが存在しないため、仕組みは単純になる。

• （Excel など）設計書型
  設計書から設計情報を取り込み、プログラムを生成する。

• デザイナ操作型
  デザイナ操作から設計情報を取り込み、プログラムを生成する。

• スキーマ定義型
  DDL、WSDL などの定義済みのスキーマの設計情報を取り込み、プログラムを生成する。

Visual Studio などはドメインに特化した
デザイナ操作型（画面） + スキーマ定義型（DDL、WSDL）の
自動生成処理が中心に実装されている。

補足（この 2 分類が本ページの背骨）: 「リポジトリを持つか否か」という
切り口は、ツールの複雑さと運用コストを決定づける。

【リポジトリ型】★
   各種リソース ──取込──→ 【リポジトリ】──生成──→ コード
                             （中間の真実の源）
   ・利点：横断的な整合性チェック、影響分析ができる
   ・欠点
       - リポジトリ自体の【マージ・ロールバックが困難】★
         （後述の「運用」の節）
       - リポジトリが【Git で差分管理できない】
         （バイナリ or DB のことが多い）
       - ツールが止まると資産が取り出せない

【設計情報型】
   設計情報 ──直接──→ コード
   ・利点：仕組みが単純。壊れにくい
   ・欠点：横断的な整合性は担保されない

【現在の潮流は「設計情報型」の勝ち】★
   ・OpenAPI（YAML）→ クライアント／サーバのコード生成
   ・.proto（gRPC）→ 各言語のスタブ生成
   ・DDL / EF Core のモデル → マイグレーション
   ・いずれも【入力がテキスト ファイル】であり、
     Git で差分管理・レビュー・CI 実行ができる ★
   → 「リポジトリ」を DB ではなく
     【リポジトリ（Git）】に置いた、とも言える

生成範囲

全層自動生成

P 層、F（B）層、D 層の全自動生成だが、
UI 要素のレイアウトや、F（B）層のビジネスロジックは
プログラマによって実装する必要がある。

ドメイン特化型全自動生成

特定のレイヤ（ドメイン）に特化した 100％自動生成。

• デザイナ操作による画面初期化コードの自動生成
• スキーマ定義（DDL、WSDL）後の Dao や proxy 等のコードの自動生成

100％全自動生成

P 層、F（B）層、D 層の 100％全自動生成で、
且つ、UI 要素のレイアウトや、F（B）層のビジネスロジックも
リポジトリから設計情報を取り込んで全自動生成する。

ツール毎の自動生成方式

Visual Studio

概要

Visual Studio を参照。

特徴

Visual Studio の自動生成は、基本的に
Visual Studio デザイナ操作やスキーマ定義からの自動生成に特化している。
また、自動生成されるものの仕様も決まっており、カスタマイズ不要である。
このためテンプレート・エンジン等の仕組みは使用していないものと考える。

• 自動生成方式

  • ドメイン特化型全自動生成
    • デザイナ操作型
    • スキーマ定義型
    • デザイナ操作＋スキーマ定義型
      Visual Studio デザイナを使用して WPF 画面を作成するような場合。
      デザイナ操作（VS デザイナ）→スキーマ（XAML）→画面初期化処理自動生成

• 設計思想

  • 設計書情報が無いので、開発工程から活用
  • 各ドメインに特化した、開発視点の軽量型

• ポイント

  • ラウンド・トリップ非対応。
  • ドメインに特化しているためカスタマイズは発生しない
  • 従って、テンプレート・エンジンは使用しない。
  • .NET 等、前提となるフレームワークを使用し生成量を抑えている。

補足（「テンプレート エンジンを使っていない」は現在は違う）: この推測は
当時として妥当だったが、Visual Studio / .NET には複数の生成機構がある。

【① T4（Text Template Transformation Toolkit）】★
   ・VS 2008 から搭載されている
     【テンプレート エンジンそのもの】
   ・.tt ファイルに C# を埋め込んで任意のテキストを生成
       <#@ template language="C#" #>
       <# foreach (var t in tables) { #>
       public class <#= t.Name #> { }
       <# } #>
   ・EF の旧 Database First / Model First は
     【T4 で生成していた】★
   → 原文の「使用していない」は
     デザイナ系については正しいが、
     データ アクセス系では【使っていた】

【② スキャフォールディング】
   ・dotnet ef dbcontext scaffold
   ・dotnet aspnet-codegenerator
   → 【一度きり生成して、以後は手で保守する】方式

【③ ソース ジェネレータ】（.NET 5〜）★★
   ・【コンパイル時に】コードを生成する
   ・生成物は【ファイルとして残らない】
     → リポジトリを汚さない
     → 【ラウンド トリップ問題が原理的に起きない】★
   ・実例
       - System.Text.Json のシリアライザ
       - LibraryImport（P/Invoke）
       - Regex（コンパイル時に正規表現を展開）
       - CommunityToolkit.Mvvm の [ObservableProperty]

【④ Roslyn ベースのリファクタリング】
   ・「生成」と「編集」の中間
   ・IDE が構文木を理解して安全に書き換える

【本ページの分類に当てはめると】★
   ソース ジェネレータは
     ・入力：【既存のコード】（属性・部分クラス）
     ・出力：コンパイル時のみ存在するコード
   → 従来の 3 分類（設計書／デザイナ／スキーマ）の
     どれにも当てはまらない【第 4 の方式】である
   → 「生成物を保守しない」という
     最大の難題への回答になっている ★

UIデザイン系

• Windows Forms、ASP.NET WebForm

  • UI コントロールをデザイナを使用して配置していくと
    コードビハインドや、ASPX の ASP タグに UI 生成のコードが自動生成される。

  • コントロールによっては拡張のカスタム デザイナが用意されており、
    それを使用して、UI のデザインと対応する UI 生成のコードを自動生成する。

• WPF、Silverlight

  • UI コントロールをデザイナを使用して配置していくと XAML コードが自動生成され、
    ビルド時に XAML から BAML というバイナリ化された XAML が生成される。

  • WPF、Silverlight 実行時は BAML を使用して UI の初期化が行われる。

  • カスタム コントロールは使用せず
    ItemTemplate、DataTemplate などを駆使して
    カスタマイズ可能なアーキテクチャに変更されている。

補足（カスタム デザイナと BAML の詳細）: 本節の 2 点は
本 Wiki 内に詳しい解説があるので案内しておく。

【カスタム デザイナ】★
   ・ControlDesigner を継承して
     デザイン時の表示を自前で作る仕組み
   → 詳細は
     [.NETコントロールのカスタマイズ方法](MS_DotNetControlCustomization)
     [コンストラクタで子コントロール追加すると二重追加される件](MS_DoubleAddedControls)

【BAML（Binary Application Markup Language）】
   ・XAML をトークン化した中間形式
   ・アセンブリに【リソースとして埋め込まれる】
   ・利点
       - パース（XML 解析）が不要で【起動が速い】★
       - サイズが小さい
   ・注意
       - 【仕様は非公開】
       - 逆コンパイラ（ILSpy 等）で
         XAML に復元されうる
   → 詳細は [WPFのアーキテクチャ](MS_WPFArchitecture)

【「カスタム コントロールは使用せず Template で」】★
   ・WPF の設計思想（ルックレス コントロール）を
     正しく捉えた記述である
   → 詳細は
     [XAMLの書き方（１）](MS_XAMLWriting1) の
     スタイル・テンプレートの節

データ・アクセス系

• DataAdapter：データ・アダプタ構成ウィザード

• TableAdapter：テーブル・アダプタ構成ウィザード

• Entity Framework

Dynamics（MS_Dynamics.md）

CRM

デザイナ操作型の 100％全自動生成

• 画面定義から DB が自動生成される。
• 業務処理は JavaScript でイベント定義

AX

BRMS系

概要

• 業務プロセスはフロー、ルール、データから出来ている。

• 実世界の業務の中で、改修、改善が必要であったり、
  ビジネスの状況に併せて変更する必要があるのは
  フローよりもむしろ、ビジネス・ルールの方が圧倒的に多い。

• 構成要素

  • Engine（ルール・エンジン）
  • Manager（ルールの編集）
  • ルール・リポジトリ（ルール定義の管理）

• Engine（ルール・エンジン）

  • ビジネス・ルールの実行をするフレームワーク、またはライブラリ
  • アプリケーションとビジネス・ルールの分離を実現
  • ダイナミックにルールを変更可能（アプリケーションの柔軟性を高める）。
  • 多くのルール・エンジンは Rete アルゴリズムをベースとする。
  • 定義したルールをプログラムから呼び出すと、入力から出力に変換される。

移行メモ（括弧の欠落）: 移行元の「アプリケーションの柔軟性を高める。」は
開き括弧に対する閉じ括弧が欠落していたため補った。

• Business Rule Management（BRM）
  Manager（ルールの編集）＆ルール・リポジトリ（ルール定義の管理）

  • ビジネス・ルール・ライフサイクルをあらゆる側面からサポート
  • ビジネス・ルールの可視化
  • ビジネス・ルールのテスト
  • ビジネス・ルールの編集・デプロイ

• ルールの記法は以下の 3 つ

  • DRL：デベロッパ向け、ネイティブ記法、テキスト形式
    基本的に直接使用せず、以下 DSL、Decision Table から自動生成される。
  • DSL：ビジネス・エキスパート向け、自然言語、テキスト形式
  • Decision Table：デベロッパ、ビジネス・エキスパート向け、スプレッド・シート形式

補足（Rete アルゴリズムとは）: 説明なく出てくるため補っておく。

【Rete アルゴリズム】★
   ・Charles Forgy が 1974年に考案した
     【前向き推論（forward chaining）の高速化手法】
   ・ルールの条件部を【ネットワーク状に共有】し、
     前回の評価結果をノードに保持する
     → ファクト（データ）が 1 件変わったとき、
       【影響するルールだけを再評価する】
     → 全ルール × 全ファクトの総当たりを避ける

【向く問題 / 向かない問題】
   向く   … ルールが【数百〜数千】あり、
            ファクトが少しずつ変化していく
   向かない … ルールが数十しかない
            → 【素直に if を書いた方が速く、読みやすい】★
            → メモリを大量に消費する点にも注意

【現況】
   ・Drools（現 Drools / KIE）が代表的実装
   ・記法は【DMN】（OMG 標準）へ寄りつつある
     → デシジョン テーブルが標準化され、
       ツール間の移植性が上がった ★

特徴

• ユーザ・フレンドリ

  • 可視性　　：仕様定義 ≒ ルール定義、実装への橋渡しが容易
  • テストレス：仕様系バグのみ対象、パンチ系バグはテストレス
  • 編集・デプロイが容易（≒ EUC 容易）

• ルールが頻繁に変わって可視化＆修正し易い製品メリットが
  通常のプログラムを上回る極狭い範囲で有用と考える。

自動生成方式毎の特徴

生成方式

自動生成ツールが何に重きを置いているかは、自動生成方式で大方、判断できる。

入力がExcel設計書の場合

モジュール設計情報が入力となるため、モジュール設計工程からの生成用途となる。

• メリット

  • Excel 設計書を選択する理由は
    設計と実装の乖離を防ぐ設計書からの生成のため。

  • 設計工程からの設計書からの生成は、
    ウォータ・フォール的な開発プロセスには適合する。
    設計情報を修正しながらのラウンドトリップ開発は困難。

• デメリット
  しかし、100％全自動生成でなければ、

  • プロトタイピング、スパイラル、アジャイルなどの開発プロセスに適合しない。
    （これは、後述するようにラウンド・トリップ開発が困難であるためである）

  • モジュール設計レベルの工程が必須になり、場合によっては、
    キーパンチ相当の工程・スキルも２重に必要になる。

補足（Excel 設計書型が抱える構造的な問題）: 「キーパンチ相当の工程が
二重に必要」という指摘に加えて、運用上の問題がある。

【Excel をマスタにすることの代償】★
 ① 【差分が見えない】
     → Git に入れてもバイナリ扱い
     → 誰が何を変えたか追えない
     → レビューができない ★
 ② 【マージできない】
     → 並行作業が事実上できない
     → ロック運用に戻る
       （→ [構成管理ツール](MS_ConfigurationManagementTools)）
 ③ 【壊れる】
     → セル結合、書式、マクロ、バージョン差
     → 生成ツールがパースに失敗する
 ④ 【二重管理になる】
     → 実装を直したら設計書も直す、が守られない
     → 皮肉にも【設計と実装の乖離を防ぐ】という
       本来の目的が達成されない ★

【現在の代替】
   ・仕様を【テキスト（YAML / Markdown）】で書く
     → OpenAPI、JSON Schema、Gherkin（受入条件）
     → 差分・レビュー・CI 検証がすべて可能になる ★
   ・表形式が要るなら【CSV / TSV】
   ・どうしても Excel が要るなら
     「入力 UI」として使い、
     【マスタはテキストに落とす】

入力がデザイナ操作の場合

開発時の設計情報が入力となるため、開発工程からの生成用途となる。

• メリット

  • 入力にデザイナ操作を選択する理由は、
    設計と実装の乖離の防止ではなく、開発スピード向上（RAD 開発）のため。
  • プログラマが開発ツールのスキルセットを満たすだけで良い。
  • 工程を跨がないので、ウォータ・フォールだけでなく、
    プロトタイピング、スパイラル、アジャイルなどの開発プロセスにも適合する。

• デメリット

  • 設計と実装の乖離を防ぐ仕組みは用意されていない。

入力がスキーマ定義の場合

開発時の設計情報が入力となるため、開発工程からの生成用途となる。

• スキーマ定義型の生成

  • XSD スキーマやコードの自動生成の入力とし、
  • （設計と実装の乖離を防止しつつ、）
  • 開発スピード向上（RAD 開発）を向上させる。

• メリット

  • 入力にスキーマを選択する理由は、
    設計と実装の乖離と、開発スピード向上（RAD 開発）のため。
  • スキーマ定義型の生成方式は仕組みも、最も簡単になる。
  • プログラマが開発ツールのスキルセットを満たすだけで良い。
  • 工程を跨がないので、ウォータ・フォールだけでなく、
    プロトタイピング、スパイラル、アジャイルなどの開発プロセスにも適合する。

• デメリット

  • 設計書と実装の乖離を防ぐ仕組みは用意されていない。

補足（スキーマ定義型が現在の主流である理由）: 「仕組みが最も簡単」
という評価が、そのまま普及の理由になった。

【現在の代表例】★
   ・【OpenAPI】（旧 Swagger）
       openapi.yaml → クライアント／サーバ／
                      ドキュメント／モックを生成
   ・【gRPC / Protocol Buffers】
       .proto → 多言語のスタブ
   ・【GraphQL】
       schema.graphql → 型定義
   ・【EF Core】
       モデル ⇄ マイグレーション ⇄ DDL
   ・【JSON Schema】
       設定ファイルの検証と補完

【なぜ強いのか】★
 ① 入力が【テキスト】＝ Git で管理できる
 ② 【契約（contract）そのもの】が入力になる
     → 「設計と実装の乖離」が
       原理的に起きにくい ★
       （原文が「デメリット」に挙げた点は、
         スキーマを唯一の真実の源とすれば解消する）
 ③ 生成物を【捨てて作り直せる】
     → ラウンド トリップの必要がない
 ④ 言語・チームを跨げる
     → フロント／バック／モバイルが
       同じスキーマから生成する

【実務上の鉄則】★
   ・生成されたコードは【編集しない】
   ・生成物を【リポジトリに含めるか】を決めておく
       含める   … 差分が見える。CI が軽い
       含めない … リポジトリが綺麗。CI で毎回生成
   ・拡張は【partial class / 継承 / 別ファイル】で行う

リポジトリを経由するもの

最も大掛かりな仕組みではあるが、
リポジトリと専用設計ツールを組み合わせ、
100％全自動生成をサポートするツールが多い。

詳しくは後述のリポジトリ型を参照。

生成範囲

自動生成方式によって生成範囲が異なる。

全層自動生成

柔軟性はあるが、導入のために多くのサポートが必要。
社内の治工具ツールではこの自動生成方式が多い。

• 特徴

  • 受託開発で、いろいろな要件に対応する必要があるために
    プログラミングでの対応範囲を広げており、柔軟性を出している。
  • PJ 毎、テンプレートのカスタマイズが可能な仕様となっていることが多い。
  • この柔軟性を発揮するには、重厚なサポートが必要になるが、
    重厚なサポートが可能となる社内の治工具ツールではこの自動生成方式が多い。

• メリット
  柔軟性がある。

  • テンプレート・カスタマイズが困難か、仕組みが用意されている。
  • 自動生成コードのカスタマイズが困難か、仕組みが用意されている。

• デメリット

  • ラウンド・トリップ開発への対応が必要。
  • 採用したツール・プログラミングの両方のスキルセットが必要。
  • このため EUC、設計・開発の分業の両方に適合しなくなっている。

ドメイン特化型全自動生成

ドメインに特化した範囲で 100％自動生成なので、この範囲でプログラミングは不要となる。
サポートが容易になるので製品系ではこの自動生成方式が多い。

• 特徴
  以下の自動生成方式に多い。

  • 社内の治工具ツール

    • EXCEL 設計書型

  • 製品

    • デザイナ操作型
    • スキーマ定義型

• メリット

  • 設計・開発の分業に向いている。
  • ラウンド・トリップ開発が不要

• デメリット

  • EUC に向いていない。

  • プログラミングと採用したツールに特化したスキルセットが必要。

  • 柔軟性が低い

    • テンプレート・カスタマイズが困難か、仕組みが用意されていない。
    • 自動生成コードのカスタマイズが困難か、仕組みが用意されていない。

100％全自動生成

100％全自動生成なので、プログラミングは一切不要となる。
柔軟性に難があるが、サポートが容易になるので製品系ではこの自動生成方式が多い。

• メリット

  • EUC に向いている（と謳われることが多い）。
  • プログラミングのスキルセットが不要。
  • ラウンド・トリップ開発が不要

• デメリット

  • 設計・開発の分業に向いていない。

  • 採用したツールに特化したスキルセットが必要。

  • 定義がプログラミングと同等の作業が必要であり実際はあまり改善しない。

  • 柔軟性が低い

    • テンプレート・カスタマイズが困難か、仕組みが用意されていない。
    • 自動生成コードのカスタマイズが困難か、仕組みが用意されていない。

補足（「定義がプログラミングと同等の作業」という指摘）: これは
ノーコード・ローコードにもそのまま当てはまる普遍的な洞察である。

【本質】★
   ・業務ロジックの【複雑さの総量は減らない】
   ・減らせるのは
       - 構文の暗記
       - 定型コードの記述
       - 環境構築
   ・減らせないのは
       - 【業務の分岐・例外・整合性を考える作業】★
   → 「プログラミング不要」は
     「考えなくてよい」ではない

【何が起きるか】
   ・GUI で複雑な条件分岐を組む
     → コードより【読みにくく、diff も取れない】★
     → 「見えるようにしたはずが、見えなくなる」
   ・結局、詳しい人が 1 人だけ理解している状態になる

【判断の目安】★
   ・ロジックが【単純で定型】     → ノーコードが効く
   ・ロジックが【複雑・例外が多い】 → コードの方が安い
   ・「業務部門が自分で直す」が
     本当に運用されるかを確認する
     （→ [RPA (Robotic Process Automation)](MS_RPA) の
       「野良ロボット」の議論と同じ構図）

リポジトリ型

生成範囲

• 以下のどちらのケースもある。

  • 100％全自動生成のツール
  • 100％全自動生成ではないツール

• ツールによっては設計情報の生成も可能になっている。

設計ツール

リポジトリ型自動生成ツールの周辺設計ツール（DB や、Interface）の操作は

• 基本設計・詳細設計の設計工程の作業ではなく、
• モジュール設計工程以降の開発工程に近い作業であり、
• ツールの専門性も（ある程度）ある。

という事を考えると、

• 100％全自動生成ではないツールは
  開発スキルを２重に要する（デメリットがある）との見方もできる。

• 一方で、100％全自動生成のツールは、
  EUC 用途での利用が想定されており、受託開発の工程の組み方と大きく異なる。

  • これらのツールでは、EUC で得られるメリットを最大化している。
  • トレンド的には、ピュアデベロップメントが衰退し
    EUC ツールが隆盛していくと考えられる。

運用

リポジトリ型自動生成ツールでは、
リポジトリの運用（変更操作への対応）が困難と言われている。

• マージ
• ロールバック
• .etc

ツールの機能拡充で対応できる可能性もあるが、ツールは複雑になっていく。

補足（この節が最も重要）: リポジトリ型の致命傷を的確に突いている。

【なぜマージできないのか】★
   ・リポジトリの実体が
     【独自形式のバイナリ or RDB】であることが多い
   ・テキストの行単位の差分が取れない
     → 3-way マージが原理的にできない
   ・ツールが独自のマージ機能を持つ場合でも
     - 意味の衝突（同じ項目を別の意味で使った）は
       機械的には解決できない
     - 【マージ結果の妥当性を検証できない】★

【現場で何が起きるか】
   ・「リポジトリは 1 人しか触らない」運用になる
     → その人がボトルネックになる ★
   ・ブランチが切れないので
     【並行開発ができない】
   ・バックアップからの復元 ＝ 全員の作業が消える

【「ツールは複雑になっていく」という予測】★
   → 【当たった】。
     機能を足すほど学習コストが上がり、
     前ページの「エンジニアが習得しない」構造に嵌まる
     （→ [開発支援ツール](MS_DevelopmentSupportTools)）

【現在の回答】
   ・真実の源を【テキスト ファイル】にする
     → Git がマージ・ロールバック・レビューを
       すべて引き受ける ★
   ・リポジトリが要るなら
     【Git そのものをリポジトリとして使う】
     （設計情報を YAML でコミットする）

テンプレート・エンジン

ポイント

• テンプレート・エンジンの機構は JSP や ASP で
  （Java、VBScript 言語で動的に）HTML を生成する機構に近い。

• テンプレート・エンジン・言語の習得が難しい事がネックとなり、
  EUC 的なテンプレート・カスタマイズは困難。

エンジン比較

• 独自テンプレート・エンジン

  • 言語が独自テンプレート言語となっており習得が困難。
  • デバッガの機能がないという問題があり、VBS 化されるなどの事例がある。
  • 平たく言って → 難しい。

• Apache Velocity テンプレート・エンジン

  • 入力形式は Java（VelocityContext 経由）。
  • テンプレート側は Velocity VTL 言語を併用する。
  • Console 出力などを使用したデバッグは不可能。

• Eclipse JET テンプレート・エンジン

  • 入力形式は XML 形式となっている。
  • テンプレート側は Java 言語で習得が容易
  • Console 出力などを使用したデバッグが可能。

サマリ

• メリット
  専任者が自動生成の仕組みを沢山 [ 作る / カスタマイズする ] 場合は
  有用であると考える。

• デメリット

  • テンプレート・エンジン・言語の習得が難しい事がネックとなり、
    EUC 的なカスタマイズは困難
  • このため、製品系ツールでは、
    柔軟なテンプレート・カスタマイズができるものは存在しない。
  • 採り得るアーキテクチャの多い .NET テクノロジでは、
    テンプレート・カスタマイズ方式では導入が困難である。

補足（「テンプレート言語が難しい」への現在の回答）: 「習得コストが
ネック」という診断は正しく、その後の設計はこれを回避する方向に進んだ。

【回避の方向①：ホスト言語をそのまま使う】★
   ・T4          → C# をそのまま埋め込む
   ・Razor       → C# をそのまま埋め込む
   ・JSX / TSX   → JavaScript の式
   → 【新しい言語を覚えなくてよい】
   → デバッガも IntelliSense もそのまま効く
     （原文が Eclipse JET を評価した理由と同じ）★

【回避の方向②：テンプレートを見せない】★★
   ・【ソース ジェネレータ】
     → 生成ロジックは C# のコード
     → テンプレート言語という概念がない
   ・【スキャフォールディング】
     → 生成は 1 回きり。以後は普通のコード

【回避の方向③：自然言語で指示する】★
   ・AI コード生成
     → テンプレートを書く代わりに
       【規約を文章で書く】（AGENTS.md 等）
     → 「習得コスト」が事実上ゼロに近づいた
     → ただし【出力の非決定性】という
       新しい問題と引き換え
       （→ [GitHub Copilot](MS_GitHubCopilot)）

ラウンド・トリップ開発

Eclipse JET テンプレート・エンジンでは
行単位の追加・変更はラウンド・トリップ可能となっているが

• クラス・メソッドのシグネチャや、
• クラス・メソッド、XML などのエンティティの属性の

修正などの行内部の細かい修正については、ラウンド・トリップできない。

補足（ラウンド トリップ問題の「正解」）: 本ページ全体を通じて
繰り返し現れるこの難題には、現在では定石がある。

【問題の構造】★
   生成コード ──手で修正──→ 生成コード(改)
      ↑                          │
      └──再生成すると【上書きで消える】

【解 ① 生成物と手書きを物理的に分ける】★★
   ・【partial class】
       Foo.g.cs   … 生成（毎回上書き）
       Foo.cs     … 手書き（触られない）
     → Visual Studio のデザイナが
       昔からこの方式を採っている
       （.designer.cs）
   ・【partial method】/ 仮想メソッド
     → 生成側が拡張点を用意する

【解 ② 生成物を継承する】
   ・生成クラスを基底にして派生クラスに手を入れる

【解 ③ 生成物を保守しない】★
   ・ソース ジェネレータ
     → そもそもファイルとして存在しない
     → 【ラウンド トリップが発生し得ない】

【解 ④ 生成物を「使い捨て」にする】
   ・スキャフォールディング
     → 最初の 1 回だけ生成し、以後は手で保守する
     → 「再生成しない」と割り切る

【アンチパターン】★
   ・生成コードに
     「// ここから下は編集しないでください」と書くだけ
     → 必ず編集される
     → 【仕組みで守る】（別ファイルにする）

---

Tags: 移行, .NET開発, ツール類, その他、開発の色々