【RT-Thread】show-me-bad-code
1. 题外话 在本活动开始之前，非常荣幸地收到rrt小师弟的邀请， 看能否帮忙想想1024程序员节的论坛活动好点子，在此非常感谢对我的信任。 想起早年在浏览一些博文的时候，对国外代码社区举办的烂代码比赛印象深刻， 看到那些牛人提交的眼花缭乱的bad-but-work-well的代码，简直是佩服得五体投地。 自然我们大部分的程序员还很难提供出这么秀的代码， 所以基于这个原则，结合我们的实际情况， 修改了下比赛规则，重在娱乐参与，旨在代码提升。
更多关于此次show-me-bad-code活动的介绍，请点击这里。
2. 我来提供一段代码 2.1 代码背景 这段代码的原型来自于早几年在一家pos行业内头部企业供职时的真实案例代码，基于这套代码也是过了各种pos机的行业认证， 经过10多年的沉淀，基于该模板代码移植/改造而来的应用程序，罐装的pos机累计装机量应该在kw级别，可谓就是传说中妥妥的【祖传代码】。
早期代码的运行环境是嵌入式linux系统，总内存高达128mb，还是非常富余的；后面才慢慢切为rtos系统，内存也锐减到64mb，但即便这样，给到应用程序的内存也是非常充足的。
2.2 代码功能 这段代码的主要功能就是在pos机触发交易时的界面（带lcd显示）下，能够自动识别出当前要使用的各种交易方式，其中包括：
除这些功能外，因为pos机交易是需要保存最近n笔交易记录的，所以这个处理交易的流程中，还得维护交易记录的保存。而代码中用于保存交易记录的结构体也是非常非常非常的庞大，大到一个结构体就占用接近2kb，这是非常恐怖的。
2.3 代码片段 为了仅说明情况，而不透露具体的技术细节，这里我仅提供伪代码，注意代码里的注释，是我为了辅助介绍而自己添加的，原来的代码中，注释比这少得可怜。
/** * 保存交易记录的结构体定义 */ typedef struct _transaction_log_t { char time_stamp[32]; uint8_t trans_type; uint8_t trans_no; /* 各式各样的数据定义长达20-30个变量 */ uint8_t data1[64]; ... uint8_t datan[128]; } transaction_log_t; /* 全局的交易log变量，被各个处理流程的文件引用 */ transaction_log g_log_info; /** * 支持的交易方式的掩码 */ #define transaction_swipe_card 0x01 #define transaction_insert_card 0x02 #define transaction_tap_card 0x04 #define transaction_code_pay 0x08 /** * 处理交易的流程总入口 */ int all_transaction_process(int timeouts_ms, int transaction_flag) { int start_time, end_time; end_time = 0; start_time = get_local_time(); /* 循环判断需要支持的交易方式，直到触发了某种交易或者超时 */ while (1) { if (transaction_flag & transaction_swipe_card) { /* 判断刷卡：阻塞式的接口，带超时时间 */ ret = get_swipe_card(10); if (ret == ok) { /* 处理刷卡流程 */ ... return 0; } } else if (transaction_flag & transaction_swipe_card) { /* 判断插卡：阻塞式接口，带超时时间 */ ret = get_insert_card(10); if (ret == ok) { /* 处理插卡流程 */ ... return 0; } } else if (transaction_flag & transaction_swipe_card) { /* 判断挥卡：阻塞式接口，带超时时间 */ ret = get_tap_card(10); if (ret == ok) { /* 处理挥卡流程 */ ... return 0; } } else if (transaction_flag & transaction_swipe_card) { /* 判断条码支付 */ ret = get_code(10); if (ret == ok) { /* 处理条码流程 */ ... return 0; } } end_time = get_local_time(); if (start_time + timeous_ms == end_time) { /* timeout */ return -1; } /* 界面显示倒计时 */ lcd_update_timetous(); /* 循环延时 */ delay_ms(10); } } /** * main函数总入口 */ int main(int argc, const char *argv[]) { /* 应用初始化 */ system_init(); /* 处理备份及系统异常断电引发的冲正交易 */ handle_bakup(); /* main loop */ while (1) { /* 每10ms获取下当前有没有按键触发交易 */ key = get_key_ms(10); if (key1 == key) { /* 有触发交易需求 */ ret = all_transaction_process(60*1000, ); } else if (key2 == key) { /* 其他菜单操作 */ ... } else { /* 超时或未知按键输入 */ ... } /* 刷新显示在lcd上的时间 */ update _time_dispaly(); } return 0; } 2.4 烂的理由 这里说上面的代码烂并不是说它工作得不行，相反，它的确工作得可以，从装机量和各种行业认证就可以看得出来，还是扛得住市场对它的考验。这里提出它烂的原因，主要考虑是从代码设计和代码维护的角度来看。
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（控制器） - 控制器作用于模型和视图上。它控制数据流向模型对象，并在数据变化时更新视图。它使视图与模型分离开。 根据这个理论模型，应用到我的工程上就是：
controller：控制器，对应在这里就是，各式各样的事件监听器，把各种用户可能输入的方式抽象成一个个事件，而每个事件都有对应的监听器，当监听器识别到了对应事件的发生，立马触发事件给到模型层。
model: 模型，这应该整个设计中代码最重的部分，主要是各个处理事件的处理，独立抽象成一个个模型，这些模型层互不干扰，也易于扩展，有新的事件需要处理就重新定义个模型即可。
view：视图，就是最简单的ui界面，它负责对model提供的数据最ui界面的更新，比如刷新时间，比如显示倒计时，比如提示用卡信息等等。
它的整一个示意图如下所示：
应用mvc框架的最大好处就是把m和v分离开来，数据和视图解耦，使得数据易于处理并存储，同时也易于扩展，这里的扩展包括视图扩展和模型扩展，从一变n变得更加容易。
另外很重要的一点，在性能上，处理的实时性大大提升了，而不是简单的阻塞、延时这种粗暴的方法，取之而来的各种异步监听，快速响应，这一点我觉得在涉及到ui的应用场景下，都是应该要着重考虑的部分。
4. 更多思考 代码是无止境的，没有最好的代码实现，但是往往有更好的代码实现。
很多奇奇怪怪的bug，在代码设计和代码编写阶段其实已经埋下了隐患，只不过短时间没有暴露出来而已。
这也就要求我们这些代码工作者，在敲代码之前，多想想设计思路，尽量把你的思路，你的流程通过图表的形式表达出来，
再不济，也应该要形成文档，以便于随时可以复盘你的代码实现是否偏离了你原本的设计。
毫不夸张地说，一个在设计阶段就有缺陷的代码架构，再怎么修饰也将于事无补。
这也是我目前转入软件架构师岗位，得出的最直接的心得。
最后愿这个世界的程序越来越强，bug越来越少；
不过，这样的话，那我们岂不是要失业了？
代码性能上：流程处理中，大量使用带超时时间的阻塞式函数，导致整个流程响应的时效性不是很理想
代码设计上：lcd显示与核心业务流程跳转参杂在一起，没有解耦，往往改了业务功能的同时还要改ui实现
代码设计上：所有交易流程的判断处理，太过于死板，一个if-else判断到底，耦合严重，可扩展性非常差
代码设计上：数据结构没有规划设计，导致结构体定义太复杂，太过庞然大物，冗余空间浪费大
代码维护上：全局变量全盘引用，乱串于各个文件中，可读性非常差
是否在规定的时间内（一般60s）没有任何的交易发生，导致超时？
是否按下了【取消键】，用户主动退出了交易？
是否扫描到了微信/支付宝这类的支付条码？（条码支付与标准银行卡交易是完全不一样的流程）
是否使用了ic卡做非接触交易（俗称：挥卡）？（挥卡交易，走银联的ic卡快速交易，行内称qpboc流程）
是否插入了ic卡？（插入ic卡，走银联的ic卡交易流程，行内称pboc流程）
是否刷了磁条卡？（刷了磁条卡，走刷磁条卡的交易流程）
龙芯助力开发真正自主SSD主控
三季度六氟磷酸锂最高价格有望突破40万/吨
iPhone8生产遇大尴尬：可能苹果8要延迟发布
Mini/Micro LED的“走红”让LED屏企们看到市场的巨大增量空间
工业智能网关BL110应用之三：功能特点
【RT-Thread】show-me-bad-code
一文看懂五类线、超五类线和六类线的区别
百度投资一家新建人脸识别公司 最终受益人为李彦宏
中国发展高层论坛2018年会在毕竟举行，探讨人工智能产业推进措施
USB调试注意事项
食品检验仪器设备清单都有哪些配件
华为云云耀云服务器 L 实例，助力千行百业轻松上云
诺基亚3、诺基亚5、诺基亚6、诺基亚3310夺回市场噱头，诺基亚8依然蔡司或配双摄！情怀杠杠滴
适用于TI处理器的可扩展Linux和TI RTOS解决方案
NASA欲利用人工智能探测外星生命
光电开关在纺织设备上的应用简述
为什么有些音圈电机模组是黑色，而有些是白色？
苹果iOS10.2.1Beta4测试版更新，是为了防止iOS10.2越狱？
苹果承认部分iPhone11存在触摸问题
红外接收二极管接收光的多少和输出信号的关系？
更多关于此次show-me-bad-code活动的介绍，请点击这里。
2. 我来提供一段代码 2.1 代码背景 这段代码的原型来自于早几年在一家pos行业内头部企业供职时的真实案例代码，基于这套代码也是过了各种pos机的行业认证， 经过10多年的沉淀，基于该模板代码移植/改造而来的应用程序，罐装的pos机累计装机量应该在kw级别，可谓就是传说中妥妥的【祖传代码】。
早期代码的运行环境是嵌入式linux系统，总内存高达128mb，还是非常富余的；后面才慢慢切为rtos系统，内存也锐减到64mb，但即便这样，给到应用程序的内存也是非常充足的。
2.2 代码功能 这段代码的主要功能就是在pos机触发交易时的界面（带lcd显示）下，能够自动识别出当前要使用的各种交易方式，其中包括：
除这些功能外，因为pos机交易是需要保存最近n笔交易记录的，所以这个处理交易的流程中，还得维护交易记录的保存。而代码中用于保存交易记录的结构体也是非常非常非常的庞大，大到一个结构体就占用接近2kb，这是非常恐怖的。
2.3 代码片段 为了仅说明情况，而不透露具体的技术细节，这里我仅提供伪代码，注意代码里的注释，是我为了辅助介绍而自己添加的，原来的代码中，注释比这少得可怜。
/** * 保存交易记录的结构体定义 */ typedef struct _transaction_log_t { char time_stamp[32]; uint8_t trans_type; uint8_t trans_no; /* 各式各样的数据定义长达20-30个变量 */ uint8_t data1[64]; ... uint8_t datan[128]; } transaction_log_t; /* 全局的交易log变量，被各个处理流程的文件引用 */ transaction_log g_log_info; /** * 支持的交易方式的掩码 */ #define transaction_swipe_card 0x01 #define transaction_insert_card 0x02 #define transaction_tap_card 0x04 #define transaction_code_pay 0x08 /** * 处理交易的流程总入口 */ int all_transaction_process(int timeouts_ms, int transaction_flag) { int start_time, end_time; end_time = 0; start_time = get_local_time(); /* 循环判断需要支持的交易方式，直到触发了某种交易或者超时 */ while (1) { if (transaction_flag & transaction_swipe_card) { /* 判断刷卡：阻塞式的接口，带超时时间 */ ret = get_swipe_card(10); if (ret == ok) { /* 处理刷卡流程 */ ... return 0; } } else if (transaction_flag & transaction_swipe_card) { /* 判断插卡：阻塞式接口，带超时时间 */ ret = get_insert_card(10); if (ret == ok) { /* 处理插卡流程 */ ... return 0; } } else if (transaction_flag & transaction_swipe_card) { /* 判断挥卡：阻塞式接口，带超时时间 */ ret = get_tap_card(10); if (ret == ok) { /* 处理挥卡流程 */ ... return 0; } } else if (transaction_flag & transaction_swipe_card) { /* 判断条码支付 */ ret = get_code(10); if (ret == ok) { /* 处理条码流程 */ ... return 0; } } end_time = get_local_time(); if (start_time + timeous_ms == end_time) { /* timeout */ return -1; } /* 界面显示倒计时 */ lcd_update_timetous(); /* 循环延时 */ delay_ms(10); } } /** * main函数总入口 */ int main(int argc, const char *argv[]) { /* 应用初始化 */ system_init(); /* 处理备份及系统异常断电引发的冲正交易 */ handle_bakup(); /* main loop */ while (1) { /* 每10ms获取下当前有没有按键触发交易 */ key = get_key_ms(10); if (key1 == key) { /* 有触发交易需求 */ ret = all_transaction_process(60*1000, ); } else if (key2 == key) { /* 其他菜单操作 */ ... } else { /* 超时或未知按键输入 */ ... } /* 刷新显示在lcd上的时间 */ update _time_dispaly(); } return 0; } 2.4 烂的理由 这里说上面的代码烂并不是说它工作得不行，相反，它的确工作得可以，从装机量和各种行业认证就可以看得出来，还是扛得住市场对它的考验。这里提出它烂的原因，主要考虑是从代码设计和代码维护的角度来看。
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（控制器） - 控制器作用于模型和视图上。它控制数据流向模型对象，并在数据变化时更新视图。它使视图与模型分离开。 根据这个理论模型，应用到我的工程上就是：
controller：控制器，对应在这里就是，各式各样的事件监听器，把各种用户可能输入的方式抽象成一个个事件，而每个事件都有对应的监听器，当监听器识别到了对应事件的发生，立马触发事件给到模型层。
model: 模型，这应该整个设计中代码最重的部分，主要是各个处理事件的处理，独立抽象成一个个模型，这些模型层互不干扰，也易于扩展，有新的事件需要处理就重新定义个模型即可。
view：视图，就是最简单的ui界面，它负责对model提供的数据最ui界面的更新，比如刷新时间，比如显示倒计时，比如提示用卡信息等等。
它的整一个示意图如下所示：
应用mvc框架的最大好处就是把m和v分离开来，数据和视图解耦，使得数据易于处理并存储，同时也易于扩展，这里的扩展包括视图扩展和模型扩展，从一变n变得更加容易。
另外很重要的一点，在性能上，处理的实时性大大提升了，而不是简单的阻塞、延时这种粗暴的方法，取之而来的各种异步监听，快速响应，这一点我觉得在涉及到ui的应用场景下，都是应该要着重考虑的部分。
4. 更多思考 代码是无止境的，没有最好的代码实现，但是往往有更好的代码实现。
很多奇奇怪怪的bug，在代码设计和代码编写阶段其实已经埋下了隐患，只不过短时间没有暴露出来而已。
这也就要求我们这些代码工作者，在敲代码之前，多想想设计思路，尽量把你的思路，你的流程通过图表的形式表达出来，
再不济，也应该要形成文档，以便于随时可以复盘你的代码实现是否偏离了你原本的设计。
毫不夸张地说，一个在设计阶段就有缺陷的代码架构，再怎么修饰也将于事无补。
这也是我目前转入软件架构师岗位，得出的最直接的心得。
最后愿这个世界的程序越来越强，bug越来越少；
不过，这样的话，那我们岂不是要失业了？
代码性能上：流程处理中，大量使用带超时时间的阻塞式函数，导致整个流程响应的时效性不是很理想
代码设计上：lcd显示与核心业务流程跳转参杂在一起，没有解耦，往往改了业务功能的同时还要改ui实现
代码设计上：所有交易流程的判断处理，太过于死板，一个if-else判断到底，耦合严重，可扩展性非常差
代码设计上：数据结构没有规划设计，导致结构体定义太复杂，太过庞然大物，冗余空间浪费大
代码维护上：全局变量全盘引用，乱串于各个文件中，可读性非常差
是否在规定的时间内（一般60s）没有任何的交易发生，导致超时？
是否按下了【取消键】，用户主动退出了交易？
是否扫描到了微信/支付宝这类的支付条码？（条码支付与标准银行卡交易是完全不一样的流程）
是否使用了ic卡做非接触交易（俗称：挥卡）？（挥卡交易，走银联的ic卡快速交易，行内称qpboc流程）
是否插入了ic卡？（插入ic卡，走银联的ic卡交易流程，行内称pboc流程）
是否刷了磁条卡？（刷了磁条卡，走刷磁条卡的交易流程）
龙芯助力开发真正自主SSD主控
三季度六氟磷酸锂最高价格有望突破40万/吨
iPhone8生产遇大尴尬：可能苹果8要延迟发布
Mini/Micro LED的“走红”让LED屏企们看到市场的巨大增量空间
工业智能网关BL110应用之三：功能特点
【RT-Thread】show-me-bad-code
一文看懂五类线、超五类线和六类线的区别
百度投资一家新建人脸识别公司 最终受益人为李彦宏
中国发展高层论坛2018年会在毕竟举行，探讨人工智能产业推进措施
USB调试注意事项
食品检验仪器设备清单都有哪些配件
华为云云耀云服务器 L 实例，助力千行百业轻松上云
诺基亚3、诺基亚5、诺基亚6、诺基亚3310夺回市场噱头，诺基亚8依然蔡司或配双摄！情怀杠杠滴
适用于TI处理器的可扩展Linux和TI RTOS解决方案
NASA欲利用人工智能探测外星生命
光电开关在纺织设备上的应用简述
为什么有些音圈电机模组是黑色，而有些是白色？
苹果iOS10.2.1Beta4测试版更新，是为了防止iOS10.2越狱？
苹果承认部分iPhone11存在触摸问题
红外接收二极管接收光的多少和输出信号的关系？