需求的頻繁變化是否導致意大利麪代碼？

Question

如果需求經常變化，並且您希望及時交付代碼，那麼用於克服意大利麪的最佳解決方案或方法是什麼？

Answer 1

你對意大利麪代碼的定義是什麼？對我來說，意大利麪代碼是一個太長，非結構化和混亂的方法/功能。這並不是由於需求的變化而發生的，而是由於開發者的懶惰。如果你必須重寫一個方法，因爲事情已經改變了，你也可以直接清理它，而不需要太多的開銷。

如果您的意思是設計不好的對象結構，那麼您可以對。如果需求變化太快，那麼您將很容易就會遇到不再按照他們的意圖實現的類，不良對象層次結構等等。

有一些的竅門，以避免這種情況：

• 在開始的時候，不要過度設計。儘量保持您的方法，類和類層次結構儘可能簡單，以減少更改難度。

• 的要求改變後，不要開始實施它的權利的話，但後退一步，看看是否需要改變你的代碼結構中的新功能可以適應了。

• 溝通，你的客戶端，這種改變需要一些時間。如果您知道他們知道更改需求也意味着您的代碼結構發生了變化，那麼將代碼壓入現有結構的壓力會更小。

• 編碼時總是重構。根據我的經驗，將冗餘代碼從多個地方移動到單個方法或類中的小重構對於保持代碼清潔最有效。始終注意代碼氣味，並儘可能快地移除它們，以使您的工作更輕鬆。這需要一些經驗，但現在是開始訓練的合適時間:-)

• 就像krosenvold說的那樣，通過在代碼中添加測試用例來安全地發揮它的作用，以消除對重大變化的恐懼。我自己在一個大型遺留系統上工作，我知道這種恐懼感和沒有安全網的感覺。當你首先在你的安全網上工作時，變得不那麼冒險去做必要的改變。

Answer 2

我認爲其中一個關鍵點是編寫易於改變的代碼。這通常有利於具體而不是摘要。還有一些設計模式傾向於通過代碼構建非常大的支柱。這些支柱傾向於在錯誤的地方發生變化，因爲您害怕改變代碼中那些重要的核心部分，您應該改變。

測試覆蓋率是一個真正的好幫手，可以讓你做無畏的重構。這是降低瘋狂和理智的測試飛行員之間的差異的降落傘。

Answer 3

良好的測試覆蓋率是防止頻繁更改的最佳防禦措施。

Answer 4

餐飲頻繁的需求變更是以下的目的：

• 面向對象的設計（抽象業務領域，並拆分爲可管理的宗旨面向概念）
• 設計模式（再利用建立的編碼方案）基於MVC的開發（數據分離，業務邏輯和視圖/演示）
• 基於體系結構的開發（在提交任何特定項目之前先設計一個體繫結構框架設計和開發）

所以，如果你想避免意大利麪，學習和應用上述概念。

Answer 5

對於任何需求，請設計您的代碼以獲得最大可能的更改。這可以通過將可變部分與可變部分分開來完成。這在開發之前不會花費太多時間。意大利麪代碼大多數時間出現，因爲需求發生變化，您的設計和編程應該能夠承受。

http://www.dreamsongs.org/Files/DesignBeyondHumanAbilitiesSimp.pdf將是有幫助的。

Answer 6

1. 預期的變化，如果/當你可以了，更重要的是推廣，如果可能的
2. 的要求，預期變化的工作/功能/迭代之間
3. 大塊的時間，使他們能夠在完成更改時間
4. 瞧！你現在正在做敏捷的飛行和不斷變化似乎正常8-P
5. 服用阿司匹林，在哀鳴老闆，循環回＃1 ;-)

Answer 7

頻繁更改項目的要求，包括增加或刪除功能，不必必然導致意大利麪代碼，但它可能會，如果你不寫模塊化軟件（見Modular Programming）。爭取的東西包括以下內容：

• 每個模塊（無論它是一個函數，類，庫或完整的應用程序）具有良好限定的目的。
• 理想情況下，每個模塊不大於它需要爲以服務其定義的目的。
• 模塊是鬆散耦合，這意味着它們可以替代其他模塊而不會導致軟件中斷。
• 模塊可以是單獨測試驗證他們爲他們的目的沒有錯誤。
• 模塊是有組織的方式，有助於使問題域直觀的其他程序員。

給定組織良好的模塊（同樣，這些模塊可以是函數，類，庫和完整應用程序），它們在鬆散耦合的情況下一起工作，處理需求變化的方法是編寫新模塊，展開在現有的模塊上，並以新的方式連接模塊。

至於你如何到達首先有這些好軟件模塊的情況，refactoring是關鍵。其他做法如unit testing和開發方法（如Scrum）也很有幫助，但重構是您的麪包和黃油 - 而許多商業環境都沒有足夠的時間來完成重構。

對於編寫鬆散耦合代碼的好建議，請在dependency injection上進行一些研究。

Answer 8

範圍蔓延/壞的需求分析（千變萬化）：

避免像瘟疫是一個可以給你保證任何質量（代碼或其他方式）的最好的建議，它總是會產生負面影響（在所有無論您嘗試計劃您的開發項目的程度如何。

最好的解決方案是設置里程碑並知道何時向誰顯示this link誰不斷變化的要求。

你可以在你的方法中超人類思維，儘可能容易地改變代碼，但是如果你只是對所有的功能說yes而不理解應該如何影響項目的質量 - 時間範圍金字塔。

Answer 9

經常變化的需求是一個敏捷方法需要處理的問題 - 它們的創建至少部分是因爲需要更改的需求，通常是因爲很好的原因。

如果需求發生變化，但尚未實現，那麼如果不在前期設計中投入太多精力，而是通過小型迭代，持續測試和重構來管理設計演變，則影響應該很小。

如果已經實施的要求發生變化，並且無法移動完成日期，那麼您有三種選擇：工作時間更長以恢復丟失的時間，降低要求（縮小範圍）以支付額外的工作，或降低產品的質量（這可能是「意大利麪條」選項「）

Answer 10

如果您正在使用一個忠告離開。！重構，重構，重構通常

其他的都是關於細節使重構更容易