• 重构,开启系统优化的钥匙


    代码重构会不会太low?

    说到重构,其实可能每个人心中的理解都不太一样。

    单纯意义上来说,重构是对代码的再调整,在不改变业务逻辑的前提下,降低代码的长度、圈复杂度、重复度,提高其可读性、可维护性和可扩展性。简单来说,就是把代码整的规整干净,逻辑清晰,层次分明。

    然而,这往往不是产品线希望得到的答案,不同的产品线在和我们接触的初期,都会很明确的说,我的系统需要重构。但当我们介绍完什么是重构,如果做重构时,或多或少的,对方会流露出失望或者不以为然。

    作为一个程序员,我当然知道对方在想什么,把代码整这么漂亮有什么用呢?系统只要没有bug就行了;我们没有这么多时间花在这种费力不讨好的事情上。

    码神训练营有一节“编写可读代码的艺术”的培训课,教如何写clean code的同时,还有一段专门讲重构代码。听培训的同学多半兴趣度不高,然而看起来简单的规则,其实不是每个人都真的理解和玩得转。

    来点我们真正需要的吧!

    产品线关心的是改善他们的业务痛点,所以经常会有人纠正我们说,你们说的代码级的重构,我们说的是架构级的重构。

    不同的产品线的业务痛点可能不尽相同:

    • 代码复杂度高,分支多,动辄上千上万行的代码,导致问题难以定位,测试覆盖不到,也不敢轻易修改;
    • 类似的bug反复出现;
    • 系统间耦合紧密,单个功能点的修改往往或涉及多处代码的修改,或者单个功能的延迟导致整个系统无法上线;
    • 系统的CPU占用率高,Memery占用率高,要吗卡死,要吗直接挂掉;
    • 系统响应慢,用户抱怨多;
    • 并发导致的各种不确定bug,测试环境复现不了,一上线又冒出来;
    • 等等;

    所以,产品线的期望非常明确,我希望通过架构重构,改善以上情况,至于代码漂不漂亮,并不重要。

    目标很远大,现实很骨感

    这种想一步到位,一针见血的想法能不能做到?我想如果是在传统行业,有了解产品整个成长过程的工程师,代码经过深思熟虑的设计,还是有可能做到的。

    可惜对于高速发展的互联网来说,人员流动快,产品上线压力大,这种任务几乎就是mission impossible了。

    很多人想到了,既然原来系统这么庞大,还没人熟悉,干脆重写得了。问题是谁能保证新写出的系统能比老系统更好,前人填过的坑,都能在新系统中一一规避呢?

    所以,我们可能还是需要从代码重构下手。

    用重构打开系统优化的大门

    我们团队有一个说法叫“小步快跑”,其实我还想到一个说法叫“星星之火,可以燎原”。把代码的复杂度降下来,重复度降下来,不是最终目的,只是最初手段。

    几乎我碰到的所有重构项目,在重构早期,面对系统已有的问题,接手重构和我们的同学有时会哀声叹气,都有种无从下手的感觉。然而随着重构的深入,对系统的改造开始不单单局限在代码上,方案也开始逐步清晰。手段和方法开始不断涌现:

    • 采用面向过程编程,还是面向对象编程,还是函数式编程?
    • 能否引入DSL,代码生成等方法?
    • 是否需要引入设计模式,例如策略,桥或者状态机?
    • 是否需要并发,是否需要同步?
    • 是否需要数据缓存,是否需要事件驱动?
    • 业务模型是否合理,数据库设计是否合理?
    • 系统分层是否合理,是否做到了单一职责,高内聚,低耦合,可扩展?
    • 系统配置是否合理,启动参数是否合理,线程池是否合理?
    • 业务逻辑是否恰当,流程是否清晰?
    • 等等

    以上这些手法,将不再被认为耍花腔,over design,而是重构系统后应运而生的最佳方案。
    一个几十万行代码的系统,它庞大,复杂,没有头绪,如果盲目的下手,可能会带来整个系统的崩盘。而重构的作用,就是从一处着眼,把相对独立的部分重构成如乐高积木块的一个单元,然后逐步扩散,剥离无用的部分,清理出主线,最终实现一个清晰可扩展的系统。

    所以,其实重构可以说很简单,也可以说很复杂。不过有了代码重构这个钥匙,再厚重的大门,也是敲得开的。

    让重构成为一种生活习惯

    不管怎样,要把系统重构或者优化到满意的状态,特别是一个已经有几十万行的代码的系统来说,都不是一朝一夕能完成的工作。他需要和开发团队的整体配合和新需求的共同排期。与其让系统有一天膨胀到走不动的时候才想起重构,最好的办法,还是把重构融入到日常的工作中。一个好的工程师,或者工程师团队,应该敏锐的及时意识到系统即将面临的问题,并及时引入重构。

    或许有些大家都认为合理的事情,其实是不合理的:

    • 你的产品真的需要这么多代码吗?
    • 这个系统真的需要这么多子系统吗?
    • 团队中真的需要这么多人吗?
    • 类似的功能真的需要反复开发吗?
    • 你真的需要天天加班吗?
      通过持续的重构,防止代码腐化,保证代码的简洁高效,让它适应新的产品需求,或许会是以上问题的一个良方。

    最后说一句口号,你不是码农(屌丝),你是软件工程师(白富美),你更是意识构建的“艺术家”(高大上)。代码可以像一堆杂草,也可以如变形金刚,好与坏全在你一念之间。当我们接手一堆烂代码时,除了骂骂前面挖坑的人,也提醒自己不要成为下一个被骂的人。

  • 相关阅读:
    (六)键盘事件
    (五)鼠标事件
    (四)WebDriver常用方法
    等价类,边界值,判定图实例
    WCF入门(三)---WCF与Web服务/Web Service
    WCF入门(二)-----实战开发
    C#中用JavaScriptSerializer和Json.Net操作json格式的文件
    C#中SaveFileDialog 和OpenFileDialog 的用法
    C#操作.csv文件Demo
    Excel操作--使用NPOI导入导出Excel为DataTable
  • 原文地址:https://www.cnblogs.com/wangtcc/p/10603000.html
Copyright © 2020-2023  润新知