技術團隊的標準化與可復用文化
一次某用戶在使用系統時候碰到一個問題，但不確認是系統的bug，于是問題通過各級的微博@消息反饋到產品與技術團隊。在反饋鏈中，每一個同事都需要確認一下自己是否也出現這個問題，以便確認是否屬實以及問題的范圍（你可以理解互聯網的從業人員為什么那么忙了）。
當這個@消息最終傳遞到當事的工程師手里，他也需將描述的問題再測試一遍，如果不能重現，問題就變得更加復雜，工程師需要從一堆海量的日志去定位當 時用戶出現這種現象的原因。那一次排查到最后，發現原因是某臺服務器的返回的數據不對導致，那臺服務器可能是由于在某些特殊情況下，啟動了一個不同的版本 而導致用戶的調用不能正常返回。如果你也是一個工程師，是否有幾分熟悉的感覺？
自從工程師鍵入第一行代碼那一時刻起，開發流程中每個環節都存在出錯的可能。比如
- 代碼可能未被單元測試覆蓋，當然有更多的團隊根本沒有編寫單元測試的習慣；業務流程未被功能測試覆蓋；因此當最終用戶才發現不正確的問題時（如文首描述的情況），整個技術團隊需要更多的時間去解決。
- 服務之間的調用方式、參數或邏輯不正確；當服務由不同的團隊維護時，出錯的概率會更大；另外一個團隊的服務往往只有幾行文字的描述的郵件，很多參 數語焉不詳，你需要通過以前的代碼或者親自調用一下來推測這些參數的作用。這時候如果你需要的功能剛好能調通，歡呼之外就是接著提交及發布代碼了，因為上 面已經開始對你聯調時間過長有些不滿。
- 發布的版本、配置、順序、服務器等不正確。盡管大家都覺得有一個上線手冊之類的指導文檔，但在實際工作中開發與運維的交互可能會是通過IM工具， 開發工程師說，今天上線模塊的順序是ABDC，運維工程師雖然對為什么不是ABCD的這樣的順序有些疑惑，但也依照開發的順序做完了。而下一次上線前，開 發工程師沒提及上線順序，運維工程師可能納悶，到底是ABCD還是ABDC呢？
上面種種情況，如果每一次代碼修改及發布都依賴每一位工程師的細心及考慮周全的話，則高概率的質量問題不可避免。而工程師則很沮喪的發現經常在解決 同一類型的問題。而將全流程更多不易變的單元編程標準化，由程序來控制，則可以從源頭上減少問題，讓軟件開發變得簡單及享受。在上面例子中，可以將（1） 測試過程標準化。（2）在服務化架構中，將更多的單元標準化。（3）發布流程標準化。這些點更多的看各團隊工程的成熟程度。團隊中標準化程度越高，軟件的 可靠性就會越好，更多的精力將會從各種不確定性問題中解放出來。
說下第2點服務標準化的一個例子，Tim所在團隊最近幾年做的系統密集的使用了消息隊列，經過幾年的演進，也將各種很復雜的場景實現在系統內，比如 多級串聯、并聯、實時性要求非常高的PUB/SUB，用自定義各種服務池來做任務調度，踩了很多坑也積累了很多經驗。但是標準化意識以及抽象能力不足，業 務架構與技術架構也缺少分開去考慮，因此大部分系統主要針對自己特定場景的設計去實現，即使有很多有價值的特性，但無法復用到另外的場合。當一些新人去學 習Kafka這些系統時，老的架構師也會去反思標準化的問題。當然，3年以上的技術團隊才會有這些感悟，年輕的團隊通常會沉浸在搭建自己系統的快感中。
再說另外一個例子，曾經有一篇技術貼說某個美國的工程師推ter技術面試失敗的經歷。
然后我們聊了一小會關于在推ter的生活。
我掛掉電話的那一秒我意識到了我的答案是錯的。
……
現在我捫心自問：在這件事我學到了什么？客觀地說——不多。對于面試官沒有問我正確的問題來引導我向正確的方向思考，我很難過。當我的解答實際上不正確的時候，我不知道為什么Justin告訴我“這應該有用”。
從中可以部分感受到硅谷科技公司對工程師的嚴格要求。但是國內的情況有所區別，由于互聯網行業有些過熱，合格的人才處于供不應求的情況，因此大部分 崗位要求都比上文中描述的要求低。工程師只要具備基本的學習及模仿能力，比如能參考一個現有的軟件能夠實現相同的功能，那這個工程師基本能進入各個互聯網 技術崗位（當然表面的工作經歷也是需要的）。
在這種情況下，整個技術群體很難對代碼質量形成太多共識。再加上大多團隊是業務驅動型（技術驅動的鳳毛麟角），企業對于技術的要求局限在按時交付。精心雕琢的軟件相比于打補丁修補而成的軟件并不會得到更好的價值體現，因此追求高質量軟件的風氣也不易形成。
企業里面的軟件可復用還有惡性循環的情況，比如某個工程師做了一個公共組件來解決一些公共問題，但是另外一個團隊在使用后發現存在一些問題，理想的 情況是，反饋的問題得到了及時修復，解決了各個團隊共性的需求，公共組件在更多場合得到了推廣。但在現實中，具備開發良好公共組件能力的人是非常稀缺的， 盡管每個Web開發團隊都有開發一套自己的MVC框架，但在做到優雅的業務實現方面尚有不足的情況下，一廂情愿的去做自己的標準組件是較難把握共性的需求 及得到使用認可。
在另外一方面，其他的團隊也容易把“那個版本沒有很好的滿足我們需求”的情況成了自起爐灶的理由，通過各自建設，表面上完成了自己的內部需求，自認 為團隊內部的認知成本是降低了，但人的精力畢竟有限的，有限的時間只能做好有限的事情，最終各自搭建可能也只能建成一些不可復用的系統，除了短期的自我充 實感之外較難有更多的價值。
Similar Posts:原文鏈接: http://timyang.net/management/reusability/