■

久しぶりに見た。
それはさておき、どうやって作ってたかと言うと、
ソースから起こしてただそうだ。

だったら仕様書作成よりソースを直せ( ・ω・)oビシッ

昔ながらの仕様書形式にまとめると、例外なく読みづらくなる。
口頭説明の補助ナシにはプログラムが組めないものがほとんどだ。
口頭説明に掛ける1時間があるなら、なぜあと1時間追加する心意気で
ペアプログラミングをやらないのだろう？
プログラマにとって見やすいのは日本語文章よりもソースコードだ。

書いているうちに気付くことは必ずある。
そのときに質問できる環境。
また、ほぼ確実に返答を返せる人がいる安心感。
さらにサボれないので仕事を進めるしかない素敵な状況。
仕様の勘違いによるミスはこれでほぼ無くなる。

仕様書からソースを作成する場合、
プログラマは2つの言語の狭間で悩まなければならなくなる。
人類の言語とプログラム言語である。
規格化された定型文章の連続を解読したうえで
プログラム言語特性を踏まえた形で翻訳しなきゃいけないのである。
そらミスもおこるっちゅーねん。
解読作業を減らせることができれば必然的にミスも少なくなるもんです。

久しぶりの紙の仕様書。
A4の紙20枚もある仕様書。
萎えそうになる自分を実感できてます。ヽ(´ー`)ノ