假设一个较大的模板库包含大约100个文件,其中包含大约100个模板,总共超过200,000行代码.一些模板使用多重继承来使库本身的使用相当简单(即从一些基本模板继承并且只需要实现某些业务规则).
所有存在的(长达数年),"工作"并用于项目.
但是,使用该库编译项目会占用越来越多的时间,并且需要花费相当长的时间来查找某些错误的源代码.修复通常会导致意外的副作用或非常困难,因为某些相互依赖的模板需要更改.由于功能的庞大,测试几乎是不可能的.
现在,我真的想简化架构以使用更少的模板和更专业的小类.
是否有任何可靠的方法来完成这项任务？什么是一个好的开始？
我不确定我是怎么看/为什么模板是问题,为什么简单的非模板类会是一个改进.这不仅仅意味着更多的课程,更少的类型安全性以及更大的漏洞潜力吗？
我可以理解简化架构,重构和删除各种类和模板之间的依赖关系,但自动假设"更少的模板将使架构更好"是有缺陷的imo.
我会说模板可能会让你构建一个比没有它们时更清晰的架构.仅仅因为你可以让独立的课程完全独立.如果没有模板,调用另一个类的类函数必须事先知道该类或它继承的接口.使用模板,这种耦合不是必需的.
删除模板只会导致更多依赖,而不是更少.增加的模板类型安全性可用于在编译时检测大量错误(为此目的使用static_assert自由地使用代码)
当然,在某些情况下,增加的编译时间可能是避免模板的正当理由,如果你只有一群习惯于用"传统"OOP术语思考的Java程序员,那么模板可能会混淆他们,是避免模板的另一个有效理由.
但从架构的角度来看,我认为避免模板是朝着错误方向迈出的一步.
重申应用程序,当然,这听起来像是需要的.但是,不要因为应用程序的原始版本滥用它而丢弃一个最有用的工具来生成可扩展和健壮的代码.特别是如果您已经关注代码量,删除模板很可能会导致更多的代码行.
您需要自动化测试,十年后,当您的成功者遇到同样的问题时,他可以重构代码(可能添加更多模板,因为他认为这将简化库的使用)并且知道它仍然符合所有测试用例.同样,任何小错误修复的副作用将立即可见(假设您的测试用例很好).
除此之外,"划分和征服"
京公网安备 11010802040832号 | 京ICP备19059560号-6 