概念実証の銃撃戦を行うための最良の方法は何ですか？
当社が維持しているソフトウェアの新しいリリースに備えて、スケーラビリティの問題を解決するための本当に良いアプローチであると私が信じていることに取り組んできました。私は、紙のデザインが実際に私が望むことを実行することを検証するために、概念実証をまとめるつもりです。私がチームにそれを説明したとき、上司は私が問題領域を説明した方法に部分的に触発された反対の提案をしました。上司は、代替案を評価するために2つの概念実証を行うという私の提案も受け入れました。
では、概念実証のシュートアウトを実行するための最良の方法は何ですか？ソリューションの評価に使用している客観的基準と主観的基準の両方があります。これらのかなり異なるアプローチで、アップルとアップルを比較していることを確認したいと思います。
- スループットとサイズの要件があります。つまり、1秒あたりに特定の数のオブジェクトを処理し、その速度を1時間維持する必要があることがわかっています。
- スケーラビリティを評価する必要があります（コアを追加することとオブジェクトの数を増やすことの両方によって）
- 開発のしやすさを評価する必要があります（主観的）
- アルゴリズムを理解するのがどれほど簡単かを評価する必要があります（主観的）
私は物事がどちらの方向に傾くかについての私の理論を持っていますが、それが私の結果に影響を与えたくありません。このプロセスで客観性を維持する方法についてのご意見、および私が考慮する必要があるかもしれないことは大歓迎です。
一般的に私たちがしていることは...
- 1か月のような期限を設定します
- リストした要件を使用して、コード化します。
どちらのプログラムも作成していないモデレーターが要件を制御し、短時間で実行できるはずの隠れた要件について考えていない人がいます。
チームの他のメンバーがプログラムを調べて評価するときは、各システムに要件を追加して、両方の感触をつかむ必要があります。チームがコードを掘り下げて不足している要件を追加した後、コードベースについて合理的な感覚を持ち、どちらから開発したいかを選択する必要があります。
- 次に、「敗者」の残りの最良の部分を取り、それらを勝利のアーキテクチャに組み込みます。
このプロセスで客観性を維持する方法
客観的な基準は1つだけです。スループット。
すべてが主観的です。あなたは「客観的」になることはできません。あなたにできることは「公正」であることだけです。違いの世界。
最終決定は常に政治的です。利用可能なすべての情報が提供されている限り、あなたはあなたができるすべてをしました。
完璧な（「客観的な」）ポイントを作ろうとすることを強調しないでください。 「チームには提案されたソリューションに必要なスキルがない」などのばかげた言い訳によって、あなたが正しいまたは最善と見なすものが単に覆される可能性があります。
デモを作成するだけです。それらを実行します。ランダムな意思決定に備えてください。あなたが望むことができる最高のものは情報に基づいたと公正なです。簡単に「目的」に到達することはできません。
主観的な項目については、ある程度の数値評価を考え出し、偏りのないフィードバックを得ようとします。例：「アルゴリズムを理解する」の場合、どちらも書かなかったプログラマーが両方を見て、お互いにランク付けします。
コード「複雑さ」のようなコードの客観的な測定値を考慮に入れることもできます。制御ステートメントの数などに基づいてそれを測定するためのツールがいくつかあります。
各カテゴリのランキングを取得し、各アプローチの「合計スコア」に合計します。