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 代碼片段

為了僅說明情況，而不透露具體的技術細節，這里我僅提供偽代碼，注意代碼里的注釋，是我為了輔助介紹而自己添加的，原來的代碼中，注釋比這少得可憐。

1. /**
2. * 保存交易記錄的結構體定義
3. */
4. typedef struct _transaction_log_t {
5. char time_stamp[32];
6. uint8_t trans_type;
7. uint8_t trans_no;
9. /* 各式各樣的數據定義長達20-30個變量 */
10. uint8_t data1[64];
11. ...
12. uint8_t datan[128];
13. } transaction_log_t;
15. /* 全局的交易log變量，被各個處理流程的文件引用 */
16. transaction_log g_log_info;
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
26. /**
27. * 處理交易的流程總入口
28. */
29. int all_transaction_process(int timeouts_ms, int transaction_flag)
30. {
31. int start_time, end_time;
33. end_time = 0;
34. start_time = get_local_time();
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. }
72. end_time = get_local_time();
73. if (start_time + timeous_ms == end_time) {
74. /* timeout */
75. return -1;
76. }
78. /* 界面顯示倒計時 */
79. lcd_update_timetous();
81. /* 循環延時 */
82. delay_ms(10);
83. }
84. }
86. /**
87. * main函數總入口
88. */
89. int main(int argc, const char *argv[])
90. {
91. /* 應用初始化 */
92. system_init();
94. /* 處理備份及系統異常斷電引發的沖正交易 */
95. handle_bakup();
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. }
112. /* 刷新顯示在LCD上的時間 */
113. update _time_dispaly();
114. }
116. return 0;
117. }

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流程）

是否刷了磁條卡？（刷了磁條卡，走刷磁條卡的交易流程）

審核編輯：湯梓紅