max*_*ori 11 refactoring design-patterns
在我曾经工作的几乎每个项目中,都会有一个或两个具有以下属性的类:
你可能会说糟糕的设计.但在所有情况下,在设计时并非如此.这些课程随着时间的推移有机地成长,成为众所周知的"上帝阶级".这对我在大型软件项目中的经验是如此不变,我不得不问:
提示,经验和想法欢迎!
持续重构将有助于防止这种情况发生.
此外,这是一个强制进行一些静态代码分析的地方.您通常可以通过查看代码度量标准找到这些类并标记它们以便自动重构.
不过,我最大的建议是保持设计需要改变的态度,事情需要分解.通常,根据我的经验,这些课程的形成是因为人们不愿意考虑改变破损或次优的设计.保持灵活性可以更容易地防止这种情况发生.
我认为,很多这种情况往往源于随后的设计懒惰."积极重构"的理念是解决这类设计问题的一个很好的解决方案.问题在于,虽然"依赖磁铁"类的初始设计是好的,但后续时间紧迫的工程师倾向于简单地将其他功能附加到该类,原因很简单,因为它可以在需要的地方(通常)使用.
很大程度上,问题与这样一个事实有关:能够处理成熟软件产品需求的设计是对不太成熟的软件产品的过度设计.所有最终都在软件产品的成熟迭代中的设计对于该产品的早期迭代来说是大量的过度杀伤; 从根本上说,随着发展的继续,设计必须随时摆弄.这就是重构是必要的; 随着新特性和功能开始实施,设计问题将显示出来; 正如他们所做的那样,承担重新设计类交互方式的任务以及重构代码以利用它的任务至关重要.只有这样,才能保持与项目成熟度具有任何相似性的设计成熟度.
实际上,设计成熟度会随着项目的复杂性而增加; 对于简单项目而言,大型复杂的设计是不合适的; 就像复杂项目的大规模简单设计是不合适的一样.但由于存在不匹配,设计必须随项目一起发展.重构作为一个过程只是对这种必要性的认识.