新しいフレームワークを構築するための一般的なルールやベストプラクティスはありますか？
オープンソースのECMとやり取りする新しいフレームワークの設計と開発を開始する必要があります。これには、このECMと対話するWebサイト開発者を支援するためにカスタマイズされたデータモデルが含まれているため、ノード操作の詳細やその他の低レベルの詳細を気にする必要はありません。これは、開発するクラスとメソッドの集まりにすぎません。
そのプロジェクトの組織と管理をどのように処理するかについて、いくつか疑問があります。この種のプロジェクトを開発するために留意すべき一般的なルール、ヒント、ベストプラクティスなどはありますか？
フレームワークまたはライブラリの開発とアプリケーションの間にいくつかの違いがあると確信しています。
最初に、フレームワーク廃棄物症候群を回避するための2つのルールを示します。
- 既存のものがないため、私のニーズの80％をカバーし、過去20％に合わせて拡張可能
- 別のアプリケーションで再び使用することはほぼ確実
それらをパスしたら、これをチェックしてください：
1）機能は、機能しているコードから抽出された場合にのみフレームワークに追加する必要があります。言い換えれば、クールな新しいアイデアをクールな新しいフレームワークに追加する前に、実際のアプリケーションで実際に価値を高め、繰り返しを減らすことを確認してください。
2）ドキュメント、ドキュメント、ドキュメント。
3）ドキュメント、ドキュメント、ドキュメント。
苦痛な経験と多くの無駄な努力がこのアドバイスにつながります：作業中のソフトウェアからフレームワークを抽出またはリファクタリングします。将来的にフレームワークを抽出したいと思うが、最初にフレームワークをビルドしないことを念頭に置いて、そのソフトウェアをビルドしてください。
本 Framework Design Guidelines をお勧めします。それは数年前ですが、原則は真実のままです。これにはたくさんのパターンがあり、フレームワークを構築するときに行う決定の背後にある理由を説明します。
1）最初から適切な規則に従ってください。非常に具体的な規則を文書化していることを確認してください。最適なフレームワークは、内部的に一貫しているものです。
2）優れたコードコメントから、最も重要な関数が必要とするものの説明まで、すべてが高度に文書化されていることを確認してください。ちょうど必要そのときのこと。
3）フレームワークで達成したいこと、現実的な目標、および全体的な優先順位を含めて、プロジェクトの概要を自分で説明します。
4）人々が利用できるようになる場合は、何らかの形でサポートプロセス/バグ追跡を実施していることを確認してください。バグが発生する可能性がありますが、それは私たち全員に起こりますが、それらを最初から管理できれば、生活が楽になります。
全体として、アプリケーションを構築するための同様のアプローチですが、開発者はユーザーよりもうるさく、最良のフレームワークは、私たちが選択し、理解できるものであり、戦う必要はありません。
私は言われたことの多くに同意しません、そして、もっと多くが言及されずに残されたと思うので、私はゼロから始めます。
アジャイル手法
フレームワーク開発中にアジャイル手法を採用することで、変化に適応し、ロードブロッキングに迅速に対応し、機能的で高品質の最終製品を確保できます。アジャイル方法論は、「アジャイル宣言」に従って、次のことを優先するものです。
個人と相互作用overプロセスとツール
実用的なソフトウェアover包括的なドキュメント
顧客コラボレーションover契約交渉
計画に従って変更overに対応
そのとおり。ドキュメントよりも機能の方が重要だと私は言いました。 「アジャイルマニフェスト」では、右側の優先順位が依然として重要であり、左側の優先順位よりも重要であることに言及していることに注意してください。
コミュニケーション
フレームワークを作成している人は誰でも知っておく必要があります。
- 使用方法：ターゲットアプリケーション
- 解決しようとしている問題：ターゲットの問題
- 誰が使用するか：対象読者
たとえば、企業がASP .NETを使用して最終的なアプリケーションを開発するつもりである場合、プログラマに上記のことを言わずに「このフレームワークを作成する」と伝えるのは愚かです。プログラマがそうしなかった場合ターゲットアプリケーションを知らないため、Web指向にしない可能性があります。問題を知らない場合は、別の目的のためのフレームワークを作成する可能性があります。対象ユーザーを知らない場合は、C++でフレームワークをプログラミングする可能性があります。これらの状況では、結果のフレームワークが役に立たなくなります。
スタイル
言うまでもなく、プログラミングスタイル/フォーマットを確立し、それに固執します。
Eの
- Modularity：文字通りではなく、プログラムでコードを再利用します。
- 効率：コードは再利用を目的としています。スピードを損なうことは、何倍にもなります。
- Maintainability：複数のプログラムを更新するために、フレームワークを編集して、それらのプログラムを変更する必要がないようにする必要があります。
- 使いやすさ：フープを飛び越えることなく、アプリケーションで実際にフレームワークを使用できますか？
- 実用性：必要がない場合は、ホイールを再発明しないでください。フレームワークは他のフレームワークに依存できます。
- 冗長性：例外/エラーをキャッチします。どこにでも。それらを処理します。どこにでも。エラーを処理するためにローカルスコープのコード以外は信頼しないでください。
フレームワークまたはライブラリの開発とアプリケーションの間にいくつかの違いがあると確信しています。
開発プロセスは基本的に同じです。違いは、マーケティングと展開の問題に帰着する可能性がありますが、最大の違いは、通常、プロジェクトの範囲と定義に関するものであることがわかります。アプリケーションにはフレームワークまたはライブラリが含まれている、または使用されている場合があります。フレームワークはライブラリのコレクションである場合があります。
そのプロジェクトの組織と管理をどのように処理するかについて、いくつか疑問があります。この種のプロジェクトを開発する際に守るべきいくつかの一般的なルール、ヒント、ベストプラクティスなどはありますか？
プロジェクトの編成と管理は、どの開発プロジェクトでも同じです。再びそれは範囲に行き着きます。ただし、フレームワークの作成に関しては、達成しようとしていることについて非常に明確なビジョンを持ち、フレームワークへのパブリックインターフェイスに厳密なデザインルールを設定して、APIの表示に関して一貫性を確保する必要があります。すべての開発者が独自のことを行えるようにすると、複雑な混乱と非常に洗練されていないAPI設計になってしまいます。
ライアンヘイズ の推奨事項 を2番目に読みます フレームワーク設計ガイドライン この本自体は.NETベースのフレームワークの開発を目的としていますが、一般的なアドバイスは、使用する特定の実装テクノロジーに関係なく適用できるためです。
経験から、私は最初に最も単純なパブリックインターフェースを実装し、次に拡張してより優れた制御と深さを提供することにより、従来のYAGNI原則に忠実に従うことをお勧めしますが、メソッドまたはクラスが拡張されている理由を示すために有用な名前を使用するように注意してください。メソッド名に「Ex」またはその他の同様のサフィックスを追加したり、拡張されたインターフェース定義に番号を追加したりするのは好きではありません。機能を差別化すると、インターフェース/メソッドの名前がより明確になり、できれば難読化や混乱が少なくなるはずです。