代码整洁之道

2022-09-22 11:05:25 浏览数 (1)

原创不易,且行且珍惜

01

前言

【挑战者号事件】1986年1月28日,美国东部时间上午11:39,“挑战者”号航天飞机在发射仅 73.124秒后,因右侧固体火箭助推器故障,在1.5万米高空爆炸坠毁,7名航天勇士全部罹难。

背景:高热气体从出现故障的固体火箭助推器的外壳接缝处泄露出来,喷到外部燃料舱体上,主液氢燃料舱底部发生爆炸,液态氢被点燃。

根本原因:在火箭助推器的圆形接缝处,有2个由合成橡胶制成的同心密封圈。发射前夜,气温降到了-8摄氏度,比密封圈的最低承限温度低了13度,这个温度下的密封圈已经硬的失去了弹性,无法很好地密封高热气体。

工程师们写了备忘录,发出了高危预警信号,要求宇航局的管理人员取消此次发射任务,面对财务和政治的 压力宇航局的管理人员们无动于衷,最终导致此次灾难发生。

反思:事前应对各个零部件进行严格的检测,并将问题报告给生产商莫顿*奥赛科公司和美国宇航局的管理人员,发出预警信号,有必要抗议取消发射任务。如下为发生此次事故的O型圈:

02

联想(雪崩效应)

由上面的“挑战者号”事故,我们联想到我们作为工程师开发的系统,当由小问题产生的连锁一系列积累也会引起以下问题:

1、服务提供者不可用;

2、重试加大请求流量;

3、服务调用者不可用;

4、整个系统崩溃不可用

2017年做支付系统时,虽然没有遇到灾难性的问题,但是各种问题层出不穷。当时的系统技术栈很落后。

技术栈:Struts1.0、ibatis、jsp/html、ThreadPoolTaskExecutor定时任务。

程序:代码冗余、结构混乱、开发困难、测试部署艰难。

遇到的问题:一个action类2000多行代码,一个method方法几百行代码,上游渠道、支付方式和路由等规则繁多,支付系统处于中台系统,下方连接商家的支付通道接口,上游连接各个银行机构等渠道。没有可视化界面系统部署可以测试和操作,只有一个jsp测试页面用来测试各个接口(交易下单、退款、交易查询、退款查询等)。

查询问题非常艰难,需要去到不同办公司的运维部门同事的机器旁边,登录生产服务器跟踪日志排查问题(或者打包日志自己查询)。经常出现长款或短款问题,商家支付了没有收到支付系统的异步通知,一是由于支付系统问题导致没有通知到商家,二是由于上游渠道问题没有通知到支付系统,或者在接收上游异步通知的过程中出现问题导致失败。

03

重构

基于以上频发问题带来的耗费大量运维人员成本和时间成本等,公司决定重构系统。

技术栈:SpringBoot/SpringCloud kafka Redis vue angluar

系统采用微服务架构,按照业务把支付系统划分为:交易、支付、清算、收银台等模块,前后端分离的策略。

开发和测试以及部署工作变得非常简单,采用链路式日志追踪中间,排查问题简单方便,线上问题减少了很多。

重构的微服务子系统架构如图所示:

04

代码整洁之道

4.1 何谓整洁代码

代码逻辑直截了当,缺陷难以隐藏

尽量减少依赖,便于维护,便于阅读

分层战略完善代码逻辑,不冗余

有单元测试,性能调优

只提供一种做一件事的途径

4.2 方法和技巧

有意义的命名 重构 Code Review逐步改进

4.3 有意义的命名

a、名副其实 b、避免误导 c、做有意义的区分 变量、函数、参数、类、包命名中的原则

代码语言:javascript复制
  public List<int[]> getThem(){
        List<int[]> list1 = new ArrayList<int[]>();
  for(int[] x : theList)
                 if (x[0] == 4)
         list1.add(x);
        return list1;
    }

以上这段代码,我们认为是不太整洁的,至少存在以下几个问题:

(1)theList中是什么类型的东西?

(2)theList零下标的含义是什么?

(3)值4的意义是什么?

(4)怎么使用返回的列表?

运用整洁的技巧之后:

代码语言:javascript复制
  public List<Cat> getCat(){
        List<Cat> catList = new ArrayList<Cat>();
            for(Cat cat : animals)
      if (cat.color == Constants.WIHTE)
                    catList.add(cat);
        return catList;
    }

05

重构

1、何谓重构:软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高可理解性,降低成本。

2、为何重构:可读性差、难以维护和修改,冗余甚至出现隐藏bug,带来线上隐患。重构可以改进这些问题,帮忙找出bug,避免问题。

3、何时重构:《三次法则》第一次做某件事时只管去做 第二次做类似的事会产生反感,但无论如何还是可以去做 第三次再做类似的事,就应该重构了。

预备性重构,让添加新功能更容易;帮助理解重构,使代码更易懂;有计划的重构,长期重构等。

4、挑战:延缓新功能开发,代码所有权,分支问题、测试问题。

尝试重构以下代码段,重构之前:

代码语言:javascript复制
public void scaleToOneDimension(float desiredDimension, float imageDimension){

        if(Math.abs(desiredDimension - imageDimension) <errorThresold)
        return;
        float scalingFactor = desiredDimension / imageDimension;
        scalingFactor = (float)(Math.floor(scalingFactor * 100) * 0.01f);
        RenderedOp newImage = ImageUtilities.getScaledImage(image, scalingFactor,scalingFactor);
        image.dispose();
        System.gc();
        image = newImage;
}
public synchronized void rotate(int degrees){

      RenderedOp newImage = ImageUtilities.getRotatedImage(image, degrees);
      image.dispose();
      System.gc();
      image = newImage;
}

重构之后:

代码语言:javascript复制
   public void scaleToOneDimension(float desiredDimension, float imageDimension){

        if(Math.abs(desiredDimension - imageDimension) <errorThresold)
        return;
        float scalingFactor = desiredDimension / imageDimension;
        scalingFactor = (float)(Math.floor(scalingFactor * 100) * 0.01f);
        replaceImage(ImageUtilities.getScaledImage(image, degrees));
}
    public synchronized void rotate(int degrees){

        replaceImage(ImageUtilities.getRotatedImage(image, degrees));
    }

    public void replaceImage(RenderedOp newImage){

      image.dispose();
      System.gc();
      image = newImage;
    }

06

总结

我们在做系统开发编码时,无论是对于系统响应及时性没有前端系统要求那么高,却有业务复杂、数据严谨的性质。还是面对高并发多线程,海量业务,分布式事务,一致性等要求很高的情况。良好的代码质量是保障系统和业务稳定的基础,要求我们从每一个代码、每一个变量、每一个方法做起。

0 人点赞