T級互動是什麼
在討論如何對 T級互動進行開發提效前，我們先來定義什麼是 T 級互動。T 級互動是頭號互動的簡稱，區別於其他量級較小的 S 級互動，A 級互動等，具有流量大、金額多、時效性強的特點，往往集中在春節、618、雙十一這三個特殊的電商節點，爲集團拉動用戶增長，帶動轉化。T 級互動的最大特點是整合多端資源，需要對站內和微信端進行閉環，開發的時候需要進行 H5 和 小程序端同時進行，並且保證兩者體驗相近。其次就是打造全民私域，爲商家打造專屬頁面，提升流量。
T級互動需要我們注意什麼
T級互動如此多的內容，集合了雙端、私域，並且每次都會有不同的玩法，所以在開發階段需要保證，開發效率高、開發體驗好、雙端體驗一致；在測試階段，需要保證提測質量高，及時修復問題；在線上階段，要保證項目平穩運行，能不出錯就不出錯，如果出錯也有及時的糾錯機制，無法糾錯也要有及時的容錯和兜底機制。
所以我們可以得出，我們需要的東西爲雙端高效開發的工具、良好的開發體驗、及時修復問題的制度、保證項目平穩運行的制度，兜底和容錯。那我們下面將通過全民運動會、雙十一熱愛環遊記、2022炸年獸三個互動來對以上的內容進行闡述。
Taro —— 雙端高效開發工具
爲什麼需要
目前的電商環境下，僅僅是 APP 單端的開發已經無法滿足我們的需求，我們還需要在微信域內打通流程。而多端開發則存在着多個團隊分開開發、多技術棧共存、頁面表現形式不一、代碼重複等問題。所以我們需要轉變思路，從多個團隊用多個技術棧開發轉變爲多個團隊用一個優秀的技術棧進行合作開發。此舉解決了代碼高度重複、頁面體驗不一等問題之外，還保證了不同團隊間人員可以相互幫助，通力合作，也解決了部分人效問題。
Taro 爲我們提供了什麼
Taro 作爲多端開發屆的優秀框架，已經完全可以勝任一個大型互動的開發。但是如果想要在京購小程序中正常運行，還需要做一些適當的調整。我們這邊提供了一款插件可以使 Taro3 項目在京購小程序中運行——《使用Taro3將項目作爲獨立分包運行在京購小程序中》
上述插件解決了在小程序端開發過程中的一些問題，但是依然存在很多問題是需要我們繼續探索解決的。
我們在2021年的618互動中首先使用了此插件，當時插件代碼是包含在項目中的，開發過程中需要同時運行項目本身以及京購小程序項目，我們會將自身項目中編譯好的內容通過插件複製到京購項目中，利用京購項目中的環境進行運行，開發以及測試。在京東運動會的項目中延續了此方法，並且爲了提高複用效率，將代碼抽成 Taro3 的插件，可以在任何 Taro3 的項目中使用。
我們遇見了什麼問題
但是在雙十一熱愛環遊記項目中，我們遇見了操作系統的兼容性問題，在部分開發者的 Windows 系統中，插件無法正常運行。在解決兼容性問題的同時，爲了提升開發效率，對我們的開發模式進行了調整。插件的存在是爲了能夠正常使用京購小程序中的功能，但是這部分的使用場景在項目中是較少的，所以我們可以暫時擺脫對京購小程序的依賴，使項目能夠單獨在開發者工具中運行。
調整的方法非常簡單，我們原本通過插件引用了京購小程序中模塊的相對路徑，爲了擺脫這個依賴，可以在項目中建立一個虛擬的京購小程序文件夾，使得我們打包出來的相對路徑可以指向項目中的虛擬文件夾。而在這個文件夾中，只需要建立對應路徑下的空函數，使得路徑可以指向對應方法即可。
這個開發方法的優勢就是可以不用管操作系統的區別，不論是 Windows 還是 macOS 都可以正常運行項目，以及獨立運行使得只需要編譯一次即可運行，縮短了編譯的路徑，加快了開發和調試的速度。缺點也是顯而易見，無法調試京購小程序中的功能。
但是通過這一步，我們還是暫時性解決了開發問題，能夠讓我們的流程順利進行下去。並且在炸年獸的互動開發前完善了插件，使得後續開發更加高效。
同時 Taro3 正在着手升級 Webpack5，利用 Webpack5 中的 Module Federation，我們在後續的開發中可以完全不依賴於本地京購小程序的代碼，而是直接遠程引用它的功能模塊，幫助我們進一步提升開發效率。
業務組件庫 —— 複用代碼以解決人效問題
我們的下一個問題是什麼
我們現在手頭已經有了一款優秀的雙端開發工具，並且有了適合業務的插件，大大提升了我們的開發效率和體驗。但是 T 級互動的開發週期短，開發內容多依然是我們的需要面對的問題。其實活多時間少，人手不足並不是我們互動獨有的特點，大多數業務中大家都會遇見這樣的問題。但是 T 級互動的流量與影響力放大了問題。那麼我們不得不重視起來。
一個 T 級互動往往需要大約 90 到 100 人日的開發時長，也就是說 3 個開發同時進行也需要 30 個工作日。但是一個大型互動的想法討論到交互設計最後到視覺落地，往往也需要較長的時間，最後到開發的工作時長往往都是不足 30 個工作日。那麼接下來發生的事情可想而知，或是加班解決問題，或是低質量交付任務，亦或是兩者都會發生。但這並不是我們想要的。
那麼解決人效問題就成了我們的當務之急。
如何解決人效問題
解決問題的直接方法無非兩種，在現有時間內，要麼增加人手，要麼提升個人開發效率。直接看來，增加人手是最簡單有效的方法。其實不然，增加了不熟悉項目的成員，他需要花大量的時間去學習項目的開發模式、技術棧、原有代碼與工作流程。這些其實都是隱性的時間成本。所以我們如果要解決問題，還是要提升個人開發效率，並且對新來的人員能夠非常友好。
那麼我們就想到了一個大多數開發都做過的事情——組件化。
組件化來提升效率已經是老生常談了，但是結果往往都不盡如人意，最後也無疾而終。而爲了避免出現這喫力不討好的情況，我們先來磨一磨柴刀，而不是直接動手開做。
組件化的問題往往出現在兩個地方，一是組件複用率不高，有些組件開發了沒人用；二是難以將“通用”與“好用”結合，往往好用的不通用，通用的不好用。
但是從 T 級互動出發的業務組件並沒有太多這樣的煩惱。首先是複用率，在多次 T 級互動之後，從設計到開發，都對於互動模式有了大致的把握，很多模塊從交互到視覺風格都是非常固定的，那麼我們可以從中找到基本上每次都會用到的“勞模”模塊進行組件化。其次是我們在業務組件中可以不那麼考慮一個組件的拓展性和通用性，它主要是服務於業務，好用纔是它的根本需求。
那麼根據上述的思考，我們可以得到我們的結論了——根據多次 T 級互動的經驗，找出重複模塊，在保證主體功能和交互都固定的情況下進行復用改造。
組件庫開發一二三
一自然是挑選出我們需要開發哪些組件，具體的就不多談了。只說我們將組件分爲了，含 UI 與不含 UI 兩個大類，而不含 UI 的又分爲業務邏輯，非業務邏輯，純功能函數等。這些組件是通過針對過去互動中模塊出現次數進行統計的。
二是選擇技術棧，不用多說，肯定是 Taro 打頭陣；然後爲了提升開發出組件的質量，自動化測試也要跟上，團隊內的另一款雙端自動化測試產品 Tiga 緊隨其後；隨後爲了能夠對組件進行輕量化打包，我們選擇了 Rollup 作爲快捷打包工具；最後的最後，使用 lerna 對這些組件進行統一管理，讓他們擁有統一的依賴，統一管理版本與發佈。具體的實現內容和代碼就不在此處貼出來了。僅僅是根據技術棧的選擇表現組件庫的開發流程。
三是最不起眼但是卻是一個組件庫最靈魂的內容——文檔。許多開發一提起文檔就頭疼，往往都是寫完代碼忘記文檔，寫完文檔忘記更新。沒有文檔對於一個組件庫來說是致命的，沒有文檔的組件等於沒有開發的組件。使用者不知道有沒有想要的組件，也不知道去哪裏看，最後導致組件複用率低或者重複開發。最後還來一句，組件庫真難用，誰想的這餿主意，還不如複製代碼。
而一二三這三步並非是我們做了就行，而是三步都做好，才能避免一個組件庫最後淪爲雞肋。
牛刀小試
當然我們上面長篇大論了一堆，沒有一個結果拿出手大家肯定是不服氣的。經過零零碎碎兩個月的組件化開發，我們在第一批的時候沉澱了十個組件，在年貨節互動中使用了其中七個，節約了 10 人日以上，保證了我們的人員有充足的時間在年貨節項目之餘還支持了春晚合作項目。由此可見，我們的組件庫初見成效。
糾錯與兜底
上述的兩部分內容已經很大程度上緩解了我們的人效問題，說解決還是有一定的距離，依舊需要不斷優化和探索。那我們要轉頭關注一下另一個問題——缺陷。
基本上可以說不存在沒有 bug 的項目，但是要看 bug 會不會被發現，被發現的 bug 多不多，嚴重不嚴重。我們多次強調了大型互動的繁雜內容和巨大流量，繁雜的內容意味着很多地方，很多可能性，是自測與測試會遺漏的；巨大的流量則會給我們的玩家羣體很多找 bug 的機會。兩者結合便成了我們最害怕的線上問題與客訴。
第一次面臨巨大問題是在京東運動會的互動上，在凌晨出現了長達 45 分鐘的白屏情況。究其原因，是上游數據下發錯誤，而前端未對錯誤進行兜底，導致了頁面報錯。沒錯，一個成熟的開發已經明白過來了，我們趕緊甩鍋給上游（不是）。而是我們應該趕緊解決問題，讓頁面最快速度恢復正常。隨後分析問題並且改進。
而怎麼分析又該怎麼改進呢？
我們看一下線上問題出現的兩個步驟：第一是上游數據突然錯誤，那麼爲何平穩運行了多天的項目突然數據錯誤？原來是數據在每日 0 點都會有更新，剛好更新了一批錯誤的；第二則是前端沒有對錯誤的數據做好兜底，代碼健壯性不足，本來只需隱藏部分模塊的變成了整個頁面報錯。
先從第一步下手，我們不能去要求上游不出問題，那該怎麼辦呢？只能是自己看好自家娃，在 0 點切換數據的時候，作爲爹孃的我們需要在線值班，檢查頁面所有功能，看完了再安安心心睡覺去。如果出了問題也能及時糾錯，讓頁面恢復正常。
第二步就有點玄乎了，提升代碼健壯性。這話誰都會說，但是事情做起來卻未必，我們不能對於自己的代碼過分自信，於是我們給我們的樓層上都包裹了一層兜底組件，捕捉樓層內報錯並隱藏樓層。當然了，這個方法是針對線上問題的好方法，但並非是作爲開發者的終極策略，作爲開發者來說真正能夠解決問題的應當是提升自身代碼水平，考慮周全，全面自測，避免過分自信。
雙管齊下後，我們在後續的雙十一，年貨節，春晚項目中都避免了嚴重線上問題與客訴。
從棘手到發光
剛開始的 T 級互動開發總是揹着重重的龜殼，蹣跚前行。面對種種問題，我們往往是加班加點，拆東牆補西牆，做完一個項目，缺陷多不說，開發者也已經累得不行，最後只想着趕緊休假。隨着項目的覆盤與開發體驗意識崛起，我們明白了，用戶體驗是我們的目標，但是開發體驗也是我們的目標。只有好的開發體驗才能帶給我們更高效的工作流，更輕鬆的工作體驗。而這種高效往往意味着我們最後會產出更高質量的代碼與空出更多的時間去進行優化。
所以老話總說磨刀不誤砍柴工，而我們往往是一邊磕磕絆絆砍柴一邊抱怨沒有時間磨刀。不如停下來看看爲什麼任務總在後面追，而我們總是彷彿深陷泥潭邁不開步子。
從一個難題到一個值得寫在開發生涯裏的經歷，我們所費的不過是認真思考，花點功夫，找題解題，而不是一句“道理我都懂”。