簡介： 別重造輪子了，大把時光可以去快活呀
作者：閒魚技術——莫癲
前言
在研發團隊發展到一定規模，同一領域問題不可避免地會存在多種解決方案。典型的，不同業務線會開發和使用不同的測試框架，很多業務線會重新開發特徵中心、配置中心、規則引擎和投放平臺。不可否認有業務特殊性或者已有方案無法滿足等原因導致合理建設，其中有重造輪子的現象。
作者在半年前開始投身閒魚會玩社區治理，從用什麼方案、是不是會重造輪子的自我懷疑，到後面沉澱會玩社區的通用審覈系統高效應對運營需求的豁然開朗，這段經歷頗有收益。本文通過還原這段經歷和其中的思考，談談在解決相同領域的問題如何避免陷入重造輪子的泥潭，達到高效解決業務問題實現最大技術價值的目標。
不要重複自己
軟件工程中一個基本原則：DRY(不要重複自己)，也就是強調抽象和複用，這是避免重造輪子最基礎的要求。運用算法、設計模型和框架設計思想，能從不同角度和不同層次避免重複自己，而長期駐紮業務線的同學還需要對業務抽象，從解決一個又一個的業務問題，轉變成解決一類又一類問題的工作方式解放生產力。
不像平臺型產品經理在前期就會描繪好產品的完整藍圖，業務線產品經理則更多時候是將用戶側的產品形態或者運營的單點工具訴求翻譯成源源不斷的需求文檔，前後需求之間可能有關聯也可能沒關聯。在時間和空間不連續的需求中，識別出通用流程和可複用能力，提前抽象、規劃和設計就變得極其重要而有難度。在閒魚會玩社區業務起步階段我們對社區治理方面的需求進行了充分調研和提煉：
- 緊跟業務目標和政策法規：會玩社區定位爲一個純淨、有調性和有氛圍的社區，需要運營全面洞察和協作把控社區的人、內容和場。同時網信辦加大網絡信息整治和處罰力度，對自查自糾的完整全面和及時性提出了更高的需求；
- 調研行業和競對解決方案：閒魚會玩是一個同時承載UGC和PGC內容的社區，同所有同類社區一樣，內容、話題和創作者等社區各維度元素在安全防控、分類和原創保護等都有着剛性的審覈或標註訴求；
- 與合作方充分交流：團隊內外不乏在業務和技術上沉澱深厚的前輩，這是個吸收別人經驗和驗證自身想法的很好契機；
這些方式幫忙高效定位業務現處階段和中長期在同領域的訴求，結合當前需求，可以合理看到需要支撐風險決策、治理和打標等審覈或類審覈需求，具備業務接入、崗位培訓、審覈、質檢和不斷優化效能的通用流程，不同的業務關鍵指標的訴求也基本一致，只是對人效和實時性的敏感程度不同而已。可以沉澱通用且支持擴展的審覈系統承載上述業務，避免自我複製輪子快速接入業務。
審覈業務抽象
不要重複別人
另一種更爲常見的重造輪子就是重複別人。澳大利亞的JohnKeogh於2001年申請註冊“圓形的交通設施”（輪子）爲專利，於當年被評爲2001年的搞笑諾貝爾獎科技獎。開源社區以及企業內部的軟件輪子頻出，不乏幾種原因：
- 閒暇時間個人學習或興趣驅動
- 不知道已有可用解決方案
- 別人東西體驗太差
- 已有方案不能完全滿足需求，無法適配、擴展，或成本過高
- 已有實現無人維護或者維護成本過高
- 戰略原因對戰略方向用賽馬方式進行內部競爭
- 組織架構原因導致無法合作或者合作效率低
- 純KPI原因
在以效益爲主要目標的生產企業內部，其中3、4、5、6、7是比較合理的內在訴求。而第4點“已有方案能多大程度滿足訴求”實際上決定這個方案是否能解決同類問題，這種情況的存在導致重造輪子的界定會存在一定程度的模糊。所以往往會從多個角度評估重建的合理性和必要性。
在抽象好並確定需要一個通用審覈系統後，抉擇複用其他團建的基建能力還是從零開始建設，需要花大量精力去調研和評估。在集團內部有跡可循的成熟審覈系統有多個。每個審覈系統都有清晰的定位，解決垂直領域的問題：
- 系統A：集團最爲普及的工作流系統。有優秀的流程編排能力，但是不支持複雜頁面佈局、多態審覈結果和嵌入各類交互組件，同步不支持處理人效和質量的優化；
- 系統B：封閉的內容審覈平臺，只支持接入該生態的帖子審覈；
- 系統C：安全中心的審覈系統，定位如其名，主要針對內容安全進行抓黑放白；
- 系統D：用於知識標註，不具備審覈流的協作能力；
可以看到每個系統都能滿足業務的部分訴求，卻無法通過迭代升級擴展邊界和改變其定位，那麼重建是不可避免的。
怎麼設計和演進是可承受的
論證清楚新建系統的必要性，系統建設成本控制在可承受範圍內也同樣重要。可承受，不僅包括人力和時間資源投入是否團隊可以承受，更重要的是迭代週期是否是業務可承受。以系統建設爲理由給業務畫餅的方式逼迫業務妥協，即使達成目的，卻間接導致業務受損，就丟了西瓜揀芝麻。
在落地審覈系統的過程，主要通過系統設計和演進策略的反覆優化來降本提效，最大程度按時、保質、保量支持業務發展，同時避免系統腐化、提高迭代速度。
系統設計
在規劃初期，只要時間允許，可以儘可能花較多時間在中長期系統規劃，保持架構合理。架構確定後最理想需要貫穿很長一段時間的版本迭代，堅持一些原則幫忙審覈系統架構在未發生大變化的前提仍在正確的方向迭代發展：
- 微核心和插件化設計：保持核心組件層足夠簡潔，支持核心流程和搭建基礎的插件容器。擴展功能進行插件實現；
- 借鑑和遵循成熟模式：剖析和借鑑同類系統經驗，成熟的系統沉澱了成熟的方法論，甚至如集團BPMS實現很大程度是工業標準BPMS的一個典型成功案件，XAP是對業內內容審覈流程的極大總結和實踐，在理論和功能完善性都有很大都體現；
- 對可擴展和靈活性保持克制：不爲不確定的靈活擴展做過度設計，如BPMS使用的流程引擎靈活強大且支持可視化的編排能力，在社區審覈僅需線性和有限節點的審覈流中則顯得雞肋，反而大大增加系統內核的複雜程度；
- 重點突破同類系統缺陷：某系統配置不統一、送審強依賴定時圈選無法保證流程實時等，這些已知問題在初期得到重視是可以很好得到解決的；
- 能力融合：前面提到的垂類審覈系統已經在支持閒魚會玩社區的部分審覈業務，通過將其抽象爲流程的節點類型之一進行對接，新建系統專注於目前短板能力建設，極大節省能力補全的投入；
社區審覈系統
社區審覈系統在經歷三個版本的迭代後，目前整體架構並未發生變更和重構，只是對各模塊的插件進行補充以支持更多業務場景。
MVP和演進策略
MVP(最簡化可實行產品)只需要完成主鏈路的流轉，從數據接入、工單流轉並完成簡單派單和人工審覈功能，這已經可以滿足簡單標註和初期的業務審覈需求，每個模塊也只實現百分百必要的能力：
- 接入側規約數據協議規範，支持消息輸入輸出，具備較好的容錯性；
- 基本完備的流程流轉內核：即上述抽象的微內核，需要在一期基本完成並保證在後期不會發生較大變化；
- 派單隻需要實現拉單模式，且不需要支持規則化分派；
- 根據業務訴求，實現最簡化的定製化審覈工作臺；
社區審覈系統MVP版本
演進策略跟MVP遵循的原則無差，都是圍繞每期需要支撐的業務，並抽象爲規劃圖的具體位置逐步迭代填充，以完成大圖的完整拼圖。
審覈系統的MVP版本在兩週完成開發上線，快速支撐了閒魚社區圈子的審覈，並在後續的迭代中完成安全中心的對接，避免業務側直接對接安全中心長達一個月的排期和等待更長時間實施上線。後續基本保持每個版本兩週的迭代週期，快速支持了後續的需求。
避免被重複
在日常工作中避免因爲各種原因重造輪子的同時，也有義務儘可能地去避免內部在相同領域出現重造輪子的行爲。拋開爲了造輪子而造輪子的行爲之外，很多輪子的產生原因更多是客觀因素導致，在一定程度上是可以儘可能去規避：
• 合理的架構和實現：相信很多大部分系統設計初衷都是爲了解決一類問題，而不是解決一個問題。往往會因爲各種原因達不到理想的狀態，需要花足夠多的經歷進行前期設計，保持內核的開閉、插件功能的單一職責等，遵循良好的設計模式，並定期回顧優化；
• 打破信息煙囪： 在合適的階段進行總結和思考，用分享或文章的方式傳播給大家，與外界發生互動。也就儘可能避免了其他團隊不知道輪子的存在而選擇另起爐竈；
• 避免煙囪式系統：不具備足夠的開放能力，除了完成已有的能力和支撐已有業務，不再探索可能的業務融合，逐漸會成爲煙囪系統。很多時候具備保持大門敞開這樣的開放性並不夠，還需要主動挖掘需求，用各種方式降級業務接入門檻，接入更多業務，達到業務支撐和迭代的良性循環；
舉兩個例子。一是審覈在社區內部業務的支持上，一開始只支持RPC和消息按標準消息格式接入方式，這對業務方有一定的理解和接入成本。在數據對接上實現插件化的數據適配方案，並實現核心業務領域的搜索數據源對接完成插件沉澱，並針對常見主體類型搭建了可插拔組件的審覈頁面，各域在需求對接只需要進行數據的圈選，免去複雜數據格格式的對接；另外，針對用戶認證業務在展現形式和標註能力上適配異構的信息，並對公用的數據源進行對接沉澱爲複用組件，不同認證業務關注於對接差異的數據即可。
總結
重複是枯燥無聊的，避免重複和被重複是每個開發者解放生產力和成長的必經階段。從業務、功能和流程各個維度抽象，並充分調研和論證新建系統的必要性，在前期的設計上做好通用性、可擴展性和功能的平衡，以業務訴求可滿足、資源投入和業務節奏可承受爲準則制定MVP版本和迭代版本。同時提高系統的開放性，主動擁抱業務和發揮技術最大價值。
本文爲阿里雲原創內容，未經允許不得轉載。