一、引子

回顧曾在開放平台工作台的三年，發現自己主要是寫業務為主。雖然和同伴們一起參與主導過從組件化到平台化、配置化到定製化的能力建設，但更多的精力也參與在客户拜訪、ISV培訓、數據分析和業務決策，這讓我有了對業務方向的提前感知和判斷，使得在技術側能夠前置準備，更好的服務業務目標。能力建設上沒有什麼阻力，反而省去了很多描寫技術的筆墨。

其實想想，作為一名普通程序員，也許我寫什麼並不值得別人重視，但對自己也許挺重要。因為這説明我有自己的思想和好惡。如果沒有這些，也便沒什麼意思。另外作為普通員工，我也想改改以往寫東西時那種有點貌似全局視角和方正規矩的風格，例如像《OA審批支持釘釘套件業務的探索和思考》、《釘釘工作台走向平台開放的探索和思考》、《釘釘工作台開放能力建設階段性總結》，想着着眼處應該可以放得更細微一些，風格上可以更隨性一些。譬如朝露，去日苦多，何必那麼時刻嚴肅呢。

二、要還債

主要近期經常聽人説道，被一些歷史悠久的代碼所坑。架構調整，人員更迭，種種原因，代碼問題既無記錄也無説明，每天在這樣的代碼裏挖呀挖呀挖，挖到的一定不是顆珍珠。這些也許該被稱為技術債務吧。

技術債務有不少教科書介紹過怎麼分類以及針對每一類該持有的態度。我僅從個人經驗來嘗試理解下起因：

第一類，是善意所為。原本會有一個更優的方案，但由於當下時間、成本等方面限制，權衡決策選擇了降級。可能損失了一定的擴展性，但帶來了性價比，也為業務爭取了時間。通常在業務需要快速驗證、需求有時間限制或設計新的架構時出現。決策者很清楚現在有什麼問題，未來將帶來什麼問題，影響到什麼，從而在方案中也會考慮未來逐步去演進的計劃。什麼情況該補償什麼，哪些可以暫時先不做但什麼情況下需要做，短期長期通盤考慮，只要比影響到來提前那麼一點點完善就好。

這一類留下的債務，如果有人跟蹤，通常能在後期進行有計劃的迭代償還，有點類似於還房貸，還可以選擇還款方式是等額本息還是提前結清呢。但困難的是，團隊需要將代碼設計思想傳承。如果前面的人輕輕的走了，不留下一片雲彩，後來的人沒有了解到代碼設計進化的方向，不能追蹤，這就成了壞賬。

第二類，是無心之失。在編碼時是實現了功能，但並沒考慮到對未來或全局的影響或者考慮不夠周全。產品驗收測試是看不出任何問題的，短期內或者代碼不迭代也反映不出什麼問題。經過一定時間的需求迭代後，路遙日久，則可能由於擴展性耦合性等原因，變更舉步維艱。

這第三類，權且稱為有意失之吧。且就看眼下，能快速完成，這不僅能得到點贊，還省心省事呢。以後的影響，呵呵，誰知會影響到誰呢，何必現在花這麼大心力去自尋苦惱呢。

去年中我從工作台調到了OA，這是個老牌應用，過去幾年經歷幾度調整經歷過大規模的人員更迭。在我看來，好的代碼就像詩歌、音樂，有種天然的節奏感和韻律感，彷彿眼前出現一位仙女，凌波微步，羅襪生塵，吸引你緊跟上去。反之，則似盲人摸象，看不清猜不透陷入泥沼之中。OA裏有好的代碼，但也有好多年前的遺留，剛看到時也是有種要還債了的感覺。

但大流量業務，穩定性壓倒一起，沒有技術文檔存留、也沒有口口相傳的心法，先得靜默觀察，不宜亂動。遇到問題先記下來，這樣就積累了一張技術債的表。當然新的一年裏，我們也積累了很多新需求的技術方案，這樣可讓後面來的人有跡可循，萬一要還債也會輕鬆一些。

三、等風來

若是平白無故的發起一個重構，在業務團隊，幾乎不可能，除非是可能引發或已發生重大故障了，要對應處理。債務表裏已經有了不少了，方案也思慮過一些了，萬事俱備，只欠東風。風是什麼呢，可能就是日常的迭代需求和團隊共識吧。如若團隊沒有這樣的共識，又不夠開放，這樣的想法可能只會使自己處於一個細草微風岸，危檣獨夜舟的境地了。如何判斷風向和風級，可能就是仁者見仁的事情了。

四、風的感覺

我們曾經確實歷經三年堅持代碼翻新，消滅了遠古代碼，之後再沒產生過線上故障，需求完成效率也上來了。可以感受下。日常迭代的微重構，有很多：

• 例如設計師對第三方的組件UI做了設計升級，技術側趁機使用配置化來快速實現組件的標題欄和外框樣式，而不需要每個接入的第三方組件都去開發一遍。以後外觀樣式變化也可底座統一調適。
• 例如要新增一種應用列表組件，技術趁機將原有的6種應用列表類組件整合重構成一個組件，通過配置實現多種多樣的新組件。
• 例如在對打開應用的功能增加新需求時，技術重構了原嵌套十幾層的條件語句代碼，後面還升級為了釘釘的通用組件。

日常迭代的需求(小風)，像是東風的會有些特點：

1.較小投入，可以讓完成本次需求變得更容易，以後再修改也方便。

2.修改範圍不大，有明顯影響邊界，項目管理風險和線上穩定性風險都可控。

3.完成的人心曠神怡，帶來愉悦感受。 大的風口也有：

• 我們曾經在移動端工作台支持客户定製的需求中，完成了移動端首頁的架構升級，合併海外工作台、定製工作台、行業工作台等不同代碼項目到統一的一個移動端底座項目。由原來維護多個項目，到只維護一個，減少了成倍的開發維護成本。
• 我們曾經在PC端工作台和移動端一樣支持定製的需求中，完成了PC首頁遠古代碼的架構升級，頁面schema化、組件化。和移動端數據邏輯層複用，配置管理頁面多端複用一套。同樣降本提效。
• 我們曾經在UI體驗升級需求中，前後端配合實現首頁多級緩存降級方案，增強系統容災能力和穩定性並提升頁面訪問性能。這原本僅僅是一個UI層的需求呀，可能原本只需改改樣式呢。

這樣的需求，有些共同的特點(6級東風)：

1.需求涉及到待償還技術債中的部分，且升級方案有助於需求完成以及面向未來更加友好。
2.需求有一定時長的研發週期和灰度週期，增加容錯能力，減少本次重構或升級的上線風險。
3.多數情況通常都會動到數據模型，要項目組達成共識，前後端協同動作，口徑一致。

幾乎每年，產品上都會有一次大型的體驗升級、一次大型的功能升級，這也就是業務團隊技術同學的兩次機會了。抓住它，會很治癒。

五、迎着風

前面寫過一個見縫插針的在需求中完成一些力所能及的微重構的例子，例如 記一次迭代需求中的微型代碼重構 。這一次，可來了一個首頁導航升級需求。將首頁的二級導航升級到一級導航，並且給用户新功能引導。

那麼，藉着這次東風可以做什麼呢？

一是導航的配置化。可以通過配置實現在任何導航任何位置的紅點、提醒、數字角標等。見上圖右側。

這麼做的好處：

原導航代碼的風格是有提醒、角標什麼功能需求就寫死在代碼裏。每次需求一改，就需要修改代碼走發佈，週期長、耗人力。配置化後，可實現快速響應需求。

二是新功能引導的組件化和配置化。見上圖左側。

這麼做的好處：

1.統一掉散落在各個頁面的新功能引導組件，實現頁面間組件可複用。原來多個頁面上都寫過類似的功能，每次上新功能，都重寫一份兒。再手動下掉或者乾脆留着無用的代碼。

2.統一掉新功能引導組件的邏輯。例如：a.點擊組件的關閉，則本組件不再出現，本地持久化b.點擊頁面的跳轉，則不再出現，本地持久化c.組件曝光超過天數，則不再出現，本地持久化。可配置曝光天數d.可配置是否僅老用户可見

e.引導的內容可配置

3.將容易修改的部分配置化，無需發佈，實現快速線上變更。例如有些引導僅對老用户可見，有些新老用户一視同仁。有些要求曝光3天，有些要曝光一個月。這些差異化，都可通過配置來實現。

想改下寫作習慣，卻寫得有點凌亂，果然是放任自己很容易，找回自己很難。希望自己不要氣餒，再接再厲。這篇一不小心這麼長，那麼進一步的技術方案細節，如果有必要的話，就放在後續再聊。

露沾枝葉重，水漫泥徑斜。雨打花飛落，風吹草木折。池魚聽風起，林鳥曲低合。月明星尤寂，不識異鄉客。

作者｜單丹

原文鏈接

本文為阿里雲原創內容，未經允許不得轉載。