PCで開発し始めた４０年前くらいから「ソースコードは設計」ずっと言い続けています。
設計書は、紙テープ、紙カードで入力していた時代（約４０年以上前）の遺産。紙テープ、紙カードを見ても、理解できないから（デバッグを紙テープ、紙カードを眺めてされている方はいました）。計算機を独り占めできないからフローチャートを書いたり、机上でバッグしていた。今は、ソースコードと変換可能でない資料を作ることは、無駄なだけでなく、保守上の誤りを混入させるものとして忌遺すべきことです。
<この項は書きかけです。順次追記します。>
This article is not completed. I will add some words in order.
ソースコードを設計と呼んでいる分野
HDLでは、ソースコードが設計で、回路図が実装です。
RTL Design Style Guide
は、日本が誇る名著です。
残念なことに、日本語よりも、英訳の方がわかりやすいです。
日本人にありがちな、日本語で書くと余分なこと、わかりにくく書くのに、英語で書くとわかりやすく書いてしまうという。
ちょうど、西暦2000年問題の時、日本の企業の日本語の情報はさっぱりわかりにくいのに、日本の企業の英語の情報やすごくわかりやすかったことを記憶しています。
ソースコードで仕様記述できる
仕様記述言語で記述し、機械語などに変換可能な言語に変換する方法では、仕様と動作が結びついていて、抜け漏れの可能性は低い。
仕様を記述することと、設計することは表裏一体。
設計不可能な仕様を記述しても仕方がないし、
設計によっては仕様が変わることがある。
追跡は自動的にできている。
整合性も、仕様記述言語、機械語等に変換可能な言語で確認が取れる。
設計を見直す
設計を見直す時、ソースコードまたは設計図で変更し、模擬試験(simulation)をして設計の良し悪しを判断する。ソースコードまたは設計図なら設計の良し悪しを判定できる。
設計書と称して、動かない文字をどれだけならべても、設計の良し悪しは反転できない。
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
This article is an individual impression based on the individual's experience. It has nothing to do with the organization or business to which I currently belong.
文書履歴(document history)
ver. 0.01 初稿
ver. 0.02 標題追記 20190530
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.