這不是一個精確答案的問題(嚴格來說,答案最好通過一次民意調查獲得,但該功能不可用),但我真的對答案感興趣,因此無論如何我都會問。布朗菲爾德vs格林菲爾德發展?
在您的職業生涯中,您花了多少時間在greenfield開發項目上,而不是brownfield?
在過去的10年裏,我估計我已經在綠地上花了20%,在棕地上花了80%。這是典型的嗎?
這不是一個精確答案的問題(嚴格來說,答案最好通過一次民意調查獲得,但該功能不可用),但我真的對答案感興趣,因此無論如何我都會問。布朗菲爾德vs格林菲爾德發展?
在您的職業生涯中,您花了多少時間在greenfield開發項目上,而不是brownfield?
在過去的10年裏,我估計我已經在綠地上花了20%,在棕地上花了80%。這是典型的嗎?
我認爲與客戶打交道的專業人士在棕地開發上花費更多時間是很典型的。原因是客戶通常不願意拋棄他們現有的軟件來採用「最新最好」的(綠色)軟件。
然而,研究或學者的開發人員可能更有可能做綠地開發。初創公司也是如此。
我認爲你的比例20:80是很多/大多數開發者的代表。至於新的發展:如果你正在逐步構建軟件(Scrum,XP等),那麼你可能會爭辯說,你幾乎把所有的時間都花在了brownfield開發上。除了最初的迭代/探索工作,原型設計,甚至當你正在構建新的東西時,你已經在建立一個已建立的代碼庫,重構和擴展。那麼多少綠地開發實際上是綠色的?
在過去的十年左右,我一直在研究用作公司業務中心的軟件。 (既有SaaS又有軟件產品)。雖然我一直使用現有的系統(如此使用brownfield),但我們通常會進行徹底的重新設計/重寫(所以我們的綠地)。所以,要突破下:
所以,這似乎是與你相反。這是我找到的公司的性質,因此也是項目。我的軟件是我們公司的主要產品,這意味着我多年來一直在相同的代碼基礎上工作,通常是在從頭開始自己創建它之後。
我喜歡這樣。
通常這個問題不僅僅歸結爲棕地和綠地。在某些情況下,混合綠地/棕地方法是有效的機會。
我寫了一篇名爲「經典軟件錯誤:對於Greenfield或Refactor遺留代碼」的文章,它討論了這個確切的主題,並概述了一系列可能的組合,然後評估每個組合的後果。
http://stepaheadsoftware.blogspot.com.au/2012/09/greenfield-or-refactor-legacy-code-base.html
什麼可能有些人感到驚訝的是,非技術性的屬性,公司規模,將在戰略選擇和戰略成功的可能性大決定因素。