コーディングを始める前に、紙の上でソフトウェアを適切に設計し始めることに興味があります。これに対する標準的なアプローチは何ですか？
私はUMLに沿って何かを考えていますが、それは1人のプロジェクトにとっては少しやり過ぎだと感じています。
趣味のプロジェクトを開発するときに専門家がするのが最善だと言うことのいくつかは何ですか？
いつものように投票が終了することを期待して、これは議論の余地がありません。それは明確な答えであり、何かが確立されることを期待しています。：P
3242 次
13 に答える
6
私は通常、問題を2つの異なる問題に分割しようとします。
- 関係者（これはクラスの良い候補です）
- 何が起こっているのか（同様に、これは優れた方法である傾向があり、パフォーマンス要件を確立するために焦点を当てたいと思うかもしれません）。
例：可能な車のセットの中で最も安い車を検索するとき、後で条件を変更したり、SUVに次のように適用したりする可能性があるため、「最も安い」をおそらく別の機能にしたいものとして識別します。ええと、「車」と「車のセット」は、問題の領域で必要なクラスの良い候補のように聞こえます。
それらを確立するには：
- 問題の説明で動詞を検索します：それらはメソッドを作成します
- 問題の説明で名詞を検索します：それらはクラスを作ります
- 制約とそれらが何に関連するかを見つけてください：何かの特性が最も安いのか、それとも操作の結果なのか？
最終的に、私はそれらの関係をさらに描くことから、擬似コードと小さなプロトタイプに移り、問題の説明に他の未知の制約がどのように現れるかを試してみます。
于 2009-10-27T23:23:37.967 に答える
3
この種のことについては、私は通常、基本的なUIをスケッチし、ドメインモデルとデータベーススキーマをグラフ化します（紙のボックス）。私は常に紙から始め、必要だと感じたらvisio/basalmiqにエクスポートします。
于 2009-10-27T23:18:55.343 に答える
2
簡単なプログラムでは、紙と鉛筆を使用してUIのスケッチを描き、それにいくつかの注釈を付けます。自分の考えを明確にし、デザインを確認するのに役立ちます。
プログラムが大きい場合（つまり、完全な製品のように）、1人の人間の考えではすべてを網羅できないため、他の人からフィードバックを収集する必要がある場合があります。手描きのスケッチは引き続き機能します。より多くの人にレビューしてもらい、提案をしてもらうと、デザインを大幅に磨くことができます。ただし、友人がいない場合は、紙のスケッチをファックスで送信する必要があります（または、紙のスケッチをスキャンして電子メールで送信することもできます）。
UIプロトタイプの作成に役立つツールがいくつかあります。また、UIのシミュレーションを実行できるツール（AxareやForeUIなど）もあり、他のツールからのフィードバックを収集するのに非常に役立ちます。
于 2009-10-28T03:31:06.980 に答える
1
ジャケットのポケットの中にはミニメモ帳のようなものはありません。できるだけ早くダンプすることを念頭に置いて、私は個人的にミニUMLとドットポイントを切り替えます。すばやく、シンプルで、いつでもアクセスできます。
編集：そして、私は常に特定のユースケースとアクション専用のページ/エリアを持っています。これにより、戻ってきて、システムがこれらのそれぞれを処理できるかどうかを確認できます。
于 2009-10-27T23:17:22.817 に答える
1
それは主に物の数に依存し、最も重要なのはあなたが何を作っているかです。
1) 私にとっての最初のステップは、何を作っているかを宣言することです。サウンド、シンプル？時々そうではありません。プログラムに実行させたいことをリストアップします。なくてはならないもの、あると便利なもの、持っていてもよいものをリストアップします (含めるのはそれほど面倒ではありません)。
2) 2 番目のステップは、(最善を尽くして) プロジェクトの成功に対する最も弱いリンクを特定することです。WebDB を作成している場合、心配する必要があるのは、Web UI (ページから別のページへの遷移) とデータ モデルです。ゲームを書いているなら、ゲームのルールは重要です。または、ゲームが非常にインタラクティブな場合は、インタラクションをゲームの流れと考える必要があります。
ここで特定したことは、紙の上で時間をかけて設計する必要があることです。
それを特定するには経験が必要になる可能性が高く、経験がない可能性があるため (経験した場合は、何をすべきかが既にわかっているでしょう :-D)、プロジェクトの進行に合わせて、ときどき戻って確認することができます。
3) オーバーエンジニアリングを避けるために、ドキュメントとしてのモデル化ではなく、理解のためのモデル化に焦点を当てます。
4) 理解が深まったら、簡単なプログラムを作成して、可能かどうかを確認します。もしそうなら、他の重要だが危険な部分を特定してください。
5) 小さく始めますが、常に拡張について考えます。私にとって、大きなことを考えることは問題ありませんが、大きなことをするのは危険です。
それらは私がすることです。それがあなたにいくつかのアイデアを与えることを願っています。:-D
于 2009-10-27T23:54:06.190 に答える
1
私が UML を使用するのは、それが事実上の業界標準だからではなく、ドメイン (個人またはビジネス) を探索するときに考えを整理して文書化するのに役立つからです。無料のツールは ArgoUML です。
システムで何をしたいのかを理解して伝えるためのもう 1 つの助けとして、UI のモックを作成したいと思います。素晴らしい無料のものは Balsamiq Mockups です。
そして、最初に行動に注目し、最後にデータに注目します。Rebecca Wirfs-Brock の著作を参照してください。
頑張ってください！マーク
于 2009-11-04T16:05:33.250 に答える
0
私の「トリック」のいくつか：
私は最初にマインドマッピングを使用します（例：MindMeister）。
次に、「難しいスポット」の可能性を見つけて、軽量のプロトタイピングを行います
于 2009-10-27T23:17:26.123 に答える
0
最初に UI をスケッチすると、必要な機能を正確に見つけるのに非常に役立ちます。次に、各 UI 要素とその機能のリストを作成します。これが完了したら、通常、データベース スキーマを書き出します...
于 2009-10-27T23:29:27.970 に答える
0
これは私が物事を行う順序です：
1) 擬似コードを鉛筆で書きます。ここでは、必要に応じて自分自身や他のユーザーとアイデアをブレインストーミングできます。
2) 目的を概説するアルゴリズムと、それらの目的を達成する方法を書きます。
3) プロジェクトが小規模で単純でわかりやすい場合は、この手順を省略できます。または、アプリケーションのフローチャートを作成します。
4)最後に、アルゴリズムとフローチャートをガイドとして使用してコーディングを開始します。
于 2009-10-27T23:43:32.013 に答える
0
私は、SketchFlow を使用してワイヤーフレームとモックアップを作成することの大ファンです。これは、Web/デスクトップ アプリの設計プロセス全体に本当に役立ちます。見て触れて、アイデアが実際に機能することを証明できます。他の場所で言及されているマインド マッピング (MindMeister) も気に入っています。最近はBDUF（ビッグデザインアップフロント）仕様は極力避けてます！
于 2009-10-28T20:12:55.777 に答える
0
小さなコード プロジェクトの場合は、バージョン 0 をコーディングして、必要になると思われるすべてのクラスを作成し、それらを組み合わせて動作させることを好みます。その後、完全に停止して最初からやり直します。これにより、通常ははるかに優れたプロジェクトが作成されます。
于 2009-10-29T13:30:00.397 に答える
0
私の意見では、最終目標に固執する必要があります。ほとんどの場合、最終目標は、顧客、上司、同僚に結果を届けることです。
したがって、あなたがしなければならないことはすべて、目標と一致している必要があります。解放して届けます。
紙の上にデザインするのは良い考えではないと思います。実際、ほとんどのプロジェクトは遅すぎてコーディング フェーズに入ることができませんでした。多くの愚かなデザイナーや建築家が、数週間の作戦会議室に存在しなかった詳細について議論していました。彼らはプロジェクトを遅らせました。
実際には、テスト駆動開発についてもっと多くの考え方を学ぶべきです。それは、モードに完全に従わなければならないという意味ではなく、結果を出すために効果的に自分自身をコミットする方法を教えるための考え方です。
最後に、テスト駆動型は、顧客に質の高い結果を提供するというコミットメントを維持するための最も効果的な方法だと思います。
于 2009-10-28T00:31:54.190 に答える
0
ソフトウェアは創造的であり、問題を解決する方法に無限の可能性があるという点で芸術のようなものです。プログラマーとして、私たちは設計する前にコードに飛び込むことがよくあります。設計は、技術的なソリューションを検討する前に始まります。これらは、設計の範囲を制限するために最初に実行する必要があるいくつかの手順です。
- 目標を定義します。これらはあなた自身のものかもしれませんし、ビジネスマネージャー/プロダクトマネージャーからあなたに与えられたものかもしれません.
- リソースの制約を特定します。これは、時間、お金、ハードウェア、または使用できるプログラミング言語である可能性があります。
- ソフトウェアが属する業界または環境からの環境制約を調査します。たとえば、規制やユーザーが喜んで受け入れるものなどです。
- 将来を心配してください（ただし、気が狂ってはいけません）。できる限り、設計をソフトウェア レベルおよび機能レベルからスケーラブルにします。
- その後、反復を開始します。試してみて、デザインを繰り返し始めることが重要です。すべてを予測することはできませんので、最善を尽くしてから前進してください。
型破りな分野の例を使用してこれらをより詳細に説明するブログ投稿を書きましたが、ソフトウェアにもよく適用されます。
于 2015-06-05T13:25:11.330 に答える