■

プログラム作りはテキストの編集作業である。→ソースの話
Script言語もインタプリタもコンパイラ言語もソースはみんなテキストデータである。
これをしっかり踏まえて。

先日、仕様書と言う名のExcelと格闘してたプログラム大好きエンジニアとこんな話をしてみた。

( ´∀｀)＜画面作りにおいら推奨な手法をとりいれてみませんか。
(,,゜Д゜)＜なんですか。
( ´∀｀)＜何個かの画面を解析分析して、パターンを洗い出し、
　　　　　　そのパターンを構築するためのソースを作るんです。
　　　　　　画面はそのパターンというか、パーツと言うかそんなのを組み合わせるだけで構築すると。
　　　　　　そうすれば1個目をつくるのに多少時間はくいますが、2個目以降の作業工数は激減しますぜ。

この人とは、前にデータベースアクセス部品（以下Accessorと記）を作るときにも話をしてました。（※部品の概要はココで）
データベースの項目リストを用意すると、そこからSQL文もアクセス用のクラスもData受け取り用のEntityも一式作る仕組みってやつです。

(,,゜Д゜)＜こないだ言ってたAccessorの話ですか？
( ´∀｀)＜それもありますが、その手法というか概念を画面作りに応用するんです。
(,,゜Д゜)＜っといいますと？
( ´∀｀)＜Accessorも画面も構成しているのはプレーンテキストですよね。
　　　　　　ってことはテキストを構築すればモノができるって寸法ですよね。
　　　　　　Accessorで実現しているのはデータベースアクセスする手法ってのが
　　　　　　業務によって劇的に変わるってことがほぼ無いことを利用しています。
　　　　　　つまり、やることが決まっています。
　　　　　　あとはそれにあわせたテキストを構築するのはツール化できるので、
　　　　　　再構築の速度はコピペ並みの時間で済みます。
(,,゜Д゜)＜ん〜画面でそれできるんですか？
( ´∀｀)＜Accessorと違う点は、今回の画面構築は今回しか必要がないって要件があることですが、
　　　　　　今回だけに特化したパターンを作ればいいんです。
　　　　　　編集をパターン化すればツール化が可能になります。
　　　　　　ツール化できれば作業時間が激減します。
　　　　　　ついでに、ツール化する際の元となるソースは
　　　　　　きっと我らが検証し、取りまとめた洗練されたソースとなるはずです。
　　　　　　この品質が全画面に対して保証しやすくなるおまけ付です。
　　　　　　ただ、一つ問題があります。
(,,゜Д゜)＜っといいますと？
( ´∀｀)＜スケジュール管理上、はじめだけ誤差がでます。
(,,゜Д゜)＜？
( ´∀｀)＜ほれ。今、10画面あるとしたら、等間隔でひかれてるでしょ。
　　　　　　全部同じ時間で割り当てられてるやないですか。
　　　　　　頭の固いスケジュール管理者がいた場合、
　　　　　　これらのパターン解析だのテンプレートだのツールだの作っている時間は項目としてでてこないので
　　　　　　一見、作業が進んでいないように見えるでしょ。
(,,゜Д゜)＜そうですねぇ。
( ´∀｀)＜絶対に終わるためにやっていることでもここに誤解が生まれる余地ができます。
　　　　　　これに対処するっていうめんどそうなことが問題といえば問題ですｗ
　　　　　　もう一つ、予想されることがあります。
(,,゜Д゜)＜ほぅ。
( ´∀｀)＜これらのツール化したものを利用する際に、
　　　　　　作られたツールや成果物の全てを知っている管理人みたいのが必要になります。
(,,゜Д゜)＜Wikiか何かで管理すりゃええんじゃないんですか？
( ´∀｀)＜おお。全文検索できるならそれもありですねぇ。
(,,゜Д゜)＜パーツを作っていくにはいい方法思いつきましたよ。
　　　　　画面をパーツに区切ったときにそれを作るメソッドか何かをつくるじゃないですか。
　　　　　それを作ったやつがどこかに登録していくんです。
　　　　　そしたらそれ実現できそうです。
(σ・∀・)σ＜それっ。
　　　　　　そこでツール管理者が必要になるのですよ。
　　　　　　ついでにメンテナンスも必要になりますよ。
　　　　　　1回目作ったときはこれでよかったけれども、
　　　　　　似たような別の事象が出来たときなんかに改修がでてきます。
(,,゜Д゜)＜そうですねぇ。
　　　　　ところで。
( ´∀｀)＜？
(,,゜Д゜)＜そのパーツわけなり、解析なりって難しくないですか？
( ´∀｀)＜技術的に〜ですか？
(,,゜Д゜)＜仕分けるのが。
( ´∀｀)＜よくぞ気付いてくれました。
　　　　　　観点が大事になるので、我々くらいのレベルがないとうまくいくものができません。*1
　　　　　　ゆえにやるときには我らは必ず作業にかまないといけません。
　　　　　　しかして仕分けさえできればあとの実装はヤシラでも大丈夫ですよ。
　　　　　　作業分担♪
(,,゜Д゜)＜ん〜。
( ´∀｀)＜ま、あれです。懸案事項はスケジュール調整とツール化の仕分けあたりです。
　　　　　　実際に適用されるなら最初はコッソリ手伝いますよ〜
(,,゜Д゜)＜ちょっと落ち着いたら考えてみます。

技術的な話も現実問題も両方の話ができる人はとても大事だ( ´∀｀)ノ
っと思うと同時に、すでに確立されてあるスケジュール管理方法を
現実問題に則した形で再定義することの難しさを感じてしまう瞬間です。

個人的にはこいつのレベルはどのくらいってのを感じることはできるけれども、
客観的な指標としてそれを数値化しろといわれると正確な値など出す術が無い。
ゆえに正確なスケジュールを引く材料がだせないのね。難儀。

*1:実装も設計も両方できないと美しいソースはできそうにないというような意味合いです。