オープンソースのECMとやり取りするために、新しいフレームワークの設計と開発を開始する必要があります。これには、このECMと対話するWebサイト開発者を支援するカスタマイズされたデータモデルが含まれているため、ノード操作の詳細やその他の低レベルの詳細を気にする必要はありません。これは、開発するクラスとメソッドの集まりです。

そのプロジェクトの組織と管理をどのように扱うかについて、いくつかの疑問があります。従うべき一般的なルール、ヒント、ベストプラクティス、またはこの種のプロジェクトを開発する際に留意すべき点はありますか？

フレームワークまたはライブラリの開発とアプリケーションの開発には多少の違いがあると確信しています。

最初に、フレームワーク廃棄症候群を回避するための2つのルールを示します。

• 既存のものがないため、私のニーズの80％をカバーし、最後の20％に合わせて拡張可能
• 別のアプリケーションで再び使用するというほぼ確実性

それらに合格したら、これをチェックしてください：

• http://www.slideshare.net/brada/framework-design-guidelines-presentation
• http://www.informit.com/podcasts/episode.aspx?e=5a161893-c1ce-4449-8b67-31baa54ce316
• http://www.marlabsblogs.com/?tag=microsoft-framework-design-guidelines

1）機能は、作業コードから抽出された場合にのみフレームワークに追加する必要があります。言い換えれば、クールな新しいフレームワークにクールな新しいアイデアを追加する前に、実際に動作するアプリケーションの繰り返しを減らし、実際に価値を高めていることを確認してください。

2）ドキュメント、ドキュメント、ドキュメント。

3）ドキュメント、ドキュメント、ドキュメント。

痛みを伴う経験と多くの無駄な努力がこのアドバイスにつながります。動作中のソフトウェアからフレームワークを抽出またはリファクタリングします。将来フレームワークを抽出したいと思うが、最初にフレームワークを構築しないことを念頭に置いて、ソフトウェアを構築してください。

本フレームワークデザインガイドラインを提案します。それは数年前ですが、原則は変わりません。たくさんのパターンがあり、フレームワークを構築するときに行う決定の背後にある理由を説明しています。

1）最初から適切な規則に固執し、非常に具体的な規則を文書化したことを確認します。最良のフレームワークは、内部的に一貫したものです。

2）優れたコードコメントから、最も重要な関数が必要とするものを説明するまで、すべてが高度に文書化されていることを確認します。ちょうどその1つが必要です。

3）フレームワークで何を達成したいのか、現実的な目標と全体的な優先順位を付けて、プロジェクト概要を自分で説明します。

4）使用できるようになる場合は、何らかの形でサポートプロセス/バグトラッキングを実施していることを確認してください。バグが発生しますが、それは私たち全員に起こりますが、もしあなたがそれらをオフから管理できるなら、それはあなたの人生を楽にします。

全体として、アプリケーションを構築するための同様のアプローチですが、開発者はユーザーよりもはるかに面倒であり、最高のフレームワークは、私たちが理解し、理解し、戦う必要がないものです。

私は言われたことの多くに同意せず、もっと言及されていないように感じているので、最初から始めます。

アジャイル手法

フレームワークの開発中にアジャイル手法を採用して、変化に適応し、障害物に迅速に対応し、機能的で高品質の最終製品を確保できるようにします。アジャイル方法論とは、「アジャイル宣言」によると、優先順位を付けるものです。

個人との相互作用を超えるプロセスとツール
ソフトウェアを作業する上で包括的なドキュメントの
カスタマーコラボレーションを超える契約交渉
に変更への対応を超える計画以下

そのとおり。機能性はドキュメントよりも重要だと言いました。「アジャイルマニフェスト」では、右側の優先順位が依然として重要であり、左側の優先順位よりも重要性が低いことに言及していることに注意してください。

コミュニケーション

フレームワークを作成している人は誰でも知る必要があります：

1. 使用方法：ターゲットアプリケーション
2. 解決しようとしている問題：ターゲットの問題
3. 誰がそれを使用するのか：対象読者

たとえば、ASP .NETを使用して最終アプリケーションを開発しようとする企業の場合、上記のことを伝えずにプログラマに「このフレームワークを作成する」と伝えるのは愚かなことです。プログラマがターゲットアプリケーションを知らなかった場合、Web指向にしないかもしれません。問題を知らなかった場合、別の目的のためのフレームワークを作成する可能性があります。視聴者がわからない場合は、C ++でフレームワークをプログラミングできます。これらの状況では、結果のフレームワークが役に立たなくなります。

スタイル

言うまでもなく、プログラミングスタイル/フォーマットを確立し、それに固執します。

Eの

1. モジュール性：文字通りではなく、プログラムでコードを再利用します。
2. 効率性：コードは再利用を目的としています。速度を損なうものは増えます。
3. 保守性：フレームワークを編集して、複数のプログラムを更新できますが、これらのプログラムを変更する必要はありません。
4. 使いやすさ：アプリケーションは実際にフレームワークを使用できますか？
5. 実用性：必要がない場合は、車輪を再発明しないでください。フレームワークは他のフレームワークに依存できます。
6. 冗長性：例外/エラーをキャッチします。どこにでも。それらを処理します。どこにでも。たとえ知っているとしても、エラーを処理するためにローカルスコープ内のコード以外は絶対に信用しないでください。

フレームワークまたはライブラリの開発とアプリケーションの開発には多少の違いがあると確信しています。

開発プロセスは基本的に同じです。違いはマーケティングと展開の問題に帰着するかもしれませんが、最大の違いは通常プロジェクトの範囲と定義の点にあると思います。アプリケーションにはフレームワークまたはライブラリが含まれるか、使用される場合があり、フレームワークはライブラリのコレクションである場合があることに注意してください。

そのプロジェクトの組織と管理をどのように扱うかについて、いくつかの疑問があります。従うべき一般的なルール、ヒント、ベストプラクティス、またはこの種のプロジェクトを開発する際に留意すべき点はありますか？

プロジェクトの組織と管理は、どの開発プロジェクトでも同じです。繰り返しますが、それはスコープになります。ただし、フレームワークの作成に関しては、達成しようとしていることについて非常に明確なビジョンを持ち、APIのプレゼンテーションに関して一貫性を確保するために、フレームワークへのパブリックインターフェイスに厳格な設計ルールを設定することが重要です。すべての開発者が独自のことを行えるようにすると、複雑な混乱と非常に洗練されていないAPIデザインになります。

この本自体は.NETベースのフレームワークの開発を目的としているにもかかわらず、フレームワーク設計ガイドラインを読むように2番目のRyan Hayesの勧告を行います。

経験から、最も単純なパブリックインターフェイスを最初に実装し、次に拡張してより深い制御と深さを提供することにより、古典的なYAGNI原則に固執することをお勧めしますが、メソッドまたはクラスが拡張されている理由を示すために有用な名前を使用するよう注意してください。メソッド名に「Ex」などのサフィックスを追加したり、拡張されたインターフェイス定義に数字を追加したりすることは、これまで好きではありませんでした。機能を差別化すると、インターフェイス/メソッドの名前が明確になり、わかりにくくなり、わかりにくくなるはずです。