com*_*ael 19 refactoring recovery design-patterns anti-patterns
是什么导致计算机程序变成泥球？是否有可能从这种反模式中恢复？是否有可以应用的经过验证的重构方法？
Ani*_*udh 27
泥球大球通常是由于以下原因之一而发生的:
需求变更 - 您构建了一套具有一组需求的解决方案,随着时间的推移,现在,您可能会迎合不同的受众,他们希望使用具有稍微不同要求的相同产品.您将这些要求烘焙到同一产品中,最终得到BBOM.
开发人员的变化 - 原始产品是由一组具有某些设计和架构假设的开发人员创建的,对于那些"接管"产品以进行维护或进一步开发的全新开发人员来说,这些假设并不完全明显.新开发人员做出了自己的假设,随着时间的推移,产品会变成一堆难以维护的垃圾.
能力不足 - 开发人员(他们不知道反模式),管理(要求太高,缺乏产品知识)或用户(他们真的不知道他们需要什么).这很难解决.
有时,最好的解决方案是简单地重写满足新要求的应用程序.但这通常是最糟糕的情况.繁琐的解决方案是停止所有新开发,首先编写一组测试,然后重新设计并重新构建整个解决方案.但这可能需要数年时间,具体取决于产品的尺寸.
我遇到的BBOM通常是在达尔文的过程中有机地创建的.它是这样的:
最初,系统是创建的(未设计)且文档记录不佳.
原始资源继续在其他地方创造更多的havok,因此这个"遗留"系统甚至没有口述历史.
新鲜的血液被带进来.这些开发者试图发现各种系统部件的工作情况,但就像几个盲人试图了解大象时,一个人抓住了尾巴,一个是腿,一个是躯干.他们做出改变但从未真正对他们充满信心.
通过这种方式,系统通过盲目自然选择"演变",但与此平行的是最棘手,不可再生的错误的演变,这些错误仍然存在,因为它们仍然在雷达屏幕下,直到它们在客户安装时出现.