design-patterns - ソフトウェア ファクトリを実装するかどうかを決定するために使用した基準は何ですか?

Question

先日、同僚と、開発組織にソフトウェア ファクトリを実装することと、アクティブ レコードのような足場ソリューションを使用することの類似点について話し合っていました。大規模な開発者グループがいて、コード ベース内で一定レベルの一貫性と規則を維持したい場合、ソフトウェア ファクトリを実装することは良いアイデアであると考える人もいるかもしれないと私たちは考えました。

もう少し考えてみると、私はソフトウェア ファクトリを個人的に使用するというアイデアが本当に好きであることに気付きました。なぜなら、書くことで頭痛の種を大幅に節約できるので、楽しみのために取り組んでいるプロジェクトのコードを簡単に作成できるからです。 「ボイラープレート」コード。そうは言っても、大規模な組織でソフトウェア ファクトリの使用を強制すると、チーム内で争いが生じる可能性があると思います。一部の開発者は、それが創造力の侵害になると考える可能性があるからです。

そこで私が疑問に思っているのは (ファクトリを実装した組織の一員だった人から) 、組織内でファクトリを使用することを決定するためにどのような基準が必要になるかということです。 ?

Answer 1

SO の精神では、良いフレームワーク (Spring、Windsor、Active Record) と比較して、Software Factory から多くを得る組織は大小を問わず存在しません。

ソフトウェア ファクトリは、ファクトリを構築する人にとってのみ楽しいものであり、ファクトリのアナロジーは非常に適切です。SF 環境では、コーディングは反復的で退屈なものになる可能性があります。基本的には、チームに伝えているのですが、実際には愚かすぎてこれを理解できないので、間違いを犯さないようにします。耳障りに聞こえるかもしれませんが、それがうまくいく方法です（そして、私たちが試したとき、私は方程式の楽しい側にいました）。一貫性と慣習はあらゆる手段で促進できます (強制は嫌いです)。コード レビューは最善ですが、実行するのは困難です。コード分析 (FxCop など) は最悪ですが、基本をカバーしています。

SF アプローチのもう 1 つの問題は、工場が特定のニーズを満たしていない場合です。その場合、コーダーは失われます。何が起こっているのかについての概念モデルがないほど、基礎となる技術から隔離されています。これは、生産ラインのドローンにエンジンの製造を依頼するようなものです。彼らはどこから始めればよいかわかりません。一方、まともなメカニックは何をすべきか (またはどこに行くべきか) を知っています。不必要なファクトリー アプローチでチームを制限するのではなく、優れたツールでチームを強化する必要があります。