您用什麼標準來確定是否實施軟件工廠？

Question

我前幾天正在和一位同事討論爲您的開發組織實施軟件工廠的相似之處，而不是像使用更多的活動記錄這樣的腳手架解決方案。我們都認爲，當你有一大批開發人員並且希望在代碼庫中保持一定程度的一致性和約定時，實施軟件工廠可能被某些人認爲是一個好主意。

再想一想，我意識到我非常喜歡軟件工廠供個人使用的想法，因爲它們讓我更容易地編寫我工作的項目，因爲它們爲我節省了很多時間頭疼的書面「樣板」代碼。話雖如此，我敢打賭，在較大的組織中強制使用軟件工廠可能會導致團隊內部發生衝突，因爲一些開發人員可能認爲這會對他們的創造能力造成侵害。

所以，我想知道（從你們誰已經已經實現工廠組織的一部分）是什麼標準則需決定在組織內部使用的工廠，當風險可能是一羣不開心的開發者？

Answer 1

我建議這取決於你的工廠正在生產。肯定有許多「陳詞濫調」代碼的例子，它們的生產可以被自動化，使得開發團隊可以將他們的創造力集中在真正需要人類智能的代碼部分。

用回調或其他擴展點組織構建的構件也很重要（也是完全可能的！關鍵是要確保開發者能夠看到你的工作是支持他們，而不是他們替代他們。

以上意思是你（和你的團隊）將會是強迫做更多的前期規劃，以最小的摩擦達到協調，「我們忘記了，我們也需要......「事件。這可能會產生一些抱怨。但是，如果你做得對，你就可以在某個時候加強工作，通過調整工廠來處理一些外部需求，而不會中斷他們自己的工作。此時，他們中的更多人應該開始將你視爲盟友。

Answer 2

本着SO的精神，恕我直言，沒有哪個組織可以從軟件工廠中獲得更多的利益，相比於良好的框架（Spring，Windsor，Active Record）。

軟件工廠對於那些打造工廠的人來說只是一件有趣的事，工廠的比喻非常適合。在SF環境中，編碼可能會變得重複和無聊，你實質上是在告訴你的團隊，順便說一句，你實在太愚蠢了，所以我們要確保你不會犯任何錯誤。我知道這聽起來很刺耳，但這就是它的表現方式（當然，當我們嘗試時，我在這個方程式的有趣一面）。一致性和慣例可以通過各種手段來加以實施（我討厭強制執行），代碼審查是最好的，但很難做到，代碼分析（FxCop等）是最糟糕的，但它們確實涵蓋了基礎知識。

SF方法的另一個問題是，當工廠不滿足特定需求時，那麼編碼器會丟失，他們已經與基礎技術隔離，以至於他們沒有關於發生什麼事情的概念模型上。這就像要求生產線無人機建造引擎，他們不知道從哪裏開始。另一方面，一個體面的機械師會知道該怎麼做（或去哪裏）。你應該用強大的工具賦予你的團隊力量，而不是用不必要的工廠方法來限制他們。