より表現力のあるプログラミング言語の進化により、ソフトウェア設計仕様の必要性は大幅に減少しましたか？

数年前の私を含む多くのIT担当者にとって、理想的なソフトウェア開発プロセスでは、コード行を記述する前に、多くのUMLダイアグラムを含む詳細な設計ドキュメントを作成する必要があります。（これはウォーターフォールモデルの説明のように見えますが、反復がより小さいことを除いて、アジャイルでも同じです。）

過去2、3年の間に、私は完全に考えを変えました。関連するテストケースを含む詳細な要件仕様は、絶対に不可欠であると私はまだ考えています。大規模なプロジェクトの場合、コーディングを開始する前に、アーキテクチャ全体の概要も必要になります。ただし、残りはすべてコードで可能な限り行う必要があります。理想的なケースでは、コード自体を除いてソフトウェア設計の説明はありません。

どのようにしてこの結論に達しましたか？以下にいくつかの引数を示します。

フィードバック

文書を書いたり、図を作成したりするツールはほとんどフィードバックを提供しません。はい、UMLダイアグラムの整合性チェックを行うモデリングツールがありますが、それらは制限されており、多くのオーバーヘッドが伴います。

フィードバックがなければ、エラーを認識して修正することは困難です。

コードを書くとすぐに、次のような多くのフィードバックが得られます。

• コンパイラからのエラーと警告
• 静的コード分析結果
• 単体テスト

エラーをすばやく認識して修正できます。

一貫性

コードがドキュメントと一致していることを確認するには、何度も確認する必要があります。頻繁な変更がある場合、コードとドキュメントの同期を保つのは困難です。

リファクタリング

テキストの説明や図をリファクタリングするのは通常困難でエラーが発生しやすい一方で、コードをリファクタリングするための強力なツールとテクニックがあります。

この作業を行うための前提条件が1つあります。コードは読みやすく、理解しやすいものでなければなりません。これはおそらくAssembler、Basic、またはFortranでは達成できませんが、最新の言語（およびライブラリ）ははるかに表現力があります。

したがって、私の議論が有効であれば、ソフトウェア設計の仕様やドキュメントの軽量化や軽量化に向かう​​傾向があるはずです。この傾向の経験的証拠はありますか？

言語がますます表現力を増すという前提に疑問を呈します。今日のc＃のASP.NETコードでは、Visual BasicでASPコードを記述したときとほぼ同じレベルで記述します。まだc ++を使用しています。Javascriptは機能を追加しましたが、全体的に言語は変更されていません。SQLでも同じです。

これらの他の変更はより重要だと思います：

1. 自動化された単体テストの採用。テストは仕様であると言う人もいるでしょう。そのため、仕様を記述する必要性は排除していません。むしろ、Word文書ではなくコードで記述します。

2. 展開方法の変更。過去には、ソフトウェアの更新されたコピーを出荷する必要があるため、間違えるのは非常に高価でした。したがって、注意する必要がありました。Web駆動型アプリケーションを使用すると、修正プログラムをすぐに使用できるように展開できます。また、問題を予測するのではなく、対処する余裕があり、進行中にコードを再構築できます。

3. デザインパターンの採用。誰もがパターンを知っていれば、ほとんど何も設計する必要はありません。「リポジトリファクトリを追加する」と言うだけで、チームはUMLを見る必要なくそれを実行できます。

4. SOAのデータコントラクト。最近はほとんどすべてがSOAです。必要なのはWSDLだけです。データ転送フォーマットの定義と文書化の時代は終わりました。よりRESTfulでマイクロサービスに向かう現在の動きは、この傾向を続けています。

5. ソフトウェアは小さいです。一部はSOAアーキテクチャの結果として、チームは互いに結びついた小さなプログラムを作成しています。個々のコンポーネントはそれほど複雑ではなく、事前の設計も少なくて済みます。また、コンポーネント間のインターフェース定義によって強制されるファイアブレークのため、ソリューション全体を壊すことなくアーキテクチャの一部を変更するのが簡単です。

6. 確立されたライブラリのはるかに多くの使用。.NET CLRには大量の機能が用意されているため、セッションデータをキャッシュするためのスキームを設計する必要はありません。jQuery UIやBootstrapなどのサードパーティライブラリは、特定の方法で動作するコードを記述するための標準を確立します。これらを文書化する必要はありません。チームはそれらをそのまま使用できる必要があります。

7. 業界の成熟。SWEは、特定の目標を達成するために何年も費やす「Battlestar Galactica」プロジェクトのようなものは存在しないことを学びました。それらの年が経過する頃には、目標は変わります。今日、設計に必要なすべてを正確に実現するよりも、市場投入までの時間がはるかに重要であることを知っています。

8. より優れた、より一貫した教育を受けたエンジニア。最近では、（できれば）ベストプラクティスを理解しているエンジニアを雇うことができ、設計ドキュメントに何をすべきかを伝えることなく、それらを実装するだけです。

9. TFSのような生産性ツールを使用すると、ユースケースを参照し、技術的な曖昧な決定に対していくつかの箇条書きを提供する簡単なタスクを作成できます。それ以上は必要ありません。開発者は、ツールを使用してすべてのレビュー、評価、コードレビューの取得、チェックインなどを行うことができます。これは、すべてを結び付けるため、外部ドキュメントを操作するよりもはるかに効率的です。

まだいくつかのことについて設計ドキュメントが必要です。たとえば、アプリケーションが異なるチームによって開発された異なるコンポーネントに分割されている場合、少なくともどのコンポーネントがどの要件を担当するかを伝える必要があります。しかし、ほとんどの場合、今日の開発方法論は、開発者が不十分な決定を下すことから生じる可能性のあるリスクを管理し、封じ込めるツールを提供しながら、はるかに自由になります。

いいえと主張します。

簡単な理由で

数年前の私を含む多くのIT担当者にとって、理想的なソフトウェア開発プロセスでは、コード行を記述する前に、多くのUMLダイアグラムを含む詳細な設計ドキュメントを作成する必要があります。

1990年代からエクストリームプログラミングが存在していたため、「理想」とは見なされませんでした。そしてあなたが言うように：

理想的なケースでは、コード自体を除いてソフトウェア設計の説明はありません。

ずっと前に議論されました。たとえば、1992年のこの伝説的な記事：ソフトウェアデザインとは何ですか。

上記は、複雑な言語やIDEを必要とせずに、高度に進化したアーキテクチャと反復アプローチを使用して「極端な」プロセスを実現できることを示しています。

代わりに、この「見かけ」は、多くの図やユースケースドキュメントを使用したデザインの前倒しから、より進化的で反復的なアプローチへの移行であると言えます。動的な環境と、より「アジャイルな」環境で受け入れて作業する方がはるかに簡単な人向けです。

私はこれにほぼ同意しますが、あなたが暗示するよりもずっと早く始まったと思います。また、表現力の他に別の大きな要因があると思います。父が最初にプログラミングを始めたとき、彼はパンチカードを作成し、コンピューターで時間をスケジュールする必要がありました。プログラムを実行する機会が1日1回得られる場合があります。コードの構築を無駄にし、失敗させてから修正する時間はあまりありませんでした。多分2枚か3枚のショットを撮ったのに、うまくいかなかった場合は困っていました。

このリスクは、プログラムを計画するために多くの余分な時間を費やすことが重要であることを意味していました。人々はコードを鉛筆で書き、それをパンチされたカードに転送します。技術が進歩するにつれて、端末に直接コードを書くことができましたが、共有リソースを使用していたため、CPUは高価でした。テストファーストの方法論は、その世界では完全に受け入れられません。前もって計画しなかった場合、同僚は熊手であなたの机にいるでしょう。

コンピューティングリソースは、信じられないほどのペースで安価で優れたものになりました。これらのすべてのプラクティスが開発された制約の多くは完全に消去されています。Euphoricが指摘するように、これからの移行は90年代に始まった。多くの大きな先行設計の継続は純粋な慣性でした。

そのため、プログラミング言語の表現力の向上は、表現コードをドキュメントとして使用する方が簡単であるという単純な事実から、これに影響を与えました。コードの内容を伝えるドキュメントを作成するコストは非常に高く、価値があります（あるレベルでは必然的に間違っています）。

そもそもデザイン文書を持つことの目的を忘れていると思います！

設計ドキュメント（要件、ユースケース、モックアップなど）を使用すると、システムを高レベルで説明、理解、および議論できます。そのようなドキュメントに残された詳細の量は、それらを有用にするものです。

システムシステムの正確な動作を記述した文書持っている必要はありません、すべての実際のソースコード自体は、この目的を果たすため、詳細は。

ソフトウェア開発は、人間が読める高レベルの仕様を、マシンで実行可能な低レベルの明確な仕様に変換するプロセスと考えることができます。ただし、このプロセスには入力が必要です。

理想的なケースでは、コード自体を除いてソフトウェア設計の説明はありません。

これは、あなたが暗示するよりもさらに外れています。依存型（私が理解しているように、理論的には非常に有望です）のようなものでさえ、数年先です。

フォーマル検証は非常に難しいため、フォーマル検証が一般的に使用されるのは暗号ライブラリのみです。

単体テスト

プロパティテストが主流になっていない場合、これは長い間実用的ではないと思います。

さらに、優れたテスト（リファクタリングごとに編集する必要はありませんが、それでも十分なエラーをキャッチします）の作成は非常に困難です。

コードがドキュメントと一致していることを確認するには、何度も確認する必要があります。頻繁な変更がある場合、コードとドキュメントの同期を保つのは困難です。

現時点では、おそらくドキュメントテストツールを使用する方が簡単です。

この作業を行うための前提条件が1つあります。コードは読みやすく、理解しやすいものでなければなりません。

残念ながら、非常に表現力があるだけでなく、非常に読みやすい言語を設計することは困難です。Goなどの言語は読みやすさを優先し、より高いレベルの思考を妨げます。

最後に、私の経験では、より良い言語とツールは、バグの少ないソフトウェアではなく、より大きなプロジェクトにつながります。pandoc1970年に書かれていたもっともらしい方法は実際にはありません。