4

ある程度の開発経験はありますが、API や大規模なプロジェクトの設計はまだ行っていません。

私の一般的なプロセスには、通常、次のようなものが含まれます。

  1. いくつかの提案されたデザインを考え出します。
  2. それらの長所と短所を挙げてください。
  3. 一連のシナリオ (X の変更、新機能の追加など) が与えられた場合、設計はそれにどのように反応するか。

これが私の「スタイル」です。そのようなことを行うための正式なプロセスと方法論について、どこでもっと読むことができるのでしょうか? （オンライン、書籍など）

4

3 に答える 3

4

Framework Design Guidelinesは、このための優れた本です。また、.NET Framework Standard Library Annotated Referenceも素晴らしい本です。

これが私が従ったプリンシパルのいくつかです：

  • Less is more : 機能を取り除くと、学習する概念が少なくなるため、ユーザーの生産性がより速く向上します。少ないほど多くのことにつながります...
  • 参入障壁が低い: ユーザーは、新しいフレームワーク/API の基本を非常に迅速に習得することを期待しています。彼らは、ドキュメントを読むことではなく、実験によって学びたいと考えています。ほとんどの場合、機能が特に興味深い場合、または基本的なシナリオを超えて移動する場合にのみ、機能を完全に理解するのに時間がかかります
  • 型名は名詞句にする必要があります。これらはシステムのエンティティを表します。名前もシナリオを表す必要があります。最も一般的に使用される型には、最も簡単に認識される名前を使用する必要があります。FDG の本に示されている例はとであり、は最も簡単に認識できますが、概念をよりよく説明しています。それは...PrinterPrintQueuePrinterPrintQueue
  • 概念ではなく、抽象化に集中してください。使用される例は、File.NET の基本クラスと派生しNtfsFileた . ほとんどの開発者は自動的に をインスタンス化しようとしますがFile、それが であることを発見するだけabstractです。このような継承は実装ではうまく機能しますが...
  • フレームワークの設計は OO の設計と同じではありません。たとえば、.NET にはオブジェクトの階層があります。Stream、、、、、および。StreamReader_ TextReader_ 明確な階層がありますが、ファイルの読み取りなど、シナリオを考えると混乱します。StringReaderFileStream
  • アセンブリは、パッケージ化と展開の境界を表します。ベスト プラクティス (とにかく .NET の場合) では、通常、名前空間はアセンブリと一致する必要MyCompany.MyTechnology.dllがあります。たとえば、名前空間MyCompany.MyTechnologyとMyCompany.MyTechnology.MyFeature. これは、必ずしもフレームワーク/API に適用できるわけではありません。ここでのアセンブリは、開発者向けの論理グループを表し、パフォーマンス (読み込み時間)、簡単な展開、および簡単なバージョン管理を可能にする必要があります。これはバランスをとる行為です。1 つだけで十分な場合に、複数のアセンブリを参照することを好む人はいません。また、アセンブリが大きすぎて論理的なグループ化が不十分な場合、必要のないものに依存することを好む人はいません (たとえば、API で使用している機能が ADFS とは関係なくても、ADFS に追加の依存関係を取らなければならないなど)。 ）。
于 2012-05-15T17:47:13.030 に答える
3

The Clean Coder、C# の Agile Principles、Patters、および Practices、そして最後に Robert C. Martin によって書かれた Clean Code という本が好きです。私は彼の書き方が好きで、彼のコーディング スタイルが好きで、プログラマーとしての自分のプロとしてのキャリアについて考え、適用することがたくさんありました。これらの本はすべて、Amazon でかなり安く手に入れることができます。また、Robert C. Martin は、この種のものに関する彼自身の Web サイトを持っています。http://www.objectmentor.com/omTeam/martin_r.htmlこれは、「私たちのチームについて」の部分で彼を特集している Web サイトです。彼の別のウェブサイトと、彼が作成した Fitnesse というプログラムが見つからないか調べてみてください。

あなたのスタイルは、愛好家が大規模に行う傾向がある通常のサイズのプロジェクトには適していますが、さらにいくつかの手順が必要になる場合があります. どのオンライン サービスについて執筆を考えていましたか? 現在、Zoho 用にもう 1 つ作成していますが、作業中のコードをプログラムにインポートするのを忘れがちです。

于 2012-05-10T21:29:45.020 に答える
1

作業中のプロジェクトの 1 つの API を書き終えたところですが、いくつかポイントがあります。

方法論は原則として優れていますが、要件について考えてください。複数の開発者が API の進行と保守を進めますか? それとも、主に開発を担当しますか? 前者の場合、アーキテクチャの構造化された方法論とプロセスは、将来 (恐ろしいが避けられない) 変更が発生したときに利益をもたらします。

後者の場合は、柔軟性があります。すべての API は、プラグイン フレームワークであろうと、サービスへの「パブリック」エントリ ポイントであろうと、異なる何かを達成しようとしています。いくつかの要件を収集し、いずれかの方法論に従うことが有益かどうかを判断することをお勧めします。

于 2012-05-11T07:15:20.950 に答える