最初の一連の要件と設計が完了したら、どこからプログラミングを開始しますか？（テストは同じ順序で記述されますが、コードの前に記述されると想定します）。
- エントリポイント
- フレームワーク/サポートクラス
- エンティティクラス
- 最初に最も簡単なこと
- 最初に最も難しいこと
何を指示してるんですか？
16 に答える
7
私は依存関係チェーンの最低レベルから最高レベルまで作業します。そうすれば、私は早い段階でコンパイルしてテストするものを手に入れることができ、それから私はそれを基に構築することができます。
于 2009-05-18T19:48:39.240 に答える
7
私はほとんどの場合、ユーザーインターフェイスから始めます。何が入ってくるのか、何が出るのかを正確に知ると、他のすべてを整理するのが簡単になります。
于 2009-05-18T19:54:21.943 に答える
5
データ構造（DBテーブル、XTD、データディクショナリなど）から始めます。次に、データが構造に出入りする方法（データアクセス層）次に、ビジネスオブジェクトとそれに関連するロジック最後に、ユーザーインターフェイスとそれらを添付します。私のビジネスロジックへのプログラムによるフック
于 2009-05-18T19:49:42.187 に答える
5
この質問への回答を投稿した人は誰でも、別の場所から始めるように名前を付けているようです。開始点の幅広いバリエーションは、実際に開始する必要がある場所、つまり理想的な開始点がどこにあるかを示す完璧な例です。
問題への取り組み方は人によって異なります。多くの場合、プロジェクトの成功は、最初のアプローチとは無関係です。時間をかけて考え、さまざまな分野を試して、最初に焦点を合わせ、自分に最適なものを見つけてください。
編集：より抽象的なレベルで、Paul Grahamによるこの記事は、プログラミングへのLispスタイルのボトムアップアプローチに関する優れた洞察を提供します。
于 2009-05-18T19:58:28.643 に答える
3
個人的には、ドメインモデルから始めるべきだと思います。これは、大部分、要件から直接引き出され、作成する必要のあるピースを特定するのに役立ちます。ドメインモデルはデータモデルを駆動し、要件はドメインオブジェクトに対して何をしなければならないかを教えてくれます。
于 2009-05-18T20:07:33.210 に答える
2
それはあなたが作成しているものに依存しなければなりません。私はWindowsモバイルアプリケーションに取り組んでおり、ボトムアップで作業を開始し、クラスやさまざまなデータ抽象化に取り組んでから、GUIですべてを接続しました。これは悪夢でした。人々（開発者以外）のコードを見せて、40％完了したことを彼らに納得させることはできません。彼らは、ある種のGUIを見る必要があります。戻ることができれば、最初にGUIをモックアップします。
しかし、データ駆動型のWebサイトに関しては、データを操作できるWebページは、データがどのように表示され、どのように操作できるかを知ることに依存しているため、データから始めます。
余談ですが、私は「最も簡単」で「最も難しい」ことに興味があります。なぜなら、人間の自然な傾向は、簡単なことは実際よりも簡単で、難しいことは実際よりも難しいと思うからです。
于 2009-05-18T19:53:57.620 に答える
2
UIを大まかに説明することから始めるのが好きです。
これにより、設計と要件がすべて間違っていた（全員が承認したとしても）ことについての議論がより迅速になり、多くの無駄な労力が節約されます。
ただし、これは少し危険です。ほとんどの人は、UIが作業の大部分であると想定しており、画面がほぼ完成したように見えるときに、終了に時間がかかる理由を理解できないためです。
于 2009-05-18T19:54:10.727 に答える
2
Re：イージーvsハードアイテムの優先順位：
私は最初に難しいアイテムになると思うことをやろうとします。このように問題が発生した場合、事前に通知を受け取る可能性が高くなります。また、何かが達成できないことが判明した場合でも、依存していて不要になったたくさんの小さなことに時間を無駄にすることはありません。
于 2009-05-18T20:35:42.980 に答える
1
私は最初にサポートするフレームワーククラスを作成してテストする傾向があります。そうしないと、コンパイルしてテストする前にコードを書きすぎてしまうことがわかります。また、最初にそれらを書くことは、それらを使用するコードにあまりにも熱心に結合されている中途半端なものではなく、完全な抽象化にする傾向があることを意味します。サポートクラスを作成するときに上位レベルのコードを作成していない場合は、誤って循環依存関係を導入することを回避できます。
とは言うものの、私がサポートクラスを書いているときは、少なくとも、上位レベルのコードでそれらがどのように使用されるかの例を示すコードのスニペットをすでに書いているでしょう。
于 2009-05-18T19:53:36.717 に答える
1
デスクトップ/コマンドラインプログラムを使用して、私は通常、Tedが提案したことを実行し、依存関係チェーン（ツリー）のトップ（ルート）から開始して、テストとコンパイルを早期に行うことができます。次に、チェーン（ツリー）を段階的に下（上）にクラスと複雑さを追加します。
Webアプリケーションでの作業では、通常、多少異なるアプローチを取ります。
- 私は、サイトがどのように見えるべきかについてのアイデアを与えるために、大まかなhtmlシェルを構築することから始める傾向があります。
- 次に、最も単純な機能（多くの場合、ゲストブックやブログのような入力/表示データのようなもの）から始めます。ここでは、データベースにテーブルを設定し、それをデータプロバイダー（Entity Frameworkの場合）にマップします。私は.Netにいます）、サイトにデータにアクセスしてもらいます（入力機能はまだありません！）。
- ページが正しくデータを取得しているとき（私はデータベースにランダムなものを手動で入れてテストします）、サイトのこのセクションの入力部分で作業を開始します。
- サイトの1つのセクション（ゲストブックなど）が完成し、希望どおりに機能したら、次の部分に進み、1からやり直します。
于 2009-05-18T19:58:57.940 に答える
1
開始するのに最適な場所は、データスキーマ、ドメインモデル、モデルとインターフェイス、インターフェイスの間のビジネスロジックです。
使用するテクノロジーと開発パラダイムに応じて、理想的には要件の大部分を表すため、コーディングの世界へのビジネス要件の自然な拡張として機能します。
実際、考慮する必要があるのは、構築しているもの、ソリューションの設計に使用したデザインパターン、使用されている関連テクノロジー、およびそれらがどのように相互に関連しているか（または関連していないか）、およびそれらの依存関係です。
制限要因である部分から始めます。データスキーマなしで適切なドメインモデルを構築できない場合は、スキーマから始めます。
かなりインテリジェントなデータベース（すべてのエラーチェックと検証を行うストアドプロシージャに組み込まれたすべてのテーブル、整合性、およびルール）があり、中間層（データを渡すだけ）の設計がかなり知られていない場合は、仕事と機能は後ろにあります...。
かなり単純なデータベース（テーブルとフィールドのみ）と非常にスマートな中間層（ここで行われるすべてのロジック、検証、および整合性チェック）がある場合...機能の大部分は中間にあります...
今では好みの問題です。私は進歩が好きなので、構築するのに「最も簡単な」もの、つまりアプリケーションの「最も単純な」部分から始めます。私にとって、これは私にとってコードレベルでプロセス全体を結晶化するのに役立ちます-比較的頻繁にピースが所定の位置に落ちるのを見ることができます。
しかし、私は常にまばゆいばかりのフロントエンドを最後まで残します（または私は他の誰かにそれをやらせます-私はそれを好みます）!!
それは科学であると同時に芸術でもあります...同じテクノロジーとプロセスでパターンを繰り返すだけでない限り、すべてのプロジェクトは異なります。その場合は、それを科学に落とし込み、レッスンを確実に取り除いてください。今後、より効率的なプロセスを構成できるように、各プロジェクト。
乾杯
于 2009-05-18T20:44:53.867 に答える
1
私は、より高いレベル（アーキテクチャ）の部分から始めることを好みます。それらは、より低いレベルで特に必要なものをより適切に定義するからです。あなたがより低いレベルから始めるならば、あなたは通常、あなたがより低いレベルが働くべきであるとあなたが決めた方法に合うようにより高いレベルをろくでなしにすることになります。つまり、本質的には、低いレベルから始めることで仕事が難しくなり、デザインが理解しにくくなります。より高いレベルのアプリケーションコードはあなたが理解しやすい部分なので、そこから始めて、それがあなたが望むように正確に機能することを確認することは私にとっても理にかなっています。
これは通常、UIから始めて、UIの構築時に機能を追加することを意味します。
編集：あなたが働いているより高いレベルで何かがどのように機能するのかわからない場合; 次に、その上位レベルのピースが呼び出して、作業を下位レベルのモジュールにプッシュするためのメソッドを作成します。これは私のコードを単純化する上で私にとって不思議です。
于 2009-05-18T21:04:49.303 に答える
0
可能な限り、アプリ全体のパスから始めます。スタブを惜しみなく使用してください。これは、プログラムの全体的なアーキテクチャを明確にするのに役立ちます。
それが終わったら、次に最も難しい部分に取り組むことを強くお勧めします。（最も難しい部分、つまり最も危険な部分、つまりあなたが最も情報を持っていない部分。）
なんで？不足している情報をすべて見つけるのに時間が必要であり、この部分を機能させることができない場合、他の部分は無駄になっています。
于 2009-05-18T20:31:12.227 に答える
0
これまでのところ、アプリケーションの最下位レベルであるデータレイヤーから開始し、そこから構築するという一般的なコンセンサスに同意します。ビジネスロジックはデータ層の上に構築され、フロントエンドはビジネスロジックなどの上に構築されるため、私にとっては完全に理にかなっています。
ただし、もう1つ、顧客について考えてみましょう。残念ながら、顧客はあなたが何かをしていることを知るために目に見える変化を見る必要があります。そして、技術管理者でさえこの考え方に陥る傾向があることに驚かれることでしょう。
そのため、各反復でUIにも何らかの処理が行われるようにし、ある意味でアプリケーションが垂直線で構築されるようにします。つまり、一部のデータ、一部のビジネスロジック、一部のUIが顧客に表示されます。繰り返す。
于 2009-05-18T20:03:24.747 に答える
0
私はフレームワークを書くことから始めて、それから他の部分を一緒に落とすのが好きです。
たとえば、私は通常、必要になることがわかっているクラスを作成し、必要な機能が得られたらそれをインターフェイスします...その後、周囲の機能に進みます。
私はこのように物事を行うのが好きです。なぜなら、意識の流れのように感じ、物事がクリックされたときにそれは非常に満足できるからです。
于 2009-05-18T20:53:40.433 に答える
0
ジャーニーマンプログラマーとしての私の見解：
- データ構造を計画する
- UIの大まかなバージョンを作成する
- アプリケーションロジックをコーディングする
- UIに最後の仕上げをする
Djangoアプリケーションを開発するときは、最初にモデルを定義し、適切なテンプレートをいくつかまとめてハックし、ビュー関数をコーディングして、UIの残りの作業を完了します。これらのすべての手順は必然的に少し重複します（ビューのコーディング中にモデルクラスに変更を加えるなど）が、これは私にとって一般的なロードマップになります。
于 2009-05-18T21:03:24.487 に答える