より表現力豊かなプログラミング言語の進化に伴い、ソフトウェア設計仕様の必要性は大幅に減少しましたか？
数年前の私を含む多くのIT関係者にとって、理想的なソフトウェア開発プロセスは、コード行が記述される前に、多くのUMLダイアグラムを含む詳細な設計ドキュメントを作成することです。 （これはウォーターフォールモデルの説明のように見えますが、反復が小さいことを除いて、アジャイルの場合と同じです。）
過去2年か3年の間に、私は完全に考えを変えました。関連するテストケースを含む詳細な要件仕様は絶対に不可欠であると私はまだ考えています。大規模なプロジェクトの場合、コーディングを開始する前に、アーキテクチャ全体の概要も必要になります。しかし、残りはすべて可能な限りコードで実行する必要があります。 理想的なケースでは、コード自体を除いてソフトウェア設計の記述はないはずです。
どうやってこの結論に至ったのですか？ここにいくつかの引数があります：
フィードバック
ドキュメントを作成したり、図を作成したりするためのツールは、ほとんどフィードバックを提供しません。はい、UMLダイアグラムの整合性チェックを行うモデリングツールがありますが、制限があり、オーバーヘッドが大きくなります。
フィードバックがなければ、エラーを認識して修正することは困難です。
コードを書くとすぐに、次のような多くのフィードバックが得られます。
- コンパイラからのエラーと警告
- 静的コード分析結果
- 単体テスト
エラーをすばやく認識して修正できます。
一貫性
コードがドキュメントと一致していることを確認するには、何度もチェックする必要があります。頻繁な変更がある場合、コードとドキュメントの同期を保つのは困難です。
リファクタリング
テキストによる説明や図のリファクタリングは通常難しく、エラーが発生しやすい一方で、コードをリファクタリングするための強力なツールとテクニックがあります。
これを機能させるための前提条件が1つあります。コードは、読みやすく理解しやすいように簡単である必要があります。これは、おそらくアセンブラ、Basic、またはFortranでは実現できませんしかし、現代の言語（およびライブラリ）の方がはるかに表現力があります。
したがって、私の議論が有効であれば、ソフトウェア設計仕様とドキュメントの軽量化または軽量化の傾向があるはずです。この傾向の経験的な証拠はありますか？
言語はますます表現力があるという前提に疑問を投げかけます。今日のc。＃のASP.NETコードを使用して、ASP Visual Basicでコードを記述したときとほぼ同じレベルで記述します。引き続きc ++を使用します。JavaScriptには機能が追加されていますが、全体的に言語SQLと同じです。
これらの他の変更はもっと重要だと思います：
自動化された単体テストの採用。テストはある仕様だと言う人もいます。したがって、仕様を記述する必要はありませんでした。むしろ、Word文書ではなくコードで記述します。
展開方法の変更。以前は、ソフトウェアの更新されたコピーを出荷する必要があったため、間違いを犯すことは非常に費用がかかりました。だからあなたは注意しなければなりませんでした。 Web駆動のアプリケーションを使用すると、修正をすぐに使用できるように展開できます。また、問題を予期するのではなく、問題に対処する余裕があり、コードを再構築できます。
デザインパターンの採用。誰もがパターンを知っているときは、何もデザインする必要はほとんどありません。 「リポジトリファクトリを追加する」と言うだけで、チームはUMLを見る必要なくそれを行う必要があります。
SOAのデータコントラクト。ほぼすべてがSOA=最近です。必要なのはWSDLだけです。データ転送フォーマットを定義および文書化する時代は終わりました。RESTfulおよびマイクロサービスへの現在の動きはこの傾向を続けています。
ソフトウェアは小さいです。 SOAアーキテクチャの結果の一部として、チームは一緒に結び付けられた小さなプログラムを書いています。個々のコンポーネントはそれほど複雑ではなく、事前設計が少なくて済みます。また、コンポーネント間のインターフェース定義によって強制されたファイアーブレイクのために、ソリューション全体を壊さないアーキテクチャ。
確立されたライブラリのはるかに多くの使用。 .NET CLRは既成の機能を数多く備えているため、たとえばセッションデータをキャッシュするためのスキームを設計する必要はありません。 jQuery UIやBootstrapなどのサードパーティライブラリは、特定の方法で動作するようにコードを記述するための標準を確立します。これらを文書化する必要はありません。チームはそれらを使用するだけでよいはずです。
業界の成熟度。 SWEは、特定の目標を達成するために何年も費やしている「バトルスターギャラクティカ」プロジェクトのようなものはないことを学びました。それらの年月が経つまでに、目標は変化します。今日、私たちは設計に必要なすべてを正確に得るよりも、市場投入までの時間が非常に重要であることを知っています。
より優れた、より一貫した教育を受けたエンジニア。最近では、（できれば）ベストプラクティスを理解していて、設計ドキュメントに何をすべきかを指示することなく実装するエンジニアを雇うことができます。
TFSなどの生産性向上ツールを使用すると、ユースケースを参照し、あいまいな技術的決定に対していくつかの箇条書きを提供する簡単なタスクを作成できます。それ以上は必要ありません。開発者は、ツールを使用してすべてをレビュー、見積もり、コードレビューを取得、チェックインなどできます。これは、すべてを結び付けるので、外部ドキュメントでの作業よりもはるかに効率的です。
いくつかのことについてはまだ設計ドキュメントが必要です...たとえば、アプリケーションが異なるチームによって開発された異なるコンポーネントに分割されている場合、少なくとも、どのコンポーネントがどの要件に責任があるかを伝える必要があります。しかし、ほとんどの場合、今日の開発方法論は、開発者が不適切な意思決定を行うことから生じる可能性のあるリスクを管理および封じ込めるためのツールを提供しながら、はるかに自由を可能にします。
いいえと主張します。
単純な理由で
数年前の私を含む多くのIT担当者にとって、理想的なソフトウェア開発プロセスは、コード行が記述される前に、多くのUMLダイアグラムを含む詳細な設計ドキュメントを作成することです。
1990年代以降、Extreme Programmingが存在している のように、「理想的」とは考えられていませんでした。そしてあなたが言うように：
理想的なケースでは、コード自体を除いて、ソフトウェア設計の記述はありません。
何年も前に議論されました。たとえば、1992年のこの伝説的な記事： ソフトウェアデザインとは 。
上記は、複雑な言語やIDEを必要とせずに、高度に進化したアーキテクチャと反復的なアプローチで「極端な」プロセスを実現できることを示しています。
代わりに、この「見かけ」は、多くの図やユースケースドキュメントを備えた設計の前線から、より進化的で反復的なアプローチへと変化します。動的な環境で、誰にとってもより「アジャイル」な環境で受け入れて作業する方がはるかに簡単です。
私はこれにかなり同意しますが、あなたが示唆するよりもずっと早く始まったと思います。また、表現力以外にも大きな要因があると思います。父が最初にプログラミングを始めたとき、彼はパンチカードを作成し、コンピューターで時間をスケジュールしなければなりませんでした。プログラムを実行するチャンスは1日に1回あるかもしれません。コードの作成を無駄にして失敗させ、修正するのに多くの時間はありませんでした。おそらく2つか3つのショットがあり、それが機能しない場合は問題が発生しています。
このリスクにより、プログラムの計画を立てるのに多くの時間を費やすことが重要でした。人々はコードを鉛筆で書き、それをパンチされたカードに転送します。テクノロジーが進歩するにつれ、端末に直接コーディングすることができましたが、それでも共有リソースを使用していて、CPUは高価でした。テストファーストの方法論は、その世界では完全に受け入れられないでしょう。事前に計画を立てていなかった場合、同僚はピッチフォークを使って机に向かいます。
コンピューティングリソースは、驚くほどのペースで、より安価でより良いものになっています。これらすべてのプラクティスが開発された制約の多くは完全に取り除かれています。 Euphoricが指摘するように、これからの移行は本当に90年代に始まりました。大きな先行設計の多くが続いているのは、純粋な慣性です。
そのため、はい、プログラミング言語の表現力の向上は、独自のドキュメンテーションとして表現力のあるコードを使用する方が簡単であるという単純な事実から、これに影響を与えました。コードが何を言っているかを伝えるドキュメントを作成するコストは非常に高く、その価値があります（あるレベルでは必然的に間違っています）。
そもそもデザインドキュメントの目的を忘れていると思います！
設計ドキュメント（要件、使用例、モックアップなど）により、システムを高レベルで記述、理解、および議論することができます。そのようなドキュメントの詳細の量省略は、それらを有用にするものです。
実際にはソースコード自体がこの目的を果たしているため、システムシステムの正確な動作をall詳細に記述したドキュメントを用意する必要はありません。
ソフトウェア開発は、人間が読み取れる高レベルの仕様を、マシンで実行可能な明確な低レベルの仕様に変換するプロセスと考えることができます。ただし、このプロセスにはinputが必要です。
理想的なケースでは、コード自体を除いて、ソフトウェア設計の記述はありません。
これはあなたが示唆するよりもはるかに離れています。依存型（私が理解しているように、理論的には非常に有望です）のようなものでさえ、数年後に使用されます。
正式な検証は非常に難しいため、正式な検証が一般的に使用される唯一の場所は暗号化ライブラリです。
ユニットテスト
プロパティテストが主流になっていなければ、これは長い間実用的ではないと思います。
さらに、適切なテスト（すべてのリファクタリングで編集する必要はないが、それでも十分なエラーをキャッチする）を書くことは非常に困難です。
コードがドキュメントと一致していることを確認するには、何度もチェックする必要があります。頻繁な変更がある場合、コードとドキュメントの同期を保つのは困難です。
現時点では、おそらくドキュメントテストツールを使用する方が簡単です。
この作業を行うための前提条件が1つあります。コードは、読んで理解するのに十分簡単でなければなりません。
残念ながら、非常に表現力があるだけでなく、非常に読みやすい言語を設計することは困難です。 Goなどの言語は読みやすさを優先し、より高度な思考を妨げます。
最後に、私の経験では、より優れた言語とツールは、バグの少ないソフトウェアではなく、より大きなプロジェクトにつながります。 pandocが1970年に書かれたであろうもっともらしい方法は実際にはありません。