プロジェクトが終わったときにアーキテクチャエラーが見えやすいのは相対性です。X はセキュリティ上の問題を引き起こし、Y は多くの余分な作業をもたらしました。これらはふりかえりでキャッチされますが、もっと早くキャッチされるとよいでしょう。
コーディングを開始する前に、アーキテクチャのレビューを実施する予定です。
1 つの方法は、アーキテクトにプロジェクトを提示してもらい、設計の欠陥を見つけられるかどうかを確認することです。
おそらく「考えたことはありますか」または「どのように行うつもりですか」チェックリストを使用して、より構造化されたアプローチを持っている人はいますか。
私は次のようなことを考えていました：
明らかに、このテーマに関する書籍は数多く出回っています (例えば、建築家が知っておくべき 97 の事柄)。ここで公理の包括的なリストを見つけることができます。チェックリストのプロジェクトにとって意味のある公理を厳選することをお勧めします。
変化は絶え間なく起こります。アーキテクチャが適応可能であることを確認してください。
ユーザー インターフェースは、ユーザー エクスペリエンスを向上させるものです。
アーキテクチャに関する知識をすべての人と完全に共有します。
実装する前に試してください。
デザインパターンを過度に使用しないでください。
リストに追加する追加アイテム。順不同。
よく知られたパターンを使用し、場合によってはアーキテクチャ フレームワークを使用して、what-if を減らす必要があります。
プロジェクトが終了すると、アーキテクチャ エラーが比較的簡単に見つかりますが、それは私たちが行っていることの性質にあります。
アーキテクチャのレビューを継続的に行うことは良い習慣だと思います。それはあなたが「完了する」だけのステップではありません。
重要なプロジェクトの場合、私たちが行うことの 1 つは、ソリューション オプションのドキュメントです。ブレーンストーミングを行い、既存の情報を収集し、中小企業と話し合い、必要な人と話し合い、長所、短所、大まかなコストと見積もりを含むさまざまなオプションの表を作成します. はい、この演習はオーバーヘッドですが、これを行うと、説明した問題の多くがわかります。
最後に、理由と、場合によってはソリューションを視覚化するための高レベルのアーキテクチャ図を使用して、管理者にソリューションを推奨します。