【show-me-bad-code】改善既有代码的设计,谈谈我的真实案例

141e22823a2eff067992ba47cd3994a9.png

aba8baca7d856c5d8146ce159d563dd2.png

d4fd21e3e8026ba40961fddb0d9335ec.png

作者简介:

recan RT-Thread社区成员 http://yyds.recan-li.cn

 一个专注于嵌入式软件架构设计的新生代农名工。

ace3615b22a67dbe6f11f68de11e5061.png

点击阅读原文去RT-Thread论坛认识他吧~

1.写在开头

在本活动开始之前,非常荣幸地收到小师弟的邀请,
看能否帮忙想想1024程序员节的论坛活动好点子,在此非常感谢对我的信任。
想起早年在浏览一些博文的时候,对国外代码社区举办的"烂代码比赛"印象深刻,
看到那些牛人提交的"眼花缭乱的bad-but-work-well的代码,简直是佩服得五体投地。
自然我们大部分的程序员还很难提供出这么秀的代码,
所以基于这个原则,结合我们的实际情况,
修改了下比赛规则,重在娱乐参与,旨在代码提升。

2. 我来提供一段代码

2.1 代码背景

这段代码的原型来自于早几年在一家POS行业内头部企业供职时的真实案例代码,基于这套代码也是过了各种POS机的行业认证。

经过10多年的沉淀,基于该模板代码移植/改造而来的应用程序,罐装的POS机累计装机量应该在KW级别,可谓就是传说中妥妥的【祖传代码】。

早期代码的运行环境是嵌入式Linux系统,总内存高达128MB,还是非常富余的;后面才慢慢切为RTOS系统,内存也锐减到64MB,但即便这样,给到应用程序的内存也是非常充足的。

2.2 代码功能

这段代码的主要功能就是在POS机触发交易时的界面(带LCD显示)下,能够自动识别出当前要使用的各种交易方式,其中包括:

  • 是否刷了磁条卡?(刷了磁条卡,走刷磁条卡的交易流程)

  • 是否插入了IC卡?(插入IC卡,走银联的IC卡交易流程,行内称PBOC流程)

  • 是否使用了IC卡做非接触交易(俗称:挥卡)?(挥卡交易,走银联的IC卡快速交易,行内称qPBOC流程)

  • 是否扫描到了微信/支付宝这类的支付条码?(条码支付与标准银行卡交易是完全不一样的流程)

  • 是否按下了【取消键】,用户主动退出了交易?

  • 是否在规定的时间内(一般60S)没有任何的交易发生,导致超时?

除这些功能外,因为POS机交易是需要保存最近N笔交易记录的,所以这个处理交易的流程中,还得维护交易记录的保存。而代码中用于保存交易记录的结构体也是非常非常非常的庞大,大到一个结构体就占用接近2KB,这是非常恐怖的。

2.3 代码片段

为了仅说明情况,而不透露具体的技术细节,这里我仅提供伪代码,注意代码里的注释,是我为了辅助介绍而自己添加的,原来的代码中,注释比这少得可怜。

1/**
  2  * 保存交易记录的结构体定义
  3  */
  4typedef struct _transaction_log_t {
  5       char time_stamp[32];
  6    uint8_t trans_type;
  7    uint8_t trans_no;
  8
  9    /* 各式各样的数据定义长达20-30个变量 */
 10    uint8_t data1[64];
 11    ...
 12    uint8_t datan[128];
 13} transaction_log_t;
 14
 15/* 全局的交易log变量,被各个处理流程的文件引用 */
 16transaction_log g_log_info;
 17
 18/**
 19  * 支持的交易方式的掩码
 20  */
 21#define TRANSACTION_SWIPE_CARD          0x01
 22#define TRANSACTION_INSERT_CARD         0x02
 23#define TRANSACTION_TAP_CARD            0x04
 24#define TRANSACTION_CODE_PAY            0x08
 25
 26/**
 27 * 处理交易的流程总入口
 28 */
 29int all_transaction_process(int timeouts_ms, int transaction_flag)
 30{
 31    int start_time, end_time;
 32
 33    end_time = 0;
 34    start_time = get_local_time();
 35
 36    /* 循环判断需要支持的交易方式,直到触发了某种交易或者超时 */
 37     while (1) {
 38        if (transaction_flag & TRANSACTION_SWIPE_CARD) {
 39             /* 判断刷卡:阻塞式的接口,带超时时间 */
 40            ret = get_swipe_card(10);
 41            if (ret == ok) {
 42                /* 处理刷卡流程 */
 43                ...
 44                return 0;
 45            }
 46        } else if (transaction_flag & TRANSACTION_SWIPE_CARD) {
 47             /* 判断插卡:阻塞式接口,带超时时间 */
 48            ret = get_insert_card(10);
 49            if (ret == ok) {
 50                /* 处理插卡流程 */
 51                ...
 52                return 0;
 53            }
 54        } else if (transaction_flag & TRANSACTION_SWIPE_CARD) {
 55             /* 判断挥卡:阻塞式接口,带超时时间 */
 56            ret = get_tap_card(10);
 57            if (ret == ok) {
 58                /* 处理挥卡流程 */
 59                ...
 60                return 0;
 61            }  
 62        } else if (transaction_flag & TRANSACTION_SWIPE_CARD) {
 63             /* 判断条码支付 */
 64            ret = get_code(10);
 65            if (ret == ok) {
 66                /* 处理条码流程 */
 67                ...
 68                return 0;
 69            }
 70        }
 71
 72        end_time = get_local_time();
 73        if (start_time + timeous_ms == end_time) {
 74            /* timeout */
 75            return -1;
 76        }
 77
 78        /* 界面显示倒计时 */
 79        lcd_update_timetous();
 80
 81        /* 循环延时 */
 82        delay_ms(10);
 83    }   
 84}
 85
 86/**
 87 * main函数总入口
 88 */
 89int main(int argc, const char *argv[])
 90{
 91    /* 应用初始化 */
 92    system_init();
 93
 94    /* 处理备份及系统异常断电引发的冲正交易 */
 95    handle_bakup();
 96
 97    /* main loop */
 98    while (1) {
 99         /* 每10ms获取下当前有没有按键触发交易 */
100        key = get_key_ms(10);
101        if (key1 == key) {
102            /* 有触发交易需求 */
103            ret = all_transaction_process(60*1000, );
104        } else if (key2 == key) {
105            /* 其他菜单操作 */
106            ...
107        } else {
108            /* 超时或未知按键输入 */
109            ...
110        }
111
112        /* 刷新显示在LCD上的时间 */
113        update _time_dispaly();
114    }
115
116    return 0;
117}

2.4 "烂"的理由

这里说上面的代码"烂"并不是说它工作得不行,相反,它的确工作得可以,从装机量和各种行业认证就可以看得出来,还是扛得住市场对它的考验。这里提出它"烂"的原因,主要考虑是从代码设计和代码维护的角度来看。

  • 代码维护上:全局变量全盘引用,乱串于各个文件中,可读性非常差

  • 代码设计上:数据结构没有规划设计,导致结构体定义太复杂,太过庞然大物,冗余空间浪费大

  • 代码设计上:所有交易流程的判断处理,太过于死板,一个if-else判断到底,耦合严重,可扩展性非常差

  • 代码设计上:LCD显示与核心业务流程跳转参杂在一起,没有解耦,往往改了业务功能的同时还要改UI实现

  • 代码性能上:流程处理中,大量使用带超时时间的阻塞式函数,导致整个流程响应的时效性不是很理想

3. 改善既有代码的设计

3.1 改善代码前的思考

大家都戏称祖传代码,请勿随意改动,但我觉得真正优秀的代码,是慢慢被迭代,被重构而来的,否则的代码就会被一步步地堆砌起来,直到有一天,没人能够再修改维护了,那一刻就如同一栋大厦轰然倒塌,这是非常糟糕的。

正是基于这些的考虑,当时我也是很大胆地向主管提出,我们应该从小面积开始做代码重构,逐渐改善一些有缺陷的代码设计。

比较遗憾的是,主管是相对保守的,没有接受后面大面积重构的实施,主要还是担心期间的风险,影响外面的程序升级。从商业的角度上,我是支持他的;但是,从代码的角度,我还是坚持我的观点;当然这并不影响我们的共事。

3.2 我要如何改善这些代码

先说下,主管答允我的小面积重构部分,我是怎么做的!

【代码维护上:全局变量全盘引用,乱串于各个文件中,可读性非常差】

针对这一点,我重新整理了部分的C代码规划,明确要求非十分必要的设计,不允许全局变量在多个C文件中修改传递,尽量控制在一个C文件,同时关键的数据都封装成get/set接口,减少通篇修改数据的可能性。

在code review环境,着重对此类代码做重点审查,一经发现,务必打回重新修改提交。

【代码设计上:数据结构没有规划设计,导致结构体定义太复杂,太过庞然大物,冗余空间浪费大】

针对这一点,我的方法就是重新梳理,我们需要用到的必备数据,把所有非必须的数据全部删除,同时一些数据buffer的长度,再严格评估其真正的内存需求空间,而不是一上来就定义32字节/64字节/128字节。

还有一个方面,就是尽量考虑字节对齐的问题,定义结构体的时候,多考虑考虑。

最后的实践方案,省下了一半的空间。

再说下,当时我提出的实施方案,但是被按下的重构方案!

代码设计上:所有交易流程的判断处理,太过于死板,一个if-else判断到底,耦合严重,可扩展性非常差

代码设计上:LCD显示与核心业务流程跳转参杂在一起,没有解耦,往往改了业务功能的同时还要改UI实现

代码性能上:流程处理中,大量使用带超时时间的阻塞式函数,导致整个流程响应的时效性不是很理想

这三点,我认为都应该通过改善整体的代码架构来提升,下面简单说说的重构思路。

为了解决此类有业务处理流程,又有UI输入和UI显示的处理场景了,有一个比较成熟的软件模型,叫MVC模型。

MVC 模式代表 Model-View-Controller(模型-视图-控制器) 模式。

  • Model(模型) - 模型代表核心业务处理模块。它也可以带有逻辑,在数据变化时更新控制器。

  • View(视图) - 视图代表模型包含的数据的可视化,即UI部分。

  • Controller(控制器) - 控制器作用于模型和视图上。它控制数据流向模型对象,并在数据变化时更新视图。它使视图与模型分离开。

f2f7c0ffb4f5f0fbc9103a154529d213.png

根据这个理论模型,应用到我的工程上就是:

Controller:控制器,对应在这里就是,各式各样的事件监听器,把各种用户可能输入的方式抽象成一个个事件,而每个事件都有对应的监听器,当监听器识别到了对应事件的发生,立马触发事件给到模型层。

Model: 模型,这应该整个设计中代码最重的部分,主要是各个处理事件的处理,独立抽象成一个个模型,这些模型层互不干扰,也易于扩展,有新的事件需要处理就重新定义个模型即可。

View:视图,就是最简单的UI界面,它负责对Model提供的数据最UI界面的更新,比如刷新时间,比如显示倒计时,比如提示用卡信息等等。

它的整一个示意图如下所示:

ccd453a6d812a1b846e8ec0123772a24.png

应用MVC框架的最大好处就是把M和V分离开来,数据和视图解耦,使得数据易于处理并存储,同时也易于扩展,这里的扩展包括视图扩展和模型扩展,从一变N变得更加容易。

另外很重要的一点,在性能上,处理的实时性大大提升了,而不是简单的阻塞、延时这种粗暴的方法,取之而来的各种异步监听,快速响应,这一点我觉得在涉及到UI的应用场景下,都是应该要着重考虑的部分。

4. 更多思考

代码是无止境的,没有最好的代码实现,但是往往有更好的代码实现。

很多奇奇怪怪的BUG,在代码设计和代码编写阶段其实已经埋下了隐患,只不过短时间没有暴露出来而已。

这也就要求我们这些代码工作者,在敲代码之前,多想想设计思路,尽量把你的思路,你的流程通过图表的形式表达出来,

再不济,也应该要形成文档,以便于随时可以复盘你的代码实现是否偏离了你原本的设计。

毫不夸张地说,一个在设计阶段就有缺陷的代码架构,再怎么修饰也将于事无补。

这也是我目前转入软件架构师岗位,得出的最直接的心得。

最后愿这个世界的程序越来越强,BUG越来越少;

不过,这样的话,那我们岂不是要失业了?366933f3085e06c8320c70f8ff2a5a7e.png

72e3145cf20f48bda53063a14a60689f.png

你可以添加微信17775982065为好友,注明:公司+姓名,拉进RT-Thread官方微信交流群!

c2a4654ab4a318ccca20c9267c51e07c.gif

👇 点击阅读原文进入原帖

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值