点と点をむすぶものとしての - 詳細設計書 2014/02/08

《作る(コーディング)》する上で必要な情報がない。
リバースエンジニアリングみたいなことして、プログラムを書くような状態って、《謎とき》で楽しいのははじめのうちで、時間に追われていると、メモ書きでも残っていたらと思う。

この設計書が無駄だと思う瞬間は、これから《作ろうとされモノ、作るモノ》を表現するのに足りないからと知っているからなのだけど、この足りない隙間を埋めるのがプログラマーだと思われるのかと思うと、ちと悲しい。

 《作る》上で、役に立つ設計書とは何かなーと考えるのだけど、《どこに何をどう入れる》が《全量》書いてあること。理想はコードと設計書が1対1ぐらいになるようなイメージ。もちろん表現が違うけど、情報が対になるぐらいに。《全量》大事。やるなら《全量》希望。

そこまでできれば、あと表現を変えれば、ソースから設計書へ、設計書からソースへと。
(本当にそうできるかはわからないけどな、へへへ)

そこまでいくと、設計書って何よって話になるのかなと思うけど、人がシステムとか、《これから作られようとするモノ》、《既に作られたモノ》を理解するのに役に立つ何かというのが、僕の定義 。

常に変化し続けるシステムがあって、そういケースは、《転記(コピペ)するだけの設計書》なんていらないというのもあるだろうけどな。

アルゴリズムというかロジックというか処理の流れを、フローチャートを使わずに書く記法みたいなものを採用して欲しい。

フローチャートって、最初に起こすコストより、メンテナンスするコストのほうが高いような気がする。エクセルで、図の編集ってひとつひとつ動かさないいけないでしょう。

コピペだけの労働集約的な作業をもっと、品質あげたり、ユーザーのためにであったりと そういうところにエネルギーと費やしたいよねと。

《点と点》と思うのは、一般的な、画面にDBの中身を表示するようなプログラムで、点(DBのこのテーブルのこの項目)を点(画面のどこそこの位置)にだすので、それを《結ぶ》のプログラムであり、設計書の役割かなーと。単純に考えてみた。

徒然に。



: