答“我们的团队项目是否有大泥球？”

       总结了一下，产生大泥球的主要原因有下面这些原因：

（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