7

私は機能仕様を書いたことはありません。コードに飛び込んで、物事を設計することを好みます。これまでのところ問題なく動作していますが、最近の個人的なプロジェクトのために、製品のすべての機能と、実装方法の詳細には触れずに「動作」する方法を説明する仕様をいくつか書いています。とても貴重だと思います。

あなたはどう思いますか?仕様を書きますか?それともコーディングを開始して計画を立てますか?どちらの方法が優れていますか?

4

11 に答える 11

13

自宅から最寄りの食料品店まで車で行く場合、地図はおそらく必要ありません。しかし...

別の州で行ったことのない場所に車で行く場合は、おそらくそうするでしょう。

運転の楽しみのためにランダムに運転している場合は、おそらく地図は必要ありません。しかし...

最も効果的な方法 (距離を最小限に抑える、時間を最小限に抑える、途中で特定の場所に 3 回立ち寄るなど) で目的地にたどり着こうとしている場合は、おそらくそうするでしょう。

一人で運転していて、興味のあるものを見つけたらいつでも立ち止まったり、目的地やルートを再検討したりして、好きなだけ運転できる場合は、地図は必要ないかもしれません. しかし...

車列の一部として運転していて、食事と宿泊施設を一緒に作る必要があり、一緒に到着する必要がある場合は、おそらくそうするでしょう。

私がプログラミングについて話しているのではないと思われる場合は、おそらく機能仕様、ストーリー カード、物語、CRC などは必要ありません。しかし...

私がそうだと思われる場合は、上記の少なくとも 1 つを検討することをお勧めします。

;-)

于 2009-01-03T15:35:39.633 に答える
11

「コードに飛び込む」「設計する」人にとって、機能仕様を含むものを書くことは、現在の方法よりも優れていると思います。始める前に時間をかけて考え、設計すれば、時間と労力を大幅に節約できます。

  • 要件は、作成する必要があるものを定義するのに役立ちます。
  • デザインは、あなたが作ることを計画しているものを定義するのに役立ちます。
  • ユーザードキュメントは、あなたが作成したものを定義します。

ほとんどの場所で、これら3つのドキュメントのバリエーションがいくつかあることがわかります。機能仕様は、設計ドキュメントにまとめることができます。

確信が持てない場合は、RapidDevelopmentを読むことをお勧めします。計画と設計により多くの時間をかけると、本当に作業をより速く行うことができます。

于 2009-01-03T15:11:55.810 に答える
5

大規模なソフトウェアプロジェクトで「コードにまっすぐ」ジャンプすると、ほぼ確実に失敗につながります（すぐに橋を架けるためにレンガのポーズを取り始めるように）。

37 Signalsの担当者は、複雑な仕様を書くよりも、紙に短い文書を書く方が良いと言うでしょう。これは、新しいWebサイト（デザインとアイデアが厳密なスキーマよりも優れている可能性がある）をすばやくモックアップする場合にも当てはまりますが、他の実際の状況では常に受け入れられるとは限りません。

顧客が署名した仕様書が持つ可能性のある（法的な、さらには）重要性について考えてみてください。

士気はおそらく次のとおりです。柔軟であり、プロジェクトのシナリオに応じて、必要なだけ機能的または技術的な仕様で計画します。

于 2009-01-03T15:16:21.840 に答える
4

1回限りのハックや小さなユーティリティの場合は、気にしないでください。

しかし、真面目で大規模なアプリケーションを作成していて、要求の厳しい顧客がいて、長時間実行する必要がある場合は、必須です。このテーマに関するジョエルの素晴らしい記事を読んでください-彼らは良いスタートです。

于 2009-01-03T15:12:51.970 に答える
3

私は両方の方法でそれを行いますが、テスト駆動開発から何かを学びました...

ロードマップを使用してコーディングを開始すると、途中でどのように分岐するかわからないまま道路を歩き始めた場合よりもはるかに速く、旅の終わりに到達します。

すべての関数が実行する内容の詳細をすべて書き留める必要はありませんが、すべてをうまく連携させるために何をすべきかがわかるように、基本を定義してください。

そうは言っても、昨日は一連の例外ハンドラーを作成する必要がありました。それを設計しようとせずに、すぐに飛び込みました。多分私は自分のアドバイスを読み直す必要があります;）

于 2009-01-03T15:07:41.263 に答える
3

多くの人が認めたり気づいたりしたくないのは、ソフトウェア開発は工学分野であるということです。彼らが物事にどのようにアプローチするかについて多くを学ぶことができます。アプリケーションで何をするかを計画することは、小さなプロジェクトでは必ずしも重要ではありません。通常、すぐに戻って間違いを修正する方が簡単だからです。システムが最初に実行することを書き留めるのに比べて、どれだけの時間が無駄になっているのかわかりません。

実際には、大規模なプロジェクトでは、システムがどのように機能し、何をするかについてのロードマップを用意する必要があります。必要に応じて機能仕様と呼びますが、通常は、ステップbがステップaに続く理由を示すことができるものが必要です。私たちは皆、その場でそれを考えることができると思います（私もこれについては間違いなく有罪です）が、実際にはそれは私たちに問題を引き起こします。振り返って、何回何かに遭遇したかを自問して、「もっと早く考えていたらよかったのに」と自分に言い聞かせました。または、他の誰かがあなたがやったことを見て、あなたが10をとったタスクを達成するために3つのステップを踏むことができることをあなたに示しました。

それを紙に書くことは本当にあなたにあなたが何をしようとしているのかについて考えることを強制します。それが紙に書かれると、それはもはや曖昧な考えではなくなり、それを見て、あなたが考えていたことが本当に理にかなっているかどうかを評価することができます。1ページのドキュメントを変更する方が、5000行のコードを変更するよりも簡単です。

于 2009-01-03T15:21:25.260 に答える
3

XP（または同様の）環境で作業している場合は、ストーリーを使用して、多くのユニットおよび廊下のユーザビリティテスト（クールエイドを飲んだと思います）とともに開発をガイドします。

ただし、仕様が絶対に必要な領域が1つあります。それは、外部チームと調整する場合です。私は大手保険会社とのプロジェクトで、特定のプログラムの動作、データベース設計のいくつかの側面、およびいくつかのファイルレイアウトについて合意する必要がありました。仕様がなければ、私は私たちが約束したことの創造的な解釈に広くオープンでした。これらは良い人たちでした-私は彼らを信頼し、彼らと一緒に働くのが好きでした。しかし、それでも、その仕様がなければ、それは死の行進だったでしょう。仕様を使用すると、合意されたレイアウトから逸脱した場所や、追加のカスタム作業（$$！）を要求している場所を常に指摘できました。半敵対的な関係で作業している場合、仕様はさらに悪いことからあなたを救うことができます：訴訟。

そうそう、私はKieveliに同意します。「コードへのジャンプ権」はほとんど決して良い考えではありません。

于 2009-01-03T15:26:43.393 に答える
1

問題の種類に完全に「依存」していると思います。私はそれのために、またはあなたの上の層のためにそれを書いているのかと自問する傾向があります。私もこれについて議論しました、そして私の個人的な経験は言う、それはプロジェクトを（コースから外れるのではなく）期待通りに軌道に乗せるのであなたはそうすべきです。

于 2009-01-03T15:17:52.600 に答える
0

私は、いくつかの理由から、コードに飛び込むよりも、重要な問題を最初に紙の上で大まかに分解するのが好きです。

  • 私が紙に書いたものは、コンパイルする必要はなく、コンピューターにとって意味をなさない
  • 紙の上で任意のレベルの抽象化で作業できる
  • 写真や図を簡単に追加できます
  • コンセプトを非常に迅速に検討し、デバッグすることができる

私が扱っている問題にかなりの時間がかかるか、他の多くの人が関与する可能性が高い場合は、機能仕様の概要として書きます。私がソフトウェアを開発するために他の誰かから支払われており、あいまいさの可能性がある場合は、このあいまいさを取り除くのに十分な詳細を追加します. また、ソフトウェアが作成されたら、自動化されたテスト ケースを開発するための出発点としてこのドキュメントを使用することも好きです。

別の言い方をすれば、自分で書いているソフトウェアを適切に理解し、関係する他の人のために可能性のあるあいまいさを解決するのに十分な機能仕様を書きます。

于 2009-01-03T16:46:17.213 に答える
-1

機能仕様の必要性を感じることはめったにありません。OTOH 私は常に機能を担当するユーザーに電話一本で対応しているので、いつでも機能要件について問い合わせることができます。

私にとって、機能仕様は技術的というよりも政治的なツールです。仕様を取得したら、後で実装の問題を発見した場合、いつでも仕様を非難できると思います。しかし、誰のせいにするかは私にはまったく興味がありません。スケープゴートを見つけたとしても、問題は依然としてそこにあります。それよりも、実装を再検討して正しく実行することをお勧めします。

良い仕様を書くことは事実上不可能です。なぜなら、それを正しく行うために、問題、ツール、または環境の将来の変更について十分に知らないからです。

したがって、アジャイルなアプローチを開発に適応させ、十分なリソースと時間を割いて再検討し、リファクタリングすることがはるかに重要だと思います。

于 2009-01-03T15:42:59.087 に答える
-5

それらを書かないことが重要です：機能仕様について機能的なものは何もありません

于 2009-01-03T15:06:43.980 に答える