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 級互動開發總是揹著重重的龜殼，蹣跚前行。面對種種問題，我們往往是加班加點，拆東牆補西牆，做完一個專案，缺陷多不說，開發者也已經累得不行，最後只想著趕緊休假。隨著專案的覆盤與開發體驗意識崛起，我們明白了，使用者體驗是我們的目標，但是開發體驗也是我們的目標。只有好的開發體驗才能帶給我們更高效的工作流，更輕鬆的工作體驗。而這種高效往往意味著我們最後會產出更高質量的程式碼與空出更多的時間去進行優化。
所以老話總說磨刀不誤砍柴工，而我們往往是一邊磕磕絆絆砍柴一邊抱怨沒有時間磨刀。不如停下來看看為什麼任務總在後面追，而我們總是彷彿深陷泥潭邁不開步子。
從一個難題到一個值得寫在開發生涯裡的經歷，我們所費的不過是認真思考，花點功夫，找題解題，而不是一句“道理我都懂”。