問題タブ [software-design]

会社は成長しており、ますます複雑なソフトウェア設計を実装し始めています。追跡ソフトウェアが必要だと感じています...存在するかどうかはわかりません。

私は現在、モジュールごとによく整理されたドキュメントを含む Google Doc フォルダ (3 人の開発者が共有) を維持しています。ドキュメントは、1 つまたは複数のモジュールへのメジャー アップグレードごとにも作成されます。他のすべての「追跡」については、内部フォーラムがあります。

次のものが必要です: 過去 X 日間に実装された開発者のコ​​メントを非表示または表示するオプションを使用して、Project_01 のすべての機能または特定のプロジェクトのバグ修正をすぐに印刷したい。

これは明らかに、開発者が問題、バグ、および機能を適切なタグ付けで入力する Web ベースのシステムを示唆しています。エントリはコメント可能、タグ付け可能、日付、編集可能である必要があり、レポートはタグ、日付、開発者、プロジェクトなどに基づいている必要があります。

私はこのビジネスを 4 年間運営してきましたが (だから私は周りにいました)、ここにいる白髪交じりの退役軍人から世間知らずだと思われると思います。CMMI のようなものを実装するためのオーバーヘッドを吸収するためのリソースが私たちにあるとは思いません。

アプリケーション モジュールごとに Google ドキュメントを使用し、その他すべてに内部の phpbb フォーラムを使用するという私の個人的な進化は、最初の方法 (マーカー ボード、Microsoft Word ドキュメント) と比較して非常に優れています。優れたオンデマンド レポートで機能/バグ/問題をより適切に追跡できれば、クライアントの期待をはるかに超えることができると感じています。

考え？

更新: MediaWiki を Mantis と統合しました

さて、ここで私が直面している問題があります。

アプリケーションに、データベース接続を必要とするメソッドを持つクラスがいくつかあります。クラスを設計する 2 つの異なる方法の間で迷っています。どちらも依存性注入を中心にしています。

1. メソッド呼び出しの前に呼び出し元によって設定される接続のプロパティを提供します。これにはいくつかの欠点があります。

   • 接続プロパティに依存するすべてのメソッドは、そのプロパティを検証して、それがnullではないこと、開いていること、および操作が台無しになる場合はトランザクションに関与していないことを確認する必要があります。

   • 接続プロパティが予期せず閉じられた場合、すべてのメソッドは (1.) 例外をスローするか、(2.) 強制的に開く必要があります。必要な堅牢性のレベルに応じて、どちらのケースも適切です。(これはメソッドに渡される接続とは異なることに注意してください。接続への参照は、メソッド呼び出しの存続期間だけではなく、オブジェクトの存続期間にわたって存在します。その結果、接続のボラティリティが高くなるように見えます。私に。）

   • プロパティを提供することは、（とにかく、私には）対応するプロパティConnectionを求めて叫ぶようです。Transactionこれにより、トランザクションがいつ使用され、いつ使用されないかを明確にする必要があるため、ドキュメントに追加のオーバーヘッドが生じます。

   一方、Microsoft は、セット アンド インボーク パラダイム全体を支持しているようです。

2. 接続を引数としてメソッドに渡す必要があります。これには、いくつかの利点と欠点があります。

   • パラメータリストは当然大きくなります。これは、主にコールの時点で、私にとって面倒です。

   • 接続 (およびトランザクション) は使用前に検証する必要がありますが、それへの参照はメソッド呼び出しの間のみ存在します。

   • ただし、要点は非常に明確です。接続を提供する必要があること、およびメソッドが背後で自動的に接続を作成しないことは明らかです。

   • メソッドがトランザクションを必要としない場合 (たとえば、データベースからデータを取得するだけのメソッド)、トランザクションは必要ありません。メソッド シグネチャによる明確さの欠如はありません。

   • メソッドがトランザクションを必要とする場合は、メソッド シグネチャにより非常に明確です。繰り返しますが、明確さの欠如はありません。

   • Connectionクラスはまたはプロパティを公開しないため、Transaction呼び出し元がそれらを介してプロパティやメソッドにドリルダウンしようとする可能性はなく、デメテルの法則が適用されます。

私は知っています、それはたくさんあります。しかし一方では、Microsoft の方法があります。プロパティを提供し、呼び出し元にプロパティを設定させてから、メソッドを呼び出します。そうすれば、複雑なコンストラクターやファクトリー メソッドなどを作成する必要がなくなります。また、多くの引数を持つメソッドは避けてください。

次に、オブジェクトでこれら 2 つのプロパティを公開すると、消費者がこれらのプロパティを悪用するのを助長する傾向があるという単純な事実があります。(私が責任を負っているわけではありませんが、それでもです。) しかし、私はただ、くだらないコードを書きたくないだけです。

あなたが私の立場だったら、どうしますか？

コードプラグイン/Priendliyを作成する方法を知りたいです。まあ言ってみれば ：

私はプログラムを持っており、ユーザーインターフェイスには、他の開発者がプラグインを提供できるアドオンセクションがありますが、自分のコードが他のコードと連携するように、このようなインターフェイスを設計するにはどうすればよいですか。想像できない:(

私は、最初にプロジェクト管理のウォーターフォール方式を採用し、それに伴い、ソフトウェア設計への予測的アプローチを採用したことを知っています。これは、ドキュメント、UML、データベース スキーマ、データ ディクショナリ、ワークフロー、アクティビティ図などの膨大なパケットがあったことを意味します。

ソフトウェアに 10 年以上携わってきた今、リアクティブなアプローチからソフトウェア設計にアプローチする方がはるかに現実的であることがわかりました。私は頻繁にプロジェクト管理にスクラム アプローチを採用していますが、そのため、重いドキュメントはほとんど生成されません。ワークフローの仕様はほとんどありません (ただし、まだ使用されています)。これは、ソフトウェア作成に対するより動的なアプローチです。もちろん、時間の経過とともに頻繁にリファクタリングが行われます。時間の経過とともに、事前に計画していれば状況が劇的に変化していたであろう新機能が見つかるからです。

私たちにとっての大きな違いは、最初のアプローチは時間がかかり、ソフトウェア構築の世界ではより頻繁に失敗するように思われ、柔軟性に欠けることです。2 番目のアプローチは柔軟性を高め、失敗をより早く認識できるようにし (コースをより速く修正できるようにします)、すべての反復の最後に何らかの形の機能を提供します。

経験から両方の側面を知っているので、ソフトウェア開発のアジャイル アプローチよりもウォーターフォール アプローチを好む人が今でも多くいます。理解できません。

質問:アジャイルを裏付けるすべての研究がある何らかの形式のアジャイルではなく、なぜウォーターフォールを使用するのでしょうか? アジャイルではなくウォーターフォールを使用することの有力な議論は何ですか?

プログラムのモジュールを分離して、相互に通信したいと考えています。それらは同じコンピューター上にある可能性がありますが、異なるコンピューター上にある可能性があります。

私は2つの方法を検討していました：

1. すべての詳細を含むクラスを作成します。それを通信層に送信します。これはそれをシリアル化して送信し、反対側はそれを逆シリアル化してクラスに戻し、さらに処理します。
2. ハッシュテーブル (キー/値のもの) を作成します。そこにすべてのデータを入れます。通信層などに送信する

したがって、ハッシュテーブルとクラスに要約されます。

「疎結合」だと思うなら、ハッシュテーブルを好みます。一方のモジュールを更新するのは簡単で、もう一方のモジュールを更新せずに、新しい追加パラメーターを hastable に含めます。

次に、クラスを使用して、実行時ではなくコンパイル時の型チェックを行います。

誰かが以前にこれに取り組み、これについて提案がありますか?

ありがとう！

編集：元の質問に最も関連する回答にポイントを与えましたが、最も支持された回答ではありません

私には2つのクラスがあります。SpeciesReaderファイルを取得して解析します。Speciesファイルから解析された種に関する特定のデータを格納します。

現在、私はメソッドを持っています：SpeciesReader.generateSpecies()、それはオブジェクトを作成するためにインスタンス化されたファイルを使用しSpeciesます。これは悪い習慣/デザインですか？Speciesファイル名を引数として取るコンストラクターにこれを移動する方法をどうにかして見つける必要がありますか？

readData()ファイルを読み取る関数があり、解析されたデータのいくつかの異なるオブジェクトを返します。現在、の戻りタイプreadData()は次のObject[]とおりです。

これはぎこちなく感じます。このデータを返すためのより良い方法はありますか？readGenome()のような個別の関数は必要ありませんreadSpecies()。ファイルを2回繰り返す必要があるためです。また、データの収集をすべて1つの関数にまとめたいと思います。

同様の問題：2つの文字列間で少なくとも4文字の一致を返す関数：

ここbounds[0][0]で、はg0の左境界、はg0bounds[0][1]の右境界、bounds[1][0]はg1の左境界などです。これも、ちょっと厄介な感じがします。キーを継続的に検索せずに結果をコーディングすることは困難です。

次の UI コンポーネントを含むアプリケーションがあります。

• メインメニュー
• フォルダ ツリー
• クエリビルダー
• タブ付きリスト (各タブには、データ エンティティを表示できるグリッドがあります)

アプリケーションは MVC に基づいているため、上記の各コンポーネントにはコントローラーとビューがあります。

最初の 3 つのコンポーネントは、データ エンティティをリストに (新しいタブとして) 表示する必要があります。

• フォルダをダブルクリックすると、フォルダの項目が新しいリストに表示されます。
• クエリビルダーの検索ボタンをクリックすると、検索結果が新しいタブで開きます。
• 「開く...」メニュー項目をクリックしてファイルを選択すると、ファイル内の項目を含む新しいタブが開きます。

多くのアイテムが存在する可能性があるため、データベースからそれらをロードするプロセスはグリッドによって非同期に行われます (グリッドは、見ているときに満たされます)。

私の質問は次のうちどれが「よりクリーンな」デザインですか? （より良い解決策があれば、とても感謝します）

私が持っている最初の解決策は、 EventAggregator を使用し、「ShowQuery」イベントを定義し、リストコントローラーをそれにサブスクライブさせ、他のコントローラーがクエリ結果を表示したいときにそれを公開することです。

もう 1 つのソリューションは Unity コンテナーのようなもので、他のコントローラーから "IListsController" インターフェイスを解決し、"ShowQuery" メソッドを呼び出します。

Alexander Stepanov や Sean Parent のような人々は、ソフトウェア設計に対する形式的で抽象的なアプローチに投票しています。
アイデアは、複雑なシステムを有向非循環グラフに分解し、その動作を表すノードに循環動作を隠すことです。
親はboost-conとgoogleでプレゼンテーションを行いました（boost-conのシート、p.24でアプローチを紹介、google talkの動画もあります）。

私はこのアプローチが好きで、必要な開発だと考えていますが、無定形の動作をするサブシステムをどのように処理するかを想像するのに問題があります。
たとえば、状態マシンの一般的なパターンを想像してみてください。すべての状態がサポートするインターフェイスを使用し、状態の具体的な実装で異なる動作をすることです。

どうすればそれを解決できますか？
私は抽象的なアプローチを探しているだけであることに注意してください。

その動作をノードの背後に隠し、状態ごとに異なるサブ DAG を定義することも考えられますが、サブ DAG からメイン DAG の動作に影響を与えたい場合、設計がかなり複雑になります。