設計書って言っても色々とあるけど。現場によって色々と言葉が違うけど。ここで書くのは内部設計書に相当する設計書の話になると思う。
俺は設計書の部・章・節はそんなに気にしない。誤字脱字も多少なら気にしない。読み手が補完して解釈する事が出来れば別に良い。そういうのは問題にしない。設計書の見栄えとかは俺も苦手とする分野だし。問題なのはロジック的に誤っていたり矛盾していたり曖昧な部分があったりして、読み手が確信に至る事が出来ない様な内容である事。
例えば設計書に「3 分毎にｘｘｘ処理を行う」って記述があったとして、それ以上の記述が無いとすれば、その設計書は曖昧過ぎると思う。
読み手が確信に至るには以下の様な記述が必要になる。
- 「3 分毎にｘｘｘ処理を行う」というのは「ｘｘｘ処理の始まり」から「ｘｘｘ処理の始まり」までが 3 分であるという事である。最初のｘｘｘ処理の始まりが 01:23:45 なら 2 回目のｘｘｘ処理の始まりは 01:26:45 であり 3 回目のｘｘｘ処理の始まりは 01:29:45 である。動作の遅延が発生したり Sleep 等々の精度の悪さにより 2 回目のｘｘｘ処理の始まりが 01:26:47 になったとしても 3 回目のｘｘｘ処理の始まりは 01:29:45 である。つまり常に最初のｘｘｘ処理の始まりを基準として考える。
- 3 分という時間を計る為に OS の時計を用いる。CPU が保持するカウンタ等々は用いない。OS の時計は NTP 等々によって常に調整されている物とし、またその調整方法は「連続した微調整」による物とする。この「連続した微調整」とは例えば OS の時計が進み過ぎているのなら、2 ミリ秒毎に時計を 1 ミリ秒だけ進ませるという処理を連続して行う事を意味する。逆に時計が遅れているのなら 1 ミリ秒毎に時計を 2 ミリ秒進ませる。
- 3 分という時間を計る為に秒の単位までを用いる。ミリ秒以下の単位は全て切り捨てる。
- 1 分間は 60 秒とする。閏秒に関する特別な処理は必要としない。プログラムが実際に動いた時に閏秒を考慮した動作になっても考慮しない動作になっても良しとする。
- ｘｘｘ処理に 3 分間以上掛かった場合は連続してｘｘｘ処理を行う。この 3 分間以上の時間が掛かる場合というのは極めて稀に発生する物とする。なので何度か連続して処理をしていれば自然と遅延を挽回する。「そもそも通常のｘｘｘ処理が 3 分間以上掛かる場合」というのは有り得ない物とする。仮にそうなった場合の処理は動作保証対象外とするのでプログラムには一切盛り込まないで良い。
- プログラムを一度停止して再起動した場合は以前に動作していた時の「最初のｘｘｘ処理の始まり」を考慮しない。新たに「最初のｘｘｘ処理の始まり」を決める事とする。
- 正常終了や通常終了といった物は用意しない。強制終了でのみ終了する。それは Ctrl-C をブロックするという意味では無く、そういったシグナルが来たなら別に終了しても良い。但し終了ハンドラを書いたりして特別な処理を行ったりはしない。
- 強制終了されたとして、次にプログラムを起動した時にリカバリ処理( ロールバックやリジュームやクリーンアップ等々 )を行う必要は無い。またリカバリする為の特別なスクリプトやオペレーションマニュアルも不要とする。
- 処理の始まりを待つ間は CPU に負荷を掛けない事。それにはプラットフォームが備える標準的な方法を用いる。タイマ精度は誤差 1 秒未満もあれば十分。
- システム寿命は 2000 年の年初から 2200 年の年末までとする。その間にずっと問題無く動き続けるタイマ等々を用いる事。
これぐらい書いて置けば大丈夫かなあ…。未だ足りないかも。俺は上記の様な情報がちゃんと書かれていれば良い設計書だと思う。プログラムの一行一行に対応する様な事は全く書かなくて良いと思う。はっきり言って要らない。内部設計書にそんな物は書くなって思う。
