?????? 總結了一下，產生大泥球的主要原因有下面這些原因：

（1）一次性代碼

（2）碎片式增長

（3）為了讓軟件不出問題

（4）Copy/paste導致問題轉移（有問題的代碼被復制到很多地方，不斷蔓延）

（5）缺少前期設計

（6）應對需求變化過晚

?????? 在具體的項目開發之中，體會較深的就是一次性代碼和缺少前期設計造成的大泥球。我們在設計軟件時常?？紤]不到軟件代碼的復用性，導致設計的代碼僅供目前所在模塊使用，而沒有考慮到其它模塊可能的調用，從而帶來了代碼復用時的泥球；前期接口設計不當也會造成大泥球的產生，當調用關系復雜起來后，調用深度越來越深，最后到寫出來的代碼自己都看不懂（我遇到這種情況的時候，常常注釋都不知道怎么寫才好）。

?????? 在這次團隊項目作業里，我們設計的是網站UI，所以調用深度不會特別深，不過一次性代碼也帶了好些麻煩，因為畢竟分工時經常是每個人負責一個模塊，當組員一在設計自己的模塊時，經常只考慮到自己的模塊要使用的地方，當設計其它模塊的組員二發現要使用到該組員設計的模塊里的某個方法時，然而組員一沒有提供一個方便的調用這個方法方便方法（當然這也涉及到前期設計不好造成的后果了），組員二就會嘗試“繞著彎子”調用這個方法了，因此就會出現類似下面這樣的代碼了：

clusterNO1=_listOfObjectClusterInfo.get(index1).getOne_clusterInfo(j).get_clusterNO();

這里面有四層的調用深度，這是我自己在寫一個小項目時的java代碼，這時候我已經不知道怎么寫注釋了，不認真看也不怎么看得懂了。之前還看過大牛的調用深度達到六七層之深，我就難于想象在維護時會有多麻煩了。

??????? 但是文章里提到“大泥球”似乎仍然是最常見的軟件設計，很難避免。盡管涌現出各種鼓勵、促進良好結構代碼的開發方法，軟件技藝運動也在不斷成長，但是“大泥球”仍然是最常見的軟件設計，即使人們已經從過去惡劣的設計中學到了東西，但在新的開發過程中，大泥球仍未消失。

轉載于:https://www.cnblogs.com/DOOM-lz/archive/2012/11/11/2765493.html

總結

以上是生活随笔為你收集整理的答“我们的团队项目是否有大泥球？”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。