メタプログラミングでExcel仕様書よさらば
16 likes•16,104 views
メタプログラミングでExcel仕様書よさらば！ 第一回Center CLR 勉強会 http://www.kekyo.net/2014/11/02/%e3%83%a1%e3%82%bf%e3%83%97%e3%83%ad%e3%82%b0%e3%83%a9%e3%83%9f%e3%83%b3%e3%82%b0%e3%81%a7excel%e4%bb%95%e6%a7%98%e6%9b%b8%e3%82%88%e3%80%81%e3%81%95%e3%82%89%e3%81%b0%ef%bc%81-%e7%ac%ac%e4%b8%80/
![ラムダ式で式木
Lambda
title2 =
Body:
Member
Parameters:
[0]
Expression:
null
Member:
FieldInfo
Expression.Field
スタティック フィールドなので null
FieldInfo
Expression.Lambda
C#コンパイラはこのように展開する](https://image.slidesharecdn.com/excel10-141110091525-conversion-gate01/85/Excel-18-320.jpg)
![LINQで使えるようにしよう
IEnumerable<string[]>にすれば、とりあえずLINQで繋げられるので：
yield returnを使って、LINQソース化する
LINQは本当に強力だ(6)TextFieldContexthttp://www.kekyo.net/2012/11/17/linq%e3%81%af%e6%9c%ac%e5%bd%93%e3%81%ab%e5%bc%b7%e5%8a%9b%e3%81%a0-6%e3%80%80textfieldcontext/](https://image.slidesharecdn.com/excel10-141110091525-conversion-gate01/85/Excel-39-320.jpg)
![カスタムコード生成方式
モデルクラスのソースを自動生成しているのだから、カスタムコードを生成して埋め込めば？
コンストラクタの引数にフィールドの文字列配列を指定可能なコードを生成する。
比較的簡単で理解は容易。
モデルクラスのコードを手動で実装する場合は負担増。
モデルクラス
（コンストラクタ）
フィールド
文字列[2]
フィールド
文字列[1]
フィールド
文字列[0]
文字列変換
ソース
ジェネレーター](https://image.slidesharecdn.com/excel10-141110091525-conversion-gate01/85/Excel-55-320.jpg)
メタプログラミングでExcel仕様書よさらば
- 1. メタプログラミング で EXCEL仕様書よ、 さらば！ 第一回Center CLR 勉強会Kouji Matsui @kekyo2
- 2. 自己紹介 Center CLR 第一回参加ありがとうございます！！私が張本人のいいだしっぺです！ とうとうやっちまった… 頑張ります！ 自転車乗りです。 会社やってます。 Windows Phoneとか好きです。SIMフリーであぽーみたいにMSが直販してくれないかなぁ。 クラウディアたん
- 3. アジェンダ ダークサイドEXCEL仕様書 メッセージテーブルあるある CSVファイルのあれこれ まとめ 長いです。お菓子でも食べながらゆるゆるとどうぞ！
- 5. EXCEL仕様書（設計書）とは？ EXCELに書かれた仕様書（日本のガラパゴス文化） フォーマットは「EXCEL方眼紙」という、レベル1の魔法 文書レイアウトがやりやすい（？） 文書・イメージ・図の配置が思い通り（？） 仕様の説明文書 ソフトウェアアーキテクチャの図示 データ種別の解説（表形式） マトリックス図（テストパターンなど）
- 6. EXCEL仕様書の全てを否定するわけじゃない 無駄をなくしたい（という所は共通認識だよね？ね？！） 一番うんざりするのは、データ構造の定義とか、マトリックス表とか だって、この後、これを見ながらコード書くんでしょ？機械的な作業なんて無駄だよね。 それに対して、アーキテクチャの説明とか、人間にしか読めないし書けない部分は、勿論仕様書として 書き起こすべき。 ところで、それって、EXCEL方眼紙で書く必要性あるの？W ややこしい組み合わせの検証の為に、表にして可視化するのはOK。ただ、そもそもその構造本当に大丈夫？ でも、やっぱり定義系の記述は、表形式になっていたほうが、保守しやすいよね。 って言うけど、保守って何さ？ EXCEL直してコード直して だんだん！！
- 7. 逆方向に出来ないか 発想を逆転させるんだ。 こういう発想は、そもそも「ソースコードの情報を、再解析するのが難しい」から、ドキュメント→ ソースコードの順で考えるのが自然って事になってるだけでは？ それがウォーターフォール的な手法に組み込まれて、効率が良いように見えてしまっているのが問題。 コードを書いた後で、定型的にデータ構造表やらマトリックス表が抽出できれば？ しかもそれを自動で。 「そんなの事実上無理じゃん。C#のコードを解析しないと出来ないわけで、コンパイラのパーサー書けって レベルじゃん」 さて、その為にこの勉強会があるわけですよ。 ご注意：ウォーターフォールはクソと思っているので、バイアス かかってます。補正する気は無いです。
- 9. メッセージテーブルって！ EXCELで管理します。 EXCELシート上に、UIに表示するメッセージを書きます。 対応するキー（管理番号）を、連番で含めます。 このEXCELファイルを、チーム内で共有し、メッセージの追加や変更が必要なら編集します。 実行時に読み取り、UIの表示に使用します。コード上では、管理番号から参照します。
- 10. 勃発 このEXCELファイルを、チーム内で共有し、メッセージの追加や変 更が必要なら編集します。 → ソースコード管理と相性が悪い！ → マージしたいんじゃ！ → 編集面倒なんですけど！！ 対応するキーを、連番で含めます。 → 誰だよ、番号勝手に変えたやし！！ → ねぇ、この定義いらないんだけど、連番付け直すの？ → 同じ番号の定義がいくつもあるぞ！！ → いつの間にか仕様書の番号が1個づつずれてるorz 改善策： 専任の管理者を決めて、その管理者が修正 を正しく行うようにしよう。 混乱するから、変更依頼伝票を作ろう。
- 11. をいをい… たかが「メッセージの管理」に、 専任者なんか必要なのか？ 手動派サン、こんな事、学生のバイト君でも出来るけど、 あなたの給料いくらなのカシラ？ それとも、あなたの存在価値はバイト君と同じというワケね？
- 12. ソースコードから表を起こす ソースコードに記述した情報を収集して、EXCELの表に出来たとしたら？ → 成果物から生成されるから、転記によるミスがない。 → マージの問題は、ソース管理システムで担保出来る（だって、ソースコードなのだから）。 キーはどうする？ → 連番も諸悪の根源なので、連番付けしなくても良い方法を考える。 ソースコードにハードコーディングしたら、運用時に変更出来ないじゃないか → 本当にそうかね？ アラアラ、それは一体イツの時代の知識なのカシラ、ネ
- 13. メタデータを使おう メッセージは文字列なので、string型で定義 する。これをstaticなフィールドに定義させ る。 キーに相当するものとして、名前空間名＋ クラス名＋フィールド名の組み合わせにす る。 これなら絶対に重複しない（同名のメンバー が異なるアセンブリで存在した場合はNGだ が、あまり起きないことに注力してもムダな ので考慮しない） これを実行時に取得しよう。 取得用のメソッドを準備。 ええと、まだ何もしてない
- 14. まずはフィールド情報を入手する フィールドやフィールドが定義されているクラスの情報を取得するには、リフレクションの「FieldInfo」 にアクセスする必要がある。 どうやって、コードの記述者に違和感を感じさせにくくしつつ、FieldInfoを取得出来るか？ クラスのTypeとフィールド名を指定させてみる FieldInfoを取得して、 キーを合成したり、文字列を取り出したり
- 15. 問題点 お膳立ては揃ったが、フィールドの指定方法が脆弱。 → フィールドを特定するのに、Typeクラスとフィールド名「文字列」が必要。 → しかも、フィールド名が文字列指定なので、インテリセンス・静的解析ツール・リファクタリングツールと相性が悪い。 → フィールドの型が文字列型かどうかは、実行時にしか分からない。 もうちょっとマシな方法は無いか… 引数に指定した式の由来（メタデータ）を取得する方法…
- 16. 式木（Expression Tree）を使う 式木、知ってるよね？ ラムダ式 ラムダ式 デリゲート 式木 デリゲートへの代入と同じように書かせることが出来て、 書いた式の「構造」を表す情報が格納される。
- 18. ラムダ式で式木 Lambda title2 = Body: Member Parameters: [0] Expression: null Member: FieldInfo Expression.Field スタティック フィールドなので null FieldInfo Expression.Lambda C#コンパイラはこのように展開する
- 19. 式木（Expression Tree）を使う フィールドの指定にラムダ式を書 かせる。 最低限の記述負担で行ける。 ラムダ式は式木に変換されていて、 FieldInfoを取り出せる。 フィールドだけを指定可能なよう に、強く制約する事は出来ない。 妥協点としては良いところか。 ラムダ式でフィールドを指定 文字列で指定しないので、タイプセーフ ラムダ式を書かせて式木で受ける 式木からFieldInfoを取り出す
- 20. 基本的なインフラ出来たじゃん 残る作戦：ハードコーディングされた文字列を、実行時に置き換え可能にする。 → キーが特定できているので、キーと置き換え文字列の辞書を作る。 → EXCELファイルから読み込む（これで従来通り運用管理側に作業を移譲できる） 辞書にないメッセージは、 ハードコーディングのまま 置き換わる キーは 「名前空間」＋「クラス」 ＋「フィールド」
- 21. EXCELファイルの読み取り xlsxファイルを読み取って、 辞書を生成する EXCELファイルの読み取りには、ClosedXMLを使います（NuGetで検索）。 全てのワークシート上の行を集約して 辞書化する。 何なら、複数のファイルから読み取っ て全部合成しても良いよね。
- 24. 残る課題 ソースコード上に分散して記述されているメッセージが把握しにくい。EXCELで管理出来ていれ ば全体を把握できる。 A:「本当」に、そんな事したいのか？ どうせ見なくなる事必定だが、まぁ、考えてみよう。 メッセージの定義は、クラス内のフィールド（スタティックな文字列）として定義されている。 だから… カンタンよネ？
- 25. リフレクションでぎょばぎょば 要するに、メッセージ定義を解析すればいいんだよね、リフレクションで。 AppDomain内に読み込まれている 全てのアセンブリから抽出 関係のある定義だけに絞り込む （ここでは名前空間を使用） ジェネリッククラス内の 定義は無視 EXCELファイルに出力
- 26. これで文句ない？ このファイルを元ネタにすれば良いよね？ 「一覧が見たい」のなら、どうぞEXCELの 神機能を使って見まくって下さい。 エンハンスネタとして： GetMessageに可変引数を追加すれば、FormatMessageとか作れるね。 上記のEXCELフォーマットを拡張して、カスタマイズしたいメッセージだけを書き入れるカラムを追加する。 → ハードコーディングされたメッセージと比較しながら、メッセージを修正できる。 リフレクションで参照するアセンブリは、フォルダ内のDLLを一括読み取り出来るようにする・あるいは別の ツールとして分離する。 Stringではなく、何らかのモデルクラスを使わせることにより、もっと多くの情報をマッピング出来る。 例：メッセージボックスに出力する事を前提に、メッセージボックスのアイコンを指定させるとか、メッセージボックス の戻り値をタイプセーフにする（モデルクラスをジェネリックにして、T型に列挙型を指定させるなど）
- 27. 開発手順がどう変わるか？ ソースにメッセージを直接定義する。従って、仕様書には単にUI表示したいメッセージをそのまま記述す るだけ。 ソースコード上の定義のすぐそばでその定義を使える（間違えにくい・しかもハードコードされたメッ セージが直視出来るから確認しやすい・ソースだけでメッセージの対応付けを把握可能） （ほぼ）タイプセーフである ラムダ式がフィールド参照式であることを前提としているだけ。 スペルミスなどの、単純ミスによるキー名を指定する可能性は無い。だって、ビルドできないし。
- 28. 開発手順がどう変わるか？ キー名の事は忘れて良い。定義は「そこ」にハードコーディングされているし、非人間的な、連番管理とかいら ない。 メッセージをオーバーライドしたい運用管理者だけが、識別しやすいシンボル名ベースのキーで区別すればよい。 インテリセンス・リファクタリングツール・静的解析ツールに親和性がある。 キー名の変更も楽々。相応しくないと思えばすぐに修正出来る。変更に失敗してもビルドエラーで検出できる。 誰がこのメッセージを参照しているのか、なんて、EXCELなんて見なくてもすぐに把握可能。 メッセージ定義は全てソースコード上に存在するので、マージが楽。 メッセージの差し替えは、完全に運用の現場に移譲できる。 差し替え用の元ネタファイルを提供できるので、後は勝手にやってよ。って言える。 最終的に、開発・保守の効率を上げるという「価値」を生み出すというこ とが重要。 これを出発点にしないと、合意形成は難しい。なぜなら、太古の手法を変 えたくないという心理が働くから。
- 29. 休憩
- 31. CSVファイルを読み取る ちょっと別の方向から攻めてみます。 CSVファイル（カンマ区切りレコード）の読み取りをどうやってる？ StreamReaderを使って自前でパース？まさかね。 いやいや、ここは、少なくともTextFieldParserクラスを使ってよ。 え、なにそれ？ 何と「Microsoft.VisualBasic.FileIO.TextFieldParser」というクラスで、「Microsoft.VisualBasic.dll」に あるわけです（参照設定してね）。 ええー？VBぃぃぃ？応用性あるの、そのクラス… 意外としっかり作ってあります。 Encodingクラスは勿論対応、セパレータ文字列を指定可能、ダブルクォートの自動認識あり、と、普通 に使うには全く問題ないレベルです。
- 32. で、CSVファイルのカラム定義とか 皆さん大好きなEXCELでやるわけです。こんな風。 郵便番号データ http://www.post.japanpost.jp/zipcode/dl/readme.html
- 33. じゃぁ、EXCELを読み取ってモデルを作りますか 例によって、ClosedXMLで読み取ります。 EXCELからカラム情報を読み取って、 カラムのフィールド名で辞書を作る カラム情報を保持するモデルクラス
- 34. モデルクラスを作る フィールドの型をどうにかしないと。 形式のカラムを読み取り： 「32ビット整数」→ int 「文字列」→ string 「真偽値」→ bool 「8ビット整数」→ byte 「8ビット整数」は本当にこれでいいのか？ 値には「変更なし」とか「指令都市施行」などという、具体的な意味が割り当てられている。 Enumっぽいよね。Enumにしよう。
- 35. ちょっと修正する カラム情報モデルクラスに、CLR型を取得するプロパティを追加 8ビット整数の場合はEnumにしたいが型名が ないので、フィールド名に”Values”と追加した 型名にする。 誤った指定は文字列にする Enum以外はnullを返す 「内容」のカラムをカンマで区切った 一つ一つの要素（word）を、更にコロン で区切り、成功した場合（個数が2）に のみ、辞書化する
- 36. モデルクラスis 何 今手に入れたカラム情報から、モデルクラスのソース コードを生成する。 FieldClrTypeとFieldClrEnumDefinitionプロパティで、 Enum型の定義を出力 モデルクラス本体を出力
- 38. TextFieldParserでCSVファイルを処理する スケルトン的にはこんな感じ 配列に1レコードのフィールド群の値が 入って返ってくる 区切り記号とかの初期化
- 39. LINQで使えるようにしよう IEnumerable<string[]>にすれば、とりあえずLINQで繋げられるので： yield returnを使って、LINQソース化する LINQは本当に強力だ(6)TextFieldContexthttp://www.kekyo.net/2012/11/17/linq%e3%81%af%e6%9c%ac%e5%bd%93%e3%81%ab%e5%bc%b7%e5%8a%9b%e3%81%a0-6%e3%80%80textfieldcontext/
- 40. よっしゃよっしゃ 早速モデルクラスにいれてみ…アレ？ いや、書かなければならないのは分かるが、 何かモヤモヤする…
- 41. リフレクションで入れればいいんでね？ 手で変換コードを書きたくないよね。 リフレクションを使えば、自動化できそうだ。 問題がいくつか： フィールド位置の対応付けをどうするか。 CSVはすべて文字列なので、型変換をどうするか。 ソースコード上、たまたま 順序通り並んでいるが、リ フレクションで順序が維持 される保証はない
- 42. 属性クラスis 何 CLRのメタデータを拡張可能な概念として「属性クラス」がある。 カスタム属性クラスを定義すれば、メタデータに情報を付加できる。 例：XmlSerializerクラスは、「XmlElement」や「XmlAttribute」属性を使って、XMLの表現方法をカスタマイ ズできる。 CSVのフィールド（モデルクラスのプロパティ）に、カラム位置を付加すれば判別可能になるよね。 カラム位置を保持するカスタム属性 プロパティ情報 （PropertyInfo） CsvColumnIndexAttribute Index = 1 Name = “旧郵便番号” GetCustomAttributes()
- 43. カスタム属性クラスis 何 属性クラスは「Attribute」クラスを継承する必要がある。 属性クラスは「AttributeUsage」属性を適用する必要がある。 → 属性クラスに属性を適用するとか、モヤモヤするかもしれないけど、こういうものだと割り切って下さい。 Attributeクラスを継承 AttributeUsage属性を適用 （この属性はプロパティにしか適用できない事を宣言） コンストラクタで値を受け取る 事が出来る プロパティで見えるように しておく
- 45. メタデータついた！
- 46. お膳立てが整ったので、自動化する 属性が適用されているプロパティだけを抽出 （念のため） インデックスを射影して保存
- 47. 例外発生orz フラグ値“0” をboolに 変換しようとして失敗 Convertクラスで文字列をboolに変換する場合 は、”true”・”false”でなければならない
- 49. 特別なパース処理 Enumの場合、Enum.Parseを使用すると、列挙値のシンボル名や生の値（数値）からEnum値に 変換出来る。 bool値の変換 Enum値の変換 その他の型の変換
- 51. クエリを試してみる
- 52. 休憩
- 54. リフレクションをどうにかしたい リフレクションは遅いので、どうにかリフレクションなしで同じことを実現したい。 案その１：文字列配列からプロパティに代入するコードを、モデルの一部として実装する。 案その２：式木を生成してコンパイルして実行する。
- 55. カスタムコード生成方式 モデルクラスのソースを自動生成しているのだから、カスタムコードを生成して埋め込めば？ コンストラクタの引数にフィールドの文字列配列を指定可能なコードを生成する。 比較的簡単で理解は容易。 モデルクラスのコードを手動で実装する場合は負担増。 モデルクラス （コンストラクタ） フィールド 文字列[2] フィールド 文字列[1] フィールド 文字列[0] 文字列変換 ソース ジェネレーター
- 58. モデルのインスタンス生成が… ジェネリック制約「whereT : new()」が使えない。 制約にはコンストラクタ引数を定義出来ないため すると、「varmodel = newT();」と書けなくなる。 仕方が無いので、動的にインスタンスを生成。 コンストラクタ引数がある （フィールド文字列群）
- 59. 式木を使ってインスタンスを生成 「model = (fields) => new T(fields)」という式に相当 するコードを、実行時に生成 （ループ中で生成すると負担が大きいので、ループ外 で生成しておく） Activator.CreateInstanceと比べてコストは 殆どない（newしたのとほぼ同じ）
- 60. どうせ式木使うなら 生成からプロパティ設定まで、全部式木でビルドすればいいじゃん？ コード例は大きすぎるので省略。デモンストレーションします。 （GitHubのソースコードを参照してください）
- 61. アンチパターン そろそろ、難易度は別にして「ソースコードベースで何でも出来そう」な気がしてきましたか？ EXCEL仕様書で延々と無駄な作業を行っていることに、疑問を感じてきましたか？ 難しい式木の話はこれにて終了。
- 62. まとめ わざわざ難易度の高い技術まで含めてお見せしたのには訳があります。今や、CLR内のメタデータを 使って、色々な事が出来る、という事を示したかったからです。 実際には自分でコードを書かなくても済む場合も多いです。本稿で示した内部の実装は、既にライブ ラリとして提供されています。例として： EntityFrameworkは、データベースへのアクセスを抽象化します。テーブルやカラムといったデータベースの 要素を、メタデータの属性でマッピングさせることで、データベースプログラミングを大幅に簡略化します。 本稿のCSVファイルへのアクセスは、「LINQ to CSV」というオープンソースのライブラリで同様の機能を実 現しています。モデルクラスへの自動マッピングによって、CSVファイルへのアクセスもタイプセーフ性を前 提に出来ます。また、「LINQ to twitter」を使うと、ツイッターのタイムラインデータを、タイプセーフなモ デルクラスを用いてアクセス出来ます。 もっともBasicな、XmlSerializerも、メタデータを活用した例です。 SandCastleや類似ツールこそ、ドキュメンテーションの為にメタデータを活用する良い例です。（リファレ ンスとしての有用性はまた別の話題） 総じて、昔では（事実上）出来ない事だったことは、今では当たり 前に出来る事です。
- 63. まとめ これらのサードパーティライブラリ群に加えて、Visual Studioを取り巻く開発環境が非常に強力です。 本稿で取り上げた「インテリセンス」や「リファクタリング」機能が標準で備わっています。従来のテ キストベースの一括置換で、誤って変更してしまうような事故がありません。 「一度決めた仕様を変えるな！」あるいは「一度決めた仕様を変えるためには開発運用手順に従って….」とい う足かせは、改善に対する前向きな取り組みを徐々に破壊していきます。 「どうせ言ってもムダだし」「言われたところだけを言われたようにやっておけばいい」という文化につながっ てしまいます。 そもそも、ルールを定めなければならなかった理由の一つが、そうしないと直ぐにコードが破綻してしまうから です。しかし、リファクタリングツールはそれを機械的に自動的に安全に処理出来ます。このエコシステムに 乗って開発しないと、高価なツールを使っている意味がありません。 リファクタリングや静的解析ツールは、サードパーティ製のツールを導入すると、更に強力になります。 「Resharper」や「NDepend」の価格と、自分の時給換算の報酬額を比較してみて下さい。無駄な残 業何日分で導入できるでしょうか？そして、全自動・半自動で行われるこれらの作業が、自分の時間を どれだけ解放できるでしょうか？その時間は是非「人間にしか出来ない作業」に使って下さい。
- 64. まとめ そして、これらのすべてが、「ソースコード」そ のものや「CLRメタデータ」を元に動作します。 そこに「EXCEL仕様書」の出番は全くありません。 繰り返しになりますが、EXCELにはEXCELの良さがあります。しかし、使い方が明後日の方向を 向き、外野でどんどん技術が進歩している現実を無視し、トータルでどのように改善できるかを 考えないうちは、ソフトウェア開発の効率性を上げて行くことは出来ません。
- 65. 長時間のご清聴、ありがとうございました！ 質疑応答：どんな質問でも受け付けます。必ず家に持ち帰って、自分なりに 噛み砕けるように、不明点は今のうちに掘り下げて下さい（本日はかなり時 間に余裕があります）。 本稿のデモコードはGitHubに上げてあります。 https://github.com/kekyo/CenterCLR.Demo1 スライドは、私のブログに掲載予定です。 http://www.kekyo.net/