這里說上面的代碼"爛"并不是說它工作得不行，相反，它的確工作得可以，從裝機量和各種行業(yè)認(rèn)證就可以看得出來，還是扛得住市場對它的考驗。這里提出它"爛"的原因，主要考慮是從代碼設(shè)計和代碼維護(hù)的角度來看。

3. 改善既有代碼的設(shè)計

3.1 改善代碼前的思考

大家都戲稱祖?zhèn)鞔a，請勿隨意改動，但我覺得真正優(yōu)秀的代碼，是慢慢被迭代，被重構(gòu)而來的，否則的代碼就會被一步步地堆砌起來，直到有一天，沒人能夠再修改維護(hù)了，那一刻就如同一棟大廈轟然倒塌，這是非常糟糕的。

正是基于這些的考慮，當(dāng)時我也是很大膽地向主管提出，我們應(yīng)該從小面積開始做代碼重構(gòu)，逐漸改善一些有缺陷的代碼設(shè)計。

比較遺憾的是，主管是相對保守的，沒有接受后面大面積重構(gòu)的實施，主要還是擔(dān)心期間的風(fēng)險，影響外面的程序升級。從商業(yè)的角度上，我是支持他的；但是，從代碼的角度，我還是堅持我的觀點；當(dāng)然這并不影響我們的共事。

3.2 我要如何改善這些代碼

先說下，主管答允我的小面積重構(gòu)部分，我是怎么做的！

【代碼維護(hù)上：全局變量全盤引用，亂串于各個文件中，可讀性非常差】

針對這一點，我重新整理了部分的C代碼規(guī)劃，明確要求非十分必要的設(shè)計，不允許全局變量在多個C文件中修改傳遞，盡量控制在一個C文件，同時關(guān)鍵的數(shù)據(jù)都封裝成get/set接口，減少通篇修改數(shù)據(jù)的可能性。

在code review環(huán)境，著重對此類代碼做重點審查，一經(jīng)發(fā)現(xiàn)，務(wù)必打回重新修改提交。

【代碼設(shè)計上：數(shù)據(jù)結(jié)構(gòu)沒有規(guī)劃設(shè)計，導(dǎo)致結(jié)構(gòu)體定義太復(fù)雜，太過龐然大物，冗余空間浪費大】

針對這一點，我的方法就是重新梳理，我們需要用到的必備數(shù)據(jù)，把所有非必須的數(shù)據(jù)全部刪除，同時一些數(shù)據(jù)buffer的長度，再嚴(yán)格評估其真正的內(nèi)存需求空間，而不是一上來就定義32字節(jié)/64字節(jié)/128字節(jié)。

還有一個方面，就是盡量考慮字節(jié)對齊的問題，定義結(jié)構(gòu)體的時候，多考慮考慮。

最后的實踐方案，省下了一半的空間。

再說下，當(dāng)時我提出的實施方案，但是被按下的重構(gòu)方案！

【

代碼設(shè)計上：所有交易流程的判斷處理，太過于死板，一個if-else判斷到底，耦合嚴(yán)重，可擴(kuò)展性非常差

代碼設(shè)計上：LCD顯示與核心業(yè)務(wù)流程跳轉(zhuǎn)參雜在一起，沒有解耦，往往改了業(yè)務(wù)功能的同時還要改UI實現(xiàn)

代碼性能上：流程處理中，大量使用帶超時時間的阻塞式函數(shù)，導(dǎo)致整個流程響應(yīng)的時效性不是很理想

】

這三點，我認(rèn)為都應(yīng)該通過改善整體的代碼架構(gòu)來提升，下面簡單說說的重構(gòu)思路。

為了解決此類有業(yè)務(wù)處理流程，又有UI輸入和UI顯示的處理場景了，有一個比較成熟的軟件模型，叫MVC模型。

MVC 模式代表 Model-View-Controller（模型-視圖-控制器） 模式。

• Model（模型） - 模型代表核心業(yè)務(wù)處理模塊。它也可以帶有邏輯，在數(shù)據(jù)變化時更新控制器。
• View（視圖） - 視圖代表模型包含的數(shù)據(jù)的可視化，即UI部分。
• Controller（控制器） - 控制器作用于模型和視圖上。它控制數(shù)據(jù)流向模型對象，并在數(shù)據(jù)變化時更新視圖。它使視圖與模型分離開。

根據(jù)這個理論模型，應(yīng)用到我的工程上就是：

Controller：控制器，對應(yīng)在這里就是，各式各樣的事件監(jiān)聽器，把各種用戶可能輸入的方式抽象成一個個事件，而每個事件都有對應(yīng)的監(jiān)聽器，當(dāng)監(jiān)聽器識別到了對應(yīng)事件的發(fā)生，立馬觸發(fā)事件給到模型層。

Model: 模型，這應(yīng)該整個設(shè)計中代碼最重的部分，主要是各個處理事件的處理，獨立抽象成一個個模型，這些模型層互不干擾，也易于擴(kuò)展，有新的事件需要處理就重新定義個模型即可。

View：視圖，就是最簡單的UI界面，它負(fù)責(zé)對Model提供的數(shù)據(jù)最UI界面的更新，比如刷新時間，比如顯示倒計時，比如提示用卡信息等等。

它的整一個示意圖如下所示：

應(yīng)用MVC框架的最大好處就是把M和V分離開來，數(shù)據(jù)和視圖解耦，使得數(shù)據(jù)易于處理并存儲，同時也易于擴(kuò)展，這里的擴(kuò)展包括視圖擴(kuò)展和模型擴(kuò)展，從一變N變得更加容易。

另外很重要的一點，在性能上，處理的實時性大大提升了，而不是簡單的阻塞、延時這種粗暴的方法，取之而來的各種異步監(jiān)聽，快速響應(yīng)，這一點我覺得在涉及到UI的應(yīng)用場景下，都是應(yīng)該要著重考慮的部分。

4. 更多思考

代碼是無止境的，沒有最好的代碼實現(xiàn)，但是往往有更好的代碼實現(xiàn)。

很多奇奇怪怪的BUG，在代碼設(shè)計和代碼編寫階段其實已經(jīng)埋下了隱患，只不過短時間沒有暴露出來而已。

這也就要求我們這些代碼工作者，在敲代碼之前，多想想設(shè)計思路，盡量把你的思路，你的流程通過圖表的形式表達(dá)出來，

再不濟(jì)，也應(yīng)該要形成文檔，以便于隨時可以復(fù)盤你的代碼實現(xiàn)是否偏離了你原本的設(shè)計。

毫不夸張地說，一個在設(shè)計階段就有缺陷的代碼架構(gòu)，再怎么修飾也將于事無補。

這也是我目前轉(zhuǎn)入軟件架構(gòu)師崗位，得出的最直接的心得。

最后愿這個世界的程序越來越強，BUG越來越少；

不過，這樣的話，那我們豈不是要失業(yè)了？

代碼性能上：流程處理中，大量使用帶超時時間的阻塞式函數(shù)，導(dǎo)致整個流程響應(yīng)的時效性不是很理想

代碼設(shè)計上：LCD顯示與核心業(yè)務(wù)流程跳轉(zhuǎn)參雜在一起，沒有解耦，往往改了業(yè)務(wù)功能的同時還要改UI實現(xiàn)

代碼設(shè)計上：所有交易流程的判斷處理，太過于死板，一個if-else判斷到底，耦合嚴(yán)重，可擴(kuò)展性非常差

代碼設(shè)計上：數(shù)據(jù)結(jié)構(gòu)沒有規(guī)劃設(shè)計，導(dǎo)致結(jié)構(gòu)體定義太復(fù)雜，太過龐然大物，冗余空間浪費大

代碼維護(hù)上：全局變量全盤引用，亂串于各個文件中，可讀性非常差

是否在規(guī)定的時間內(nèi)（一般60S）沒有任何的交易發(fā)生，導(dǎo)致超時？

是否按下了【取消鍵】，用戶主動退出了交易？

是否掃描到了微信/支付寶這類的支付條碼？（條碼支付與標(biāo)準(zhǔn)銀行卡交易是完全不一樣的流程）

是否使用了IC卡做非接觸交易（俗稱：揮卡）？（揮卡交易，走銀聯(lián)的IC卡快速交易，行內(nèi)稱qPBOC流程）

是否插入了IC卡？（插入IC卡，走銀聯(lián)的IC卡交易流程，行內(nèi)稱PBOC流程）

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

審核編輯：湯梓紅