点と点をむすぶものとしての - 詳細設計書
2014/02/08
■
雑記
設計書
《作る(コーディング)》する上で必要な情報がない。
リバースエンジニアリングみたいなことして、プログラムを書くような状態って、《謎とき》で楽しいのははじめのうちで、時間に追われていると、メモ書きでも残っていたらと思う。
この設計書が無駄だと思う瞬間は、これから《作ろうとされモノ、作るモノ》を表現するのに足りないからと知っているからなのだけど、この足りない隙間を埋めるのがプログラマーだと思われるのかと思うと、ちと悲しい。
《作る》上で、役に立つ設計書とは何かなーと考えるのだけど、《どこに何をどう入れる》が《全量》書いてあること。理想はコードと設計書が1対1ぐらいになるようなイメージ。もちろん表現が違うけど、情報が対になるぐらいに。《全量》大事。やるなら《全量》希望。
そこまでできれば、あと表現を変えれば、ソースから設計書へ、設計書からソースへと。
(本当にそうできるかはわからないけどな、へへへ)
そこまでいくと、設計書って何よって話になるのかなと思うけど、人がシステムとか、《これから作られようとするモノ》、《既に作られたモノ》を理解するのに役に立つ何かというのが、僕の定義 。
常に変化し続けるシステムがあって、そういケースは、《転記(コピペ)するだけの設計書》なんていらないというのもあるだろうけどな。
アルゴリズムというかロジックというか処理の流れを、フローチャートを使わずに書く記法みたいなものを採用して欲しい。
フローチャートって、最初に起こすコストより、メンテナンスするコストのほうが高いような気がする。エクセルで、図の編集ってひとつひとつ動かさないいけないでしょう。
コピペだけの労働集約的な作業をもっと、品質あげたり、ユーザーのためにであったりと そういうところにエネルギーと費やしたいよねと。
《点と点》と思うのは、一般的な、画面にDBの中身を表示するようなプログラムで、点(DBのこのテーブルのこの項目)を点(画面のどこそこの位置)にだすので、それを《結ぶ》のプログラムであり、設計書の役割かなーと。単純に考えてみた。
徒然に。
: