代码之家  ›  专栏  ›  技术社区  ›  rr.

向急需重构的代码基添加特性

  •  2
  • rr.  · 技术社区  · 15 年前

    我正在开发一个有点难以使用的系统。它是99%的无文件证明,不遵循最佳实践,而且相当难以理解(全球范围内大量,方法跨越50行,eval滥用等)。不幸的是,我对代码库还比较陌生,需要添加功能。

    我确信里面有我可以重用的代码,但是我必须在最后期限前完成,而且我担心花在抢救上的时间最终会被我冲到最后。从长远来看,什么更好?我的一部分人希望尽可能多地重用,但另一部分人说,我应该集中精力从头开始编写新功能,冒着重复的风险(当我有更多的时间花在现有代码上时,计划进行重构)?我倾向于后者,但想听听别人的意见。

    谢谢!

    5 回复  |  直到 15 年前
        1
  •  4
  •   eruciform    15 年前

    http://www.joelonsoftware.com/articles/fog0000000069.html

    http://discuss.joelonsoftware.com/default.asp?design.4.469415.13

    http://www.joelonsoftware.com/articles/fog0000000007.html

    http://www.paulgraham.com/hp.html

    也就是说,如果有小部分需要清理,那通常是可以的。一旦你在这方面工作了一段时间,你就会更好地了解战略的、本地化的重写在哪里最有效、最不危险。

    在一个生产代码库中,记住保持客户的现状比把新东西搬出去更重要。这不会阻止你老板对你大喊大叫。但是问问你自己,有多少次你因为错误而换成了另一种产品,而有多少次你这么做是因为你想要的增强在其他可行的产品中不够快。

        2
  •  2
  •   Carl Manaster    15 年前

    我同意你的直觉:用你知道的方式写。TDD,如果这是你的方法;无论如何,试着确保你的新产品被合理的测试覆盖(当然,比现在的东西少一些混乱)。

    在这一过程中,您可能确实有机会重构,找到重复的功能,并选择要保留的方法和类;在这些情况下,您可能会发现自己是管理员。

    当然,完全有可能“顺路”永远不会到来。至少你的新东西是工作的、可读的和可重用的——这比你花时间在现有代码库中跟踪一个函数(如你所描述的)并重用它要好。

        3
  •  1
  •   Mike    15 年前

    你所经历的一切都可以通过阅读工作来克服。 Effectively With Legacy Code . 我知道你说过你的最后期限很紧,但是匆忙而没有完全理解核心代码库可能(而且很可能)会有一些负面的副作用。

    另外,您还提到了一旦时间允许,就计划重构。我已经说过很多次了,让我告诉你,几乎所有的时间都不会到来。第一次做对了,为下一个开发人员或者稍后添加新功能的时候帮自己一个忙。

        4
  •  0
  •   bpeterson76    15 年前

    在我的工作中,我们处于同一条船上:第一阶段朝着一个有效的方向发展,但并不理想。第二阶段改变了业务模型和逻辑……这个阶段是离岸的,如果公司真正理解了他们选择构建的框架,这本身就不会成为问题。因此,我们在这里试图完成第3阶段(消除第2阶段的混乱,按照预期正确地使用框架),同时哀叹必须在编写得如此糟糕的代码库上工作。存在着重大的挑战——使用两个JavaScript框架、笨重的遗留UI、垃圾代码,以及对框架的重大更新,这使得我们所使用的版本过时,几乎不可能迁移到新版本。

    这是我们选择做的……这可能不适合您的情况。首先,我们的产品开发副总裁花了两周时间,完全重新考虑了数据库结构。他让我们的编程人员根据需要修改现有代码,以适应适当、高效的DB结构。一旦(痛苦的)步骤完成了,我们就休息了两周来在新特性上取得进展。然后,我从我的职责中休息了一下,完全重构了UI,取消了使用一个JavaScript框架的工作,这样我们就可以在一个公共平台上工作(这是一个什么概念,暗示糟糕的离岸公司…)并有效地使用现代、高效、当前的UI元素。我们将遵循80%-20%的任务组合,直到产品不再测试——80%实现最终的需求,20%重构代码和清理遗留的混乱。每个员工都有一个区域负责“清理”或提高效率。流程文档也是一项已委派的任务,并且是每个员工工作周的必需百分比。

    我认为我们流程成功的关键是要着眼于第4阶段,即使在第3阶段完成之前。新的代码正在以最大的效率和互换性进行构建,因此,如果我们离开这个过时的平台,将需要进行最小的更改。我正在尝试一种方法来划分我们的过程(不仅仅是代码),以便理论上在适当的时候将它们单独移动到一个新的框架中。我们的未来计划是纸上谈兵的,随着需求清单的不断发展和寻找最佳工具的研究也在进行中。最重要的是,团队领导是一个坚持正确和高效地做事的人,所以没有任何当前或未来做得不好的事情会继续下去。

    很难向管理层证明你需要倒退才能前进。当你的公司的整个未来都依赖于一个像我们一样被测试的产品时,这就更加困难了。我把它比作为一个节油的设备花费更多……它现在会花费更多,但最终会获得巨大的经济回报。我认为在这种情况下取得成功的诀窍是找到你的产品的中位数,它“足够好”,可以在你花时间使产品变得伟大的同时独立存在。制定一个战略,以满足中位数将挑战业务部门的耐心,最终将使你成为英雄,当它成功。制定一个强有力的计划,交流这个计划,和别人一起玩得很好,然后把你的尾巴拔出来。很快,你就会重新享受生活了!

        5
  •  0
  •   Symen Timmermans    15 年前

    不要担心您正在添加的这一小部分功能。快点弄脏。

    如果您的团队正在计划对源代码进行重构,请确保您有管理层的支持。让您的管理层知道您现在面临的问题:当前的代码库没有遵循最佳实践。应用程序的非结构化程度越高,添加功能所需的时间就越多。构建新功能不会花费大部分时间,但要确保它在任何情况下都能按预期运行,并且在出现问题时解决问题,foobar也会花费宝贵的时间。

    如果要重构应用程序,请考虑一下如果选择一些现成的解决方案来更好地实现应用程序的某些部分,您将获得哪些好处:

    • 类似Zend框架的MVC框架
    • Zend框架类库,用于经常使用的组件,如auth/acl/oauth/etc。
    • 数据库抽象层或类似ORM的条令或推进
    • 只有一个javascript库:jquery(可能与jquery ui结合使用)
    • 像phing和ant这样的自动部署系统
    • 为您的类进行单元测试
    • 基于使用硒的用例的验收测试
    • 一种井外版本控制系统及策略

    我可以继续一段时间。 有时,应用程序的完整重建是后退两步,但前进四到五步。