我被要求进行代码审查并报告在我们的新产品中添加新功能的可行性,这是我迄今尚未亲自处理过的新产品.我知道很容易挑选别人的代码,但我会说它的形状很糟糕(尽量尽可能客观).我的代码审查中的一些亮点:
滥用线程: QueueUserWorkItem和线程一般使用很多,而线程池代表有无信息的名称,如PoolStart和PoolStart2.线程之间也缺乏适当的同步,特别是访问除UI线程之外的线程上的UI对象.
幻数和魔术字符串:代码中定义了一些Const和Enum它们,但是大部分代码都依赖于字面值.
全局变量:许多变量被声明为全局变量,可能会也可能不会被初始化,具体取决于所遵循的代码路径以及发生的顺序.当代码也在线程之间跳转时,这会变得非常混乱.
编译器警告:主解决方案文件包含500多个警告,总数不为我所知.我从Visual Studio收到警告,它无法再显示警告.
半完成的课程:代码已经处理并添加到这里和那里,我认为这导致人们忘记了之前所做的事情,所以有一些看似半完成的类和空的存根.
未在此处发明:该产品复制了其他产品使用的公共库中已存在的功能,例如数据访问助手,错误记录助手和用户界面助手.
关注点分离:当我们阅读有关典型的"UI - >业务层 - >数据访问层"3层架构时,我认为有人正在颠覆这本书.在此代码库中,UI层直接访问数据库,因为业务层部分实现但由于未充分充实而被忽略,并且数据访问层控制UI层.大多数低级数据库和网络方法都在对主窗体的全局引用上运行,并直接显示,隐藏和修改窗体.在实际使用相当薄的业务层的情况下,它也倾向于直接控制UI.大多数这种低级代码也使用MessageBox.Show发生异常时显示错误消息,并且大多数吞下原始异常.这当然使得在尝试重构之前开始编写单元测试来验证程序的功能有点复杂.
我只是在这里表面上看,但我的问题很简单:花时间重构现有的代码库,一次关注一个问题,或者你会考虑从头开始重写整个事情是否更有意义？
编辑:为了澄清一点,我们确实有项目的原始要求,这就是为什么重新开始可能是一个选项.另一种表达我的问题的方法是:代码能否达到维持成本的成本大于倾销和重新开始的成本？
我是一名初级软件工程师,他接受了接管旧系统的任务.根据我的初步评估,该系统存在一些问题.
我该怎么做才能提高系统质量并解决这些问题？我可以考虑使用静态代码分析软件来解决任何不良编码实践.
但是,它无法检测到任何不良设计问题或问题.我该如何逐步解决这些问题？
我将在庞大的代码库(18000+ Java类)中重构某些部分.目标是能够将较低层提取为独立库,以便在当前使用此代码库副本的其他项目中重用.特别是将一部分重构为独立于业务逻辑的框架.最终,我希望代码具有干净的架构层次结构.
我用一个名为Structure 101 for java的工具查看了代码,发现很多(!)的架构分层问题,其中较低层引用了上层.
我不想简单地开始搞乱代码,而是试图找出一个合理的策略来解决这个问题.我应该记住什么？
我在考虑至少采取一些小步骤.我也在考虑进行单元测试,但这需要创建它们,因为没有.
有什么想法吗？
我正在尝试重构一个紧密耦合的大型应用程序,并试图使其更易于维护和灵活.
我有很多单元测试,所以我希望一步一步地进行重构.
我应该考虑实施/应用哪些设计和重构模式来完成这项任务？
我能想到一些:
也可以随意分享您自己的经验和这种重构工作的最佳实践.
UPDATE
由于这个问题中解释的原因,我正在进行这种重构.基本上我不能在不提取几个接口的情况下实现插件系统,并且这些接口是高度耦合的,这需要将40多个DLL中的应用程序分开,以便在没有循环引用问题的情况下进行编译.