ソフトウェア開発者向けの10の推奨事項

統合ソフトウェアシステムの開発には、次のニーズのために大きな困難が伴います。

a）システムのラピッドプロトタイピング、

b）モデルとソースコードの品質を確保する。

c）システムの寿命中に変更を加える。



以下は、開発者が統合システムを作成するための困難な道のりに役立つ10の推奨事項です。





1.最新のソフトウェア開発プラットフォームの力を活用する



システムが起動した時点で古くなったり、時代遅れになりがちな開発プラットフォームに依存しないでください。



また、新しい言語とAPIを再学習する必要性を恐れないでください。 深刻なシステムには、開発者による適切なトレーニングが必要です。 より強力なツールとクラスライブラリを使用して、学習に費やした時間を返すだけではありません。 進行はまだ止まっていない...



2.アプリケーションの設計を真剣に考える



将来のシステムのアーキテクチャを作成することは、経験と直感の混合です。 システムの高品質モデルの作成を保証する一連のルールを選択することは困難です。 主なことは、システムのアーキテクチャの背景が主題領域を不自然に反映していないことです。



将来のプロジェクトの成功は、「今すぐやり直して、もしあればやり直し」というフレーズ（さらに悪いことに）と「この機能を後でブロックしたい」というフレーズによって間接的に判断できます。実現」（より多いほど良い）。 なんで？ 最初のケースでは、機能ブロックがどのように機能し、さらに「松葉杖」モードで機能するかについて明示的な仮定が行われたためです。 また、2番目のケースでは、特定の実装に関する決定は、どのように見えるべきかが明確になる段階まで延期されました。



3.オブジェクトドメインとユーザーインターフェイスの継承を使用する



継承を使用する場合、システムのオブジェクトのグループの一般的な動作を「1か所」で指定できます。



ドメインオブジェクトの場合、継承はオブジェクトの共通の属性と機能の定義に役立ちます。



ユーザーインターフェイスの場合、継承は、画面フォームの共通コンポーネント（勝つ場合でもWebフォームである場合でも）を定義するのに役立ちます。



表現の継承の例として、文書の抽象的なアーカイブ（つまりリスト）の形式を考えます。 ビジネスオブジェクトの継承の階層に従って、抽象ドキュメントには2つの定義済み属性「Number」と「DateDocument」があります。 文書の抽象的なアーカイブのフォームを描画し、その上に2つの列「Number」と「Date」を持つテーブル（「グリッド」）を配置します。 フォームの上部で、アーカイブの表示の深さ（ドキュメントの日付によるレコードの初期選択）を制御するコンポーネントを指定し、テーブルのコンテキストメニューのボタンを構成します。



次に、「Abstract Document」から継承される「Personnel Document」オブジェクトを定義します。 「番号」および「ドキュメント日付」フィールドに加えて、新しいオブジェクトには「従業員」フィールドがあります。 この場合、新しいアーカイブの画面フォームを「描く」必要はありません。 新しいアーカイブフォームのベースとして抽象アーカイブフォームを指定し、「Employee」列を既存のテーブルに追加して、この列をデータに関連付けます。 すべてのフォーム機能（表示深度など）は継承され、人事文書のアーカイブに自動的に実装されます。 開発時間の短縮は明らかです。



4.個別のアプリケーションビジネスロジックとユーザーインターフェイス



この条件の実現は、実際には、GUIとビジネスロジック間の相互作用の「契約」の出現を意味します。 同時に、システムに複数のユーザーインターフェイス（winやwebなど）を提供できるだけでなく、ビジネスロジッククラスの安全で理解可能なインターフェイスを実装することもできます。



この「契約」は、将来、システムモデルを大幅に変更するときに役立ちます。



5.システムは 、核爆発がモデル化されていない限り、相互作用するビジネスレベルのオブジェクトのセットである必要があります。



これは、ソフトウェア開発へのオブジェクト指向アプローチの基本原則です。 ドメインオブジェクトのクラスを作成し、それらにメッセージの交換を強制します（相互にパブリックメソッドを呼び出します）。 したがって、必要なシステム機能が実現されます。



たとえば、[OK]ボタンをクリックすると、編集されたオブジェクトを画面フォームのデータベースに保存する必要があります。 ボタンハンドラコードは次のようになります。



{

編集可能なオブジェクト保存（）;

}



Save（）メソッドには、オブジェクトの正確性に必要なすべてのチェックが含まれ、オブジェクトの対応するイベントを生成し、制御を保存パラメーターのデータベースのマネージャーに転送します。 つまり、表示フォームオブジェクトは、「保存」署名付きのメッセージを関連するビジネスオブジェクトに送信します。



そして、示された例で、オブジェクトの正確性の検証を画面フォームメソッドに渡すと、そのようなコードは将来制御するのが難しくなります。 特に、オブジェクトに複数の編集形式がある場合。



6.システムの機能をオブジェクト、コンポーネント、サブシステムにカプセル化する



明確に定義された機能を実現するために連携して機能するクラスのセットは、コンポーネントとカプセル化する必要があります。



将来、システムに変更を加えたときにインターフェイスが変更されない場合、残りのシステムコンポーネントに影響を与えることなく、コンポーネントの内部動作を完全に安全に作り直すことができます。 ただし、このような利点を実現するには、システムモデルで非常に真剣に取り組む必要があります（ヒント2を参照）。



7.明確で理解しやすい自然なインターフェースを使用して、アプリケーションのコンポーネントとサブシステム間の相互運用性を記述します。



インターフェイスは、システムコンポーネント間のリンクです。 インターフェイスの相互作用を変更しないコンポーネントの改善は、システム全体の動作に影響を与えず、システムの複雑な統合テストを必要としません。



したがって、開発者の主な目標は、システムのファイナライズのプロセスでできるだけ長く変更されないように、コンポーネントにそのようなインターフェースを提供することです。 このインターフェイスが明確で、理解可能でなく、自然ではない場合、非常に近い将来に変更される可能性が高くなります（ヒント2を参照）。



8.自動テストを作成して、システム機能が正しく実装されていることを確認します



自動テストは、開発者がコンポーネントが適切に機能しているかどうかを理解するのに役立ちます。 各テストスクリプトは、コンポーネントのインターフェイスの個別の要素をチェックする役割を果たします（いわゆる単体テスト）。 このようなテストを作成するために、NUnitのオープンソース開発があります。



テストは正と負に分けられます。 ポジティブテストの目的は、コンポーネントが正しい入力データセットで正しく機能するかどうかを調べることです。 ネガティブテストは、一連の無効な入力に対するコンポーネントの正しい応答を追跡します。 ご理解のとおり、両方のタイプのテストをコンポーネントテストドライバーで提示する必要があります。



場合によっては、コンポーネント自体の機能を開発する前に、コンポーネントのテストドライバーを作成することをお勧めします（ユースケースセット）。 これは、「正しい」コンポーネントインターフェイスを開発するのに役立ちます。



システムのテストドライバーのセットをテストケースを十分にカバーして記述できた場合、システムコードを変更する段階で多くの時間を節約できます。



9.自動コード生成用のツールを使用する



大規模なシステムでは、資格のある開発者が参加しなくても取得できるコードの割合は、自分で記述したり、既存のツールを使用して自動コード生成を行うのに十分です。



これにより、コードを記述する際に不必要なミスを防ぐことができ、システムの重要な機能の実装に集中できます。



10.データベースは目標ではなく、手段であることを忘れないでください



システムに使用するデータベースサーバーを選択するときは、システムと対話するコードの記述の容易さではなく、その安全性、操作の速度、データの安全性、その他のパラメーターを評価する必要があります。 少なくとも、DBMSとの対話操作を実行するための「ラッパー」を作成できますが、サーバー自体の動作を変更することはできません。



DBMSサーバーで操作を実行するために、ストアドプロシージャを記述する問題に取り組む必要もあります。 システムのすべてのビジネスロジックをストアドプロシージャの形式で記述することは意味がありません。 この場合、システム開発にオブジェクト指向のアプローチを効果的に使用できず、ローカルネットワーク上のコンピューター間で計算能力を分散できません。 ストアドプロシージャでは、大量のデータを含む本当に「重い」処理のみを行うのが理にかなっています。