フレームワーク作成の経験

私はかなり長い間、カスタム会計システムを開発している会社で働いています。 ほぼ同じ時間、テクノロジー部門があります。チームは、仲間のためにツールとフレームワークを開発し、顧客向けのシステムをすでに作成しています。 簡単に言えば、私たち（技術者）は、独自のORMを使用してビジネスロジックを記述するプロセスを統一し、コードジェネレーターを備えたUMLエディターでデザイナーとプログラマーを結び付け、エンドアプリケーションのユーザーが生産的に作業できるようにするさまざまなUIコントロールを提供します。

この記事では、技術層を作成するプロセスに関する私の経験を共有したいと思います。

なぜフレームワークが必要なのですか？

会社に直接利益をもたらさない人が何人かいるのにはいくつかの理由があります。ここでは、私の意見では最も重要なことです。

1.アイデアとコードの再利用。 テクノロジー部門は、さまざまなプロジェクトが完了したときにベストプラクティスを収集し、それらをすべてのチームに適用します。 この場合、隣人で何が新しくて有用であるかを知るために、お互いの接続を調整する必要はありません。 結局のところ、隣人は技術者とすぐに共有でき、普遍化についてあまり気にせず、技術者は他のすべての人に通知する機会があります（技術製品の次のバージョンに含まれる改善のリストは定期的に生成されます）。

2.決定の統一。 プログラマーは時々仕事を変えます。 このような状況のネガティブな側面に対処するために、この技術は典型的な問題を解決するためのいくつかの統一された方法を提供します。 したがって、自転車の数が減り、新しい人がプロジェクトに参加する時間が短縮されます。

成長のポイントまたは成長するテクノロジー

新しい技術的方向性をどのように明らかにしているかについて少し説明します。 使用されるプラットフォームは時々変更されるため、これらの新製品のテクノロジーを作成する必要があります。

幼稚園

当社の製品は完全なアプリケーションではないため、プロトタイププロジェクト（1〜3個）のサブジェクトエリアが最初に選択されます。 このアプリケーションは、実装を計画しているソリューションとアプローチを検証するだけです。 楽しみのために、私たちが最後に使用したこのようなシステムは、飼い猫をアパートに飼うためのものでした。 プロトタイプの特徴は、コードがかなり混合されており、技術層がどこにあり、適用されたロジックがどこからすでに開始されているかが明確でないことです。 この「猫」プロジェクトでは、必要なすべてのコンポーネント、ジェネレーター、ユーザーインターフェイス要素が作成されています。 技術者のみがプロジェクトに取り組んでいます。

学校の時間

技術をもっと深刻なものにしようとするときが来たら、「犠牲」プロジェクトが商業プロジェクトから選ばれます。 原則として、通常のプロジェクトよりも1.5-2倍長い期間を開発用に確保できます（誰もがリスクがあることを理解しています。なぜなら、私たちは初めてテクノロジーを使用し、会社自身が技術的な仕事にお金を払うからです。顧客）。 このようなプロジェクトの特徴は、技術コードが最初はソリューションにあり、開発されると、技術プロジェクトとアプリケーションコード（サブジェクトエリアに依存）に分割されることです。 技術者と応用プログラマの両方がプロジェクトに取り組んでいます。 基本的なアプローチはまだデバッグ中であり、テクノロジーのすべてが100％準備が整っているわけではないことを理解しておく必要があります。 時々、これらの「自転車」は標準的な技術的ソリューションに置き換えられ、時には最後まで残ることがあります。

高等教育

この段階では、この技術は広く使用できる状態にあると考えています。 通常の「動作モード」に入ります。 応用開発者は、もはや技術者からの直接の支援を必要としません。 技術アセンブリはコンパイルされた形式で提供されます。 ファイナライズタスクとエラーメッセージはTFSテクノロジープロジェクトに転送されます。

専門能力開発

時々、技術の大幅な改良が必要です。これは、原則として、一般的なレポートサブシステム、認可サブシステム、ロギングサブシステムなどの機能を追加することです。...機能駆動開発のようなものを使用しようとします。目標は、必要な機能を完全に実装することです。ユーザーの場合、すでに完成した形式で表示されます。 原則として、そのような革新は、積極的に開発されているすべてのプロジェクトですぐに要求されます。 面白いのは、別の機能の開発の最後に、応用プログラマーが来て、まさにそれを実装するように頼むことです。

引退

新しい方向性が発展するにつれて、古い方向性は次第に無駄になります。 プロジェクトは閉鎖されており、サポートを必要とするプロジェクトのユニットがあります。 それらと一緒に、テクノロジーは「廃止」され、バグ駆動型開発モードに入ります。 新しい機能は追加されなくなり、長年にわたって蓄積された古いバグを修正するだけです。 技術に変更を加えることはもはや実用的ではないため、アプリケーションプロジェクトの松葉杖によって修正されるバグもあります。 技術の変更は、それに依存するすべてのプロジェクトを常に念頭に置いて行う必要があります。 1つの間違った動きと問題は、アプリケーションプロジェクトに携わる人々、および彼らと技術者の両方に保証されます。

それでも何かを書き換える必要がある場合は、プロジェクトで多くのオカレンスがあるテクノロジーの場合：

•古い機能が満たした要件を収集します（原則として、一連の改善と小さな修正の後、プログラマーは完全で最新のドキュメントを持っていません）

•作業を計画します（もう一度予算を検討し、実行可能性を評価します）

•条件を修正するテストを作成します。 私たちは彼らから、以前に働いていたものが壊れないことを決定します。

•機能を作成します

•品質と規定の要件への準拠を確認します

問題の技術面

テクニックとテクニックについて少し説明します。 ソリューションはこのプラットフォーム上に構築されているため、Microsoft .NET Frameworkが対象となります。

拡張ポイント

このテクノロジーはプログラマーを制限するものではなく、ゼロからのソリューション、時には完全なターンキーソリューションよりも有利です。 プログラマーが技術が「あまりにも標準的」であるという彼の個性を示すために、次のアプローチを使用します。

•継承。 標準動作を実装する基本クラスがあり、技術アセンブリにあります。 アプリケーションプロジェクト用に生成されたコードは基本クラスから継承され、特別な方法では標準の動作を変更する必要があります。

•イベント。 テクノロジークラスには一連のイベントが含まれ、その処理により動作を変更できます。 イベントは何度もサブスクライブできることに注意してください。

•デリゲート。 イベントに似ていますが、実装は1つだけです。 これにより、不要な操作が何度も防止されます。

•App.config。 構成ファイルにはさまざまな小さなものが入ります。 原則として、これらはいくつかのフラグとパスです（デバッグ情報、サービスへの接続文字列などを記述する必要があるかどうか）。

•DI。 このオプションには、モジュール全体のオーバーライドが含まれます。

イベントログ

テクノロジーレイヤーからは、ユーザーインターフェイスへの通常のアクセスはほとんどありません。 原則として、何かがうまくいかなかった場合、これはテクノロジー（はい、存在し、私たちはそれを理解しています）またはアプリケーションコード（理想的な場合、アプリケーションプログラマーに彼が間違っていることを明示的に伝えることができます）のエラーを示しますそして、どこに）。 いずれにせよ、何らかの形でこれを知らせる必要があります。 Log4netを使用します。 技術的なメッセージを強調するには、別のロガーを使用するか、技術のエラーレベル（警告など）を修正します。

XMLコメント

プロセスコード内のXMLコメントは重要です。 パブリッククラス、メソッド、およびプロパティに対してそれらを規定する必要があります。 これにより、ヘルプ（http://sandcastle.codeplex.com/）が生成され、IntelliSenseのおかげでアプリケーションプロジェクトのヒントが提供されます。 プロジェクト設定で、コメント付きのxmlファイルを生成するかどうかを示すことを忘れないでください。

重大な変更

このようなテクノロジーの変更は非常にまれであり、アプリケーションプログラマーが介入してテクノロジーレイヤーを更新する必要があります。 そのような更新が予測できる場合は、たとえば、Obsolete属性を使用して事前に警告する必要があります。

[廃止（「この関数は次のバージョンで削除されます。関数を使用してください」））

リードをたどって、「更新を2回行うよりも1回追加する方が良い」というルールを適用する必要がある場合があります。 メソッドシグネチャが各アプリケーションプロジェクトの1000か所で使用されている場合、テクノロジで変更することはお勧めできません。 最も重要なルール：更新時に発生する可能性のある問題の常に詳細な説明-警告してから武装します。

ドキュメンテーション

技術的なアセンブリの場合、ドキュメントの可用性は非常に重要です。 情報を保存するには、技術者からの書き込みアクセス権を持つWikiエンジンを使用します。 情報を最新の状態に保つために、2つのルールが適用されます。

1.完了-Wikiに書き込みます！

2.質問に答えました-Wikiに書いてください！

説明レベル：

1.自分で

2.適用プロジェクトのプログラマー向け（メソッドとクラスの使用方法）

3.システムユーザーの場合（コンポーネントの使用方法）

フレームワークプロジェクトの構造

プロジェクトに対して発行されるアセンブリの数を最小限に抑えることが必要な場合があります。 これにより、複数のアセンブリを一度に更新する必要がある場合に誤った更新に対処できます。そうしないと、何かが機能せず、顧客が何かをインストールするのを忘れるリスクを最小限に抑えることができます。 ただし、プロジェクトごとにわずかに異なる機能が必要です。 適用できるもの

1.プロジェクト間のcsファイルへのリンク（プロジェクトの操作は少し複雑です）

2. ILMerge（これはビルドサーバーに割り当てることができますが、デバッグは困難です）

3.リソース内のアセンブリ（個別のアセンブリ読み込みメカニズムを使用）

署名アセンブリまたは厳密な名前

別の鉄則：すべての技術的アセンブリに署名する必要があります。 これにより、次の利点が得られます。

1.署名済みアセンブリはGACで一意に識別されます

2.すべての依存アセンブリが署名されている場合のみ署名できます（プロセスアセンブリが署名されていない場合、アプリケーションアセンブリは署名できません）

3.ある程度の保護（コードを変更するには、すべてのアプリケーションアセンブリを再構築する必要があります）

アセンブリのコードが失われた場合は、アセンブリを再構築することで署名できます。 再構築は次の方法で実行されます（キーを持つファイルを指定するには、特別なパラメーターを探します）。

1. ildasm.exe sampleA.exe / source /out:sampleA.il

2. ilasm.exe sampleA.il / exe /out:sampleA.exe

バージョン管理戦略

製品が頻繁にリリースされるほど、プログラマーは何もしないとユーザーに思われなくなります。 技術製品バージョンのリリースの2つのバージョンをテストしました。

1.最新のビルドが最高です

SourceControlに配置されるものはすべて実績のあるものと見なされ、アプリケーションプログラマーは技術的なアセンブリのサーバービルドを取ることができます。 同時に、技術者は各チェックインの前に変更を慎重に確認する必要があります。

長所：

•即時変更の投稿

短所：

•チェックインごとに、さまざまな機能が影響を受ける可能性のある拡張チェックが必要です。

•エラーは顧客のバージョンに簡単に侵入する可能性があります

2.安定版の定期的なリリース

定期的な技術アセンブリのバージョンのリリース。

長所：

•より信頼性の高い統合検証

短所：

•反復の途中でコードの制御を失うリスクがあります

•すぐに修正することなく、すべてを再度チェックするのに時間がかかります

1-2日バージョンのリリース中、発見されたエラーをチェックして修正することで、すべての技術者は気を散らされます。 これは現在使用しているオプションです。

アセンブリバージョン

ビルドバージョンの命名には2つの戦略があります。

1.変更可能なビルドバージョン

•プロジェクトの再コンパイルでのみ適用されたプロジェクトを更新する（技術のパッチを直接顧客に送信できない）

•問題の一部はコンパイル中に表示されます（アセンブリ間の複雑な依存関係に関連）

•型のシリアル化の問題（顧客に保存されたシリアル化されたデータは、アセンブリバージョンの更新時に問題を引き起こす可能性があります）

2.修正されたビルドバージョン

•アセンブリの単純な置換を更新する

•起動時に問題が表示されるのは、 アップグレード中の再コンパイルは不要です

•最終手段として、固定アセンブリのみを顧客に送信できます。

•識別のための条件付きバージョンとしてのアセンブリのリリース日

私たちのチームは2番目のオプションに決めました 多くの場合、適用されたプロジェクトで新しい技術アセンブリを確認する必要があり、それらを再コンパイルする必要も時間もありません。 Team Foundation Serverでサーバービルドを構成しました。サーバービルドのみを実装用に転送できます。

分岐：長所と短所

ソースコードストレージを整理するための2つのアプローチを検討しました。

機能を追加するためのブランチ、実装のためのブランチ

プラス：

•希望するバージョンに直接小さな変更を加えることができます

マイナス：

•多くのコードマージを行う必要がある

ブランチなしの単一バージョン

プラス：

•マージなし

マイナス：

•逆アセンブルされたバージョンを迅速に修復することはできません。

より単純な2番目のオプションに決めました。 チェックインなしで長期的な変更を行わないようにしますが、チェックインはソリューションのパフォーマンスを損なわないはずです。

外部アセンブリ

商用製品のOpenSourceについて一言：必要に応じて、希望するタスクを解決するための優れたライセンスを持つOpenSourceソリューションを見つけることができます。 ただし、そのような決定を行うときは、そこでどのように変更が行われるかをよく考える必要があります。

1.すべてをローカルで編集する

プラス：

•何でもできます

マイナス：

•公式バージョンを更新するときは、自分で変更をマージする必要があります

2.プロジェクトサポートチームに更新を送信する

プラス：

•修正の追加の品質チェック

短所：

•サポートが終了するリスク

•M. b。 長いチェックとリリースの修正

•修正は何らかの理由で拒否される場合があります。

変更を行うポリシー（少なくともエラーを修正する）が、お金が支払われるライセンスで修正されるため、有料ソリューションを選択する必要がある場合があります。

難読化

アプリケーションアセンブリとプロセスアセンブリの両方から利用可能なコードを分解から保護する方法は？

プロジェクトに移行する前に技術アセンブリを難読化できますが、次のようになります。

プラス：

•応用プログラマーは、技術的なコードにこだわることなく、これについて愚かな質問をすることはありません。

短所：

•アプリケーション開発者向けの複雑なデバッグ

•開発中に不安定になる可能性

•難読化と検証は2回実行されます

2番目のオプションは、完全に完成したアプリケーションをすべての技術アセンブリで難読化することです。

長所：

•アプリケーションのビルド段階での難読化

•フレームワークコードを入力してアプリケーションをデバッグする機能アプリケーションの動作の検証は1回実行されます

マイナス：

•アプリケーションプログラマーがテクノロジーアセンブリを保護

後者のオプションを適用します。

テスト中

単体テストについてはお話ししません。技術的なものだけでなく、どの層でもこれが必要です。 ただし、パフォーマンス要件を考慮して技術コードを常に記述し、マルチスレッドモードで問題なく動作する必要があります。

技術プロジェクトのテストは、原則として、主題分野を説明する最終アプリケーションなしでは不可能です。 場合によっては、エラーが隠されている場所を正確に理解するために、独自のアプリケーションを作成し、必要な条件を繰り返す必要があります。 このオプションのみが、アプリケーションコードから「ヒント」を分離するのに役立ちます。

おわりに

テクノロジーの研究は非常に魅力的で、ある場所では面白い職業であることに気付くことができます。 主なことは、あまり夢中にならず、時にはエンドユーザーとコミュニケーションを取り、ニーズを理解しようとすることです。 最後までこの長い独白を読んでくれたみんなに感謝します。