我有幾個編程工作。每個人有20-50個開發者，項目持續3 - 5年。這些年來有沒有辦法避免意大利麪代碼？
每一次都是一樣的。有些程序員很聰明，有些是平均的。每個人都有自己的CS學位，每個人都閱讀設計模式意圖是好的，人們正在努力編寫好的代碼，但是在幾年之後代碼變成意大利麪。模塊A中的更改突然中斷了模塊B.除了寫它的人之外，總是有這些代碼部分是人們無法理解的。改變基礎設施是不可能的，向後兼容性問題阻礙了很好的功能進入。有一半時間你只是想從頭開始重寫所有的東西。
而且比我更有經驗的人認爲這是正常的。是嗎？它必須是？我能做些什麼來避免這種情況，或者我應該接受它作爲生活的事實嗎？
編輯：夥計們，我對這裏回覆的數量和質量印象深刻。這個網站和它的社區搖滾！
無情的努力結合不斷的單元測試是防止意大利麪代碼的唯一方法。即使這樣，它只是一個創可貼的解決方案。一旦你停止注意出來的意大利麪。
很多時候，我發現意大利麪條代碼被引入，因爲那天有人只是簡單的懶惰。他們知道有更好的方式去做，而沒有時間。當你看到發生這種情況時，只有一件事要做。
叫出來就可以了，讓他們去改變它
我發現一個代碼審查中指出了更好的辦法通常是足夠讓人們去。如果他們檢查並強烈感受，我會自己重構它。
偶爾會有點偏心嗎？我確定我是。坦率地說，雖然我不介意。我不是一個混蛋，並以最好的社交方式來解決這個問題。但是，讓錯誤代碼檢查幾乎可以確保我將來必須在某個時刻對其進行調試。我寧願現在採取一點小故障，並得到正確的代碼。
我也覺得單元測試的文化也有助於防止意大利麪代碼。單元測試代碼良好的代碼是很困難的。隨着時間的推移，這迫使人們保持其代碼的有些因素。
我真的很喜歡你的建議。爲了幻想僱用一個特殊的人到一個只有工作職責將會檢查委託代碼並將其發佈出去的團隊。也許這是一個很好的做法。 – 2008-12-15 21:43:54
20到50位開發人員可能是這個問題。這是相當高的，並需要大量的管理和資源來控制一切。
我會考慮將項目拆分成更小的可重用部分。抽象出遠離核心系統的某些層。
那麼，這些案例需要20-50名開發人員，因爲這個項目相對較大。由於公司沒有其他產品，模塊的重複使用不是真實的。 Blackbox模塊測試很難，因爲您必須模擬每個模塊的系統其餘部分。但是，謝謝:-) – 2008-12-15 21:34:02
你能詳細說明它是什麼嗎？這似乎是一個巨大的項目，尤其是它是「不可分割的」 – 2008-12-16 03:17:29
+1答案中的「可重複使用」這個詞似乎引起了混淆，你甚至可以刪除它。拆分將有助於管理複雜性，因爲模塊A難以以模糊的方式與模塊B耦合。如果接口是仔細設計的。 – MarkJ 2009-04-04 11:14:48
在代碼的不同區域之間創建「防火牆」。您可以通過定義不同的代碼區域或層次來實現此目的，並定義每個圖層響應的單個API（Java中，這通常由一個接口完成）。應該有API使用的純粹的接口或類，但是對這些層的內部沒有「瞭解」。例如，gui不應該知道或關心你如何存儲數據，你的數據庫不應該知道或關心數據如何呈現給最終用戶。
這些API不必一成不變 - 只要您確保不會污染防火牆，您應該可以根據需要添加內容。
我理解並尊重你的意思，但這並非總是可行。如果我爲模塊A提供基礎設施，則模塊A依賴於它來進行正確的工作/測試。爲這個基礎實現一個模擬就像爲了測試的目的再次實現基礎。 – 2008-12-15 21:22:12
正確，但這通常發生在實踐中。有時候，通過使用模擬框架可以將努力降到最低。 – 2008-12-16 02:48:05
更多代碼評論，也許代碼的所有權。
如果你只是破解了一些隨機代碼，那麼你並不關心你自己的代碼。如果您有責任維護項目的一個模塊，那麼您想要發光。
而且代碼評論是您展示代碼的時候。
您必須密切關注軟件開發實踐。必須有代碼評論和單元測試，通常確保更新影響系統中的其他內容。 20-50的開發人員很多，但可以完成。實施良好的流程是唯一能夠幫助您在這種環境中解決問題的方法。強制編碼標準也是關鍵。
努力保持設計儘可能的乾淨。這並不容易，但這是值得的。
聽起來很多人並沒有遵循封裝和良好設計的一些基本原則。
爲了避免你所描述的問題，在其他部件上保持獨立和不可靠的事情是必不可少的。您可能需要更高級的設計師或建築師。這是一個典型的情況，人們已經證明一些嚴厲的流程和改變管理。 （我不主張）
您需要避免依賴性和相互關係，只需定義和使用公共接口。這當然是過於簡單化了，但是您可能會通過一些關於代碼的指標 - 類的複雜性，公共方法，從逆向工程代碼構建的UML圖等學到很多東西 -
跟蹤各個部分的缺陷和性能的系統將允許你發現問題。由於系統改變設計不當或書面功能或模塊的缺陷率較高。當發現「問題」模塊時，可以決定重寫模塊（而不是應用程序）。
我認爲主要的一點是，當你說
你只是想重寫一切從頭開始
只是擁抱它。
使用盡可能多的單元測試，然後讓重構成爲一種常見做法。
自動和單元測試將確保更改不會引入迴歸;用一定比例的時間來重構舊代碼（這意味着，較少的新功能！）確保現有代碼庫不會變老，或至少不會太快。
我不認爲這是正常的。當它在那裏呆了幾年時，很難對抗這件事。
，以避免它的唯一方法是改變態度：
「敏捷開發者向軟件設計的態度是，外科醫生對無菌手術同樣的態度。無菌手術是什麼使手術可能。沒有它，感染的風險將會太高而無法容忍。敏捷開發人員對他們的設計也有同樣的感受。讓甚至腐爛的哪怕一丁點開始的風險太高容忍。」 馬丁C.羅伯特 ‘敏捷原則，模式與實踐在C＃’
我強烈建議尋找到這本書的建議。它將所有「設計氣味」，它們存在的原因以及離開它們的後果命名。願這能幫助你說服你的管理層，目前的情況是不恰當的。
祝你好運！
我認爲可以通過全面使用依賴注入獲得的鬆耦合是一項技術特性，可以提供很多幫助。當你分解應用程序時，你不太可能得到「有趣」重用產生的意大利麪條。
您可能會過度分散，但這是另一個問題，而不是全球結構性問題。
開始創建單元測試，這將幫助您解耦代碼並避免錯誤修復後續錯誤。它具有很好的覆蓋範圍，它可以讓您更輕鬆地刪除未使用的代碼。
持續重構。你有重構，因爲你去，特別是在設計級別。當你看到破損的代碼或設計，準備修復它。這通常是修復本身未破的東西的一種情況。除了......它只是沒有表現出它的破碎......然而。
沒有
:)
代碼複查，編碼標準，以及堅定的政策。
以下是適用於我們的商店 - 因爲我不知道你有什麼樣的商店，你的里程可能會有所不同。在轉向Team Foundation Server時，我們很大一部分工作重點是維護代碼質量 - 或者至少幫助以任何可能的方式保持質量。我們添加的一些示例：
就像我說的，如果你使用的是不同的平臺，可能的工具可用，你可以做的是不同的。但是不要排除工具以任何可能的方式提供幫助。如果您可以使用它來改進，控制和審覈您的工作流程以及其中的項目，那麼至少應該值得考慮。
請記住，過程中的任何更改都將涉及推回。我們幫助緩解這一問題的方法是將策略建立在從舊版本控制/缺陷跟蹤系統轉換的培訓中。
軟件行業最大的問題是編程代碼的質量被視爲一個主觀問題。如果沒有一些明確定義的指標，只是簡潔而整齊，並且遵循這些慣例還不足以確保質量是可以接受的。
有人試圖改變this，但他們不太可能獲得足夠的興趣或接受，主要是因爲程序員長期建立的文化正在努力遠離類似於工程的任何事情。 「純粹藝術」編程理念意味着你的20-50開發人員都將以自己獨特的方式在代碼中徘徊，這樣無論個人編碼人員多麼優秀，團隊努力的總和總是要是「一大塊泥土」。爲了避免這種情況，要麼讓所有的編碼器在同一個'頁面'上，使規範化的代碼成爲你的約定的一部分，要麼在開發團隊變得更小（1-3人）的工作後追逐，而你是大kahuna。有一天，大車隊會找到一個方法來建立更好的東西，但在那之前，即使是其中最好的是，如果他們可以得到接近6個滿分10分，我們建立低質量的軟件，非常幸運，因爲這是我們建立我們的行業做...
保羅。
我認爲關鍵的代碼，避免腐爛在於完善自下而上的設計和實現方法（我相信它如此強烈，我叫我的事 - 認爲自下而上 - ！後話）。選擇這裏的工具有：
正如其它受訪者提出，需要及早發現問題。對於綠色開發者來說，這意味着輔導（配對編程在這裏很棒）和評論（代碼和設計評論）。隨着更多的高級開發人員，這意味着警惕。
最重要的是，不要害怕重構。如果重構讓你害怕，那麼你已經沉沒了。如果重構被認爲是「不好的」，那麼你的業務就會出現問題。
當你解決某個問題，妥善解決這個問題。我使用術語「fux」來描述修正方法是錯誤的：它只是「fux」你的代碼庫。
乾杯，
丹
不允許被提交代碼，直到至少兩雙眼睛都看到了。
Shore and Warden's The Art of Agile Development是一本很好的書，有關於「將XP應用於現有項目」（第4章）的章節。除非您努力奮鬥，否則項目會越來越糟糕：克服此類技術債務是困難的並且會使得發佈可接受版本變得越來越困難。唯一的解決方案是降低您提供新功能的速度，並節省時間以改進測試覆蓋率和重構。
通常，項目沒有太多的測試覆蓋率，也沒有運行10分鐘自動化腳本的選項，這些腳本將非常全面地構建和運行您的代碼。相反，大多數代碼的結構很難測試。然後，最好的選擇是在可以的地方添加簡單的測試覆蓋率，同時開始重新構建抽象代碼以便測試更容易。
儘管團隊需要花時間改進代碼以使其清潔和可測試，但您可能無法停止交付，因此需要「完成」清理工作。所以，你必須一步一步做，同時也增加新的功能。沒關係，先挑選最差的區域，但不要指望立即獲得明顯的好處。堅持下去，因爲最終你會到達那裏。不要聽那些說所有大型項目都不好的聲音。總之，每週花一點時間整理一下，並確保下週的代碼比本週更好。
我喜歡這個問題被標記爲「絕望」。 :) – Parappa 2008-12-15 21:23:43
我刪除了`despair`標籤 - 抱歉！ – 2010-06-06 01:52:58