警惕降本增笑！軟件開發不可忽視的四大誤區
發布時間：2018-11-25閱讀次數：2560
我們在以實用為目的去做事情的時候，很容易受到一些思維誤區的干擾，自以為自己是追求實用的，但實際上早已經謬之千里，卻不自知。
01、什么是軟件研發的實用主義？
軟件研發架構的各種理論方法，其本質都是圍繞著“實用”來進行設計的。
所以，事實上不應該有什么軟件研發的工作方法是不屬于實用主義的，一切的軟件架構、軟件設計、軟件研發管理的方法，都應該屬于實用主義。
但為什么我還是要提出這個題目，來探討這個問題？
那是因為我們在以實用為目的去做事情的時候，很容易受到一些思維誤區的干擾，自以為自己是追求實用的，但實際上早已經謬之千里，卻不自知。就好像我們明明是為業務發展、團隊管理提出的『降本增效』目標，一不小心卻引發了穩定性危機的『降本增笑』結果一樣。
具體有哪些誤區會干擾我們的判斷呢？我結合了在騰訊十多年工作經驗，以及和前后數十個不同風格的研發團隊深度合作的經歷，歸納了四大誤區。
02、誤區一：技術上的主次混淆
沒有人會認為自己是一個主次不分的笨蛋，但實際上，團隊合作過程中表現出來的綜合智商就是低于個體智商的。再加上，團隊中，總是會摻雜一些“不知道自己不知道”的盲目者，最終會把團隊帶向歧途。
舉一個在騰訊內，很典型很常見的例子。
本來有一個團隊，可能原本他們是負責一款軟件App的研發，在執行工作的過程中，發現自己缺少了一個基礎組件。這個組件可能是一個crash率的監控組件，也可能是一個為了解決性能問題而誕生的性能監控組件，還可能是性能輔助工具或者日志工具組件，等等。所以他們就會安排員工自己去做這樣一套工具組件出來。
當工具組件開發完成，也能夠滿足自己使用的同時，他們就會誕生一個想法，就是這個工具組件，在旁的團隊是不是也需要？這樣常見的工具，很大概率大家都會需要吧？如果我們把這個組件推廣出去，我們的技術價值是不是就會擴大？研發同事是不是就有更多的晉升素材？大家似乎能從中撈到好處，而且是以技術的名義，看起來還很正義。這樣的想法，大概率都是一拍即合的。
這個想法本身沒有錯，如果說我們有充分的時間精力，或者說我們確實做出了一個通用化的工具，且通用的價值也足夠大的話，是可以去做這個事情，但是現實往往很復雜。有可能他的主項目處于人力緊缺的一個狀態，有可能他們的業務正在生死邊緣，都快做不下去了，有可能主業務那邊還在拼命招人，卻招不夠，找不到合適的人才。但是，這邊卻又拎著一支技術隊伍去做以通用化為目的的技術工具。那么最后的結果是什么呢？那就是浪費了更多的人力和時間。
那這件事能不能夠成功呢？
首先他還不一定能夠成功，對吧？即便他能夠成功，它也僅僅只是給別的團隊提供了一個不一定很適用的工具。別的產品團隊拿過去用，可能還會抱怨說這個工具不太好用。自己還得持續投入人力去不斷完善。因為每個團隊有自己軟件架構的一些特色特點，用法特征，你做成通用化的，別人拿去不一定是最好用的，原本只做給自己用，完全以自己的使用方法習慣和團隊的成員的特色去結合，是很好用的。但是他把它通用化之后，有可能自己也不一定好用了，別人也不一定是最適用的，雖然它可能有一定用途。即便最終有人用了，那旁的團隊能給到他什么呢？能支持他的業務成功么？顯然不太可能。
所以，我們要思考一下，我們在一家大公司里，做這樣的一些小的基礎工具產生的價值，和我們做出一個真正意義成功的產品的價值的對比，差異有多大？完全不在一個量級吧，一款產品的大成功是決定性的價值，而一個或者好多個通用的小工具，其價值能與之相提并論么？
03、誤區二：管理懶惰與重度規范化問題
還有一個誤區就是來自于規范化，為什么規范化也會形成干擾呢？規范化不是好事么？如果一個事情是很容易能看出來問題的，就不會叫做誤區了。我們都能明白，日常生活中，最可怕的人就是面像和善的斯文敗類了，對吧？因為你被表象迷惑了。
繼續舉一個例子：比如某個團隊復盤研發效率低下的問題，復盤的過程，會去追究為什么研發效率低？原因是他們的團隊的同事在這些模塊接口的調用用法之間老是搞錯，或者找不到正確的用法，于是又另起爐灶開新的接口，形成各種垃圾代碼山。或者說把接口用錯，模塊重度耦合，牽一發動全身，等等。這些都會制造很多的時間成本，而且還必然會導致一些質量問題。
所以，面對這種情況，如果技術管理的主導者，自己的技術能力不夠強悍而又厭倦了無休止的討論后，會很容易能夠想到的，不需要太動腦子的方法就是：“我們要增加注釋，把接口的規范統一整理，把架構和目錄統一整理，要讓軟件變得更加易讀，架構更加清晰”。當然，這個內容本身是很正義的，聽起來也貌似很美好。【注：他們大概率沒有能力去想到，員工能力培養的方法問題，技術骨干的甄別技巧問題，以及，其實應該由技術總負責人自己親自設計架構等核心因素……】
一個聽起來很正義的事情要推行下去的話，是容易得到大家的支持的。但是真是去推行的時候就會發現問題了，因為沒有去定義注釋寫到什么程度是合格的，架構清晰到什么程度是合格的，于是就需要有專人來做這樣的規范。
這個時候團隊里面就會開始形成了分工，會有專人來負責這些規范化的事情，而負責規范化事情的同時，他的KPI和他的核心職責就是讓規范足夠的極致。這一下就開始完蛋了。
大家可以想象到一定會有過度的規范制定出來。因為既然有專人來干這個事情，就會有人把這種事情當做KPI或者OKR。這種規則，即便嚴苛，但因為一開始這個是所有人都舉手所贊成支持的事情，后面怎么可能自己又跳出來反對呢？所以，反對的聲音都是很渺小的，于是他們的團隊的成員就會形成一種：”我感覺這件事情有點不對，但是我又說不上來哪里不對“的感受。
最后的結果是什么？就是會開始形成一些有意或無意的抗爭，或者是執行怠慢。
那么負責執行規范的人就會發現規范大家都很支持，卻很難執行，因為大家有反抗情緒。他們的領導層往往會在事后，收到執行上出現困難的一些聲音之后，開始舉行一個反思會，或者說復盤會，去思考他們這么做是對的嗎？
他們很快會發現這件事情上，單就規則本身來討論，它一定是一個正確的事情，所以他們沒有辦法去把復盤出來“這個事不需要繼續進行”的結論。而且大概率會復盤出另一個結論，就是：“這件事情要繼續做，而且是堅決的做，沒有執行好是因為不夠嚴格，規則還不夠明細，獎懲措施沒有落實到人。做得好的應當獎勵，樹立標桿，執行不好的人要有懲罰！”
接下來，他們就會開始細化如何用更強制的措施讓這個事情能夠執行得更好，怎樣甑別那些干擾的人，不愿意嚴格執行的人。而強制的措施最容易想到不太用動腦子就能想到的解決方法就是打分，打分就可以量化，就不用去個例化分析了，因為個例化分析太難了，團隊的人那么多，情況那么多對吧？
他們急切地希望制定很多的一刀切的規則標準，拿著這些一刀切的規則和標準去要求大家，這樣才不會老是遇到爭議。
根據這些標準來量化大家做的事情，這個時候團隊的失敗就進入到中后期了，因為他們所有的時間和精力就開始圍繞著分數去進行工作了。團隊成員的目標倒是很明確了，把分數做高就對了。但是，這是整個團隊的最終目標么？
監管團隊的人在制定規則，他的KPI他的思考變成了思考規則，而做事情的人變成了圍繞分數去進行工作。
本來我們是應該圍繞著產品的成功去工作的，但是，這個產品如何才能成功這件事，是誰在負責？這個時候，已經幾乎沒有人負責了，只有領導大老板自己一個人在負責。但是他又想不明白有什么不對勁？因為他安排下去做的事情都是圍繞著他的目標想要做好而推導出來的事情，最后卻做得一團糟，所有人都在努力，卻都沒有圍繞最終目標去做。
其實背后的原理就來自于一個偷懶的行為：就是他們不想具體案例具體分析了，他們希望制定統一標準之后，大家統一地來套這個標準就好了，不要有誰去挑戰規則。這個才是問題的癥結。
當然，實用主義也不是說我們就不要規則了。因為有些事情它的量級很高，量級很大，如果每一個問題都要具體案例具體分析，大家也累不過來。這種時候，是需要真正的技術領導者來統籌全局的，對問題的洞悉不應該來自于層層傳遞，而是本身的深度理解。
例如大部分軟件足夠龐大后，會碰到多線程帶來的穩定性問題，會引入層層疊疊的規范和規則，以及層層疊疊的架構保護措施。幾乎無窮無盡，最后還是解決不干凈線程問題。而我會要求企業微信的線程數量嚴格控制，io都是一個線程，網絡也都是一個線程，再加上UI主線程，常規情況下只有互不干擾的3個線程。當然，也允許特例，但是非常有限，都需要懂這套規則背后原理的人來審核。幾年下來，企業微信這樣一個幾千萬行的超大型軟件系統，幾乎不會遇到任何線程上的質量問題。這為我們的快速迭代提供了極大的助力。當然，這個只是無數措施中不起眼的一小條而已。最關鍵的是，主負責人，自己理解是否對。
當然，團隊里的核心人物數量有限，當事情的量級達到一定程度的時候，我們一定會迫不得已會用一些自動化的或者說一刀切的規則化的方式去做事情，這些規則化實施的時候，一定要遵循一個原則：就是這個規則面對一些個例的時候，要有一個方法去衡量邊界，越界的，就必須有足夠能力的技術leader來獨立分析解決問題。要不然技術leader干什么呢？只管人不管技術就不是合格的技術leader了。
規則不能貪多，不能一開始就妄圖制定涵蓋一切的規則。規則太多就沒有辦法做到每一條規則都完美化了。當我們定規則定得太快太多，又長時間不更新不回溯，它們就會形成我們前面講的失敗的案例的結果。
所以規則要少要精，而且要時常復盤，對一些不能夠完美化的規則，要及時地清理。不要太過懶惰地試圖去批量的進行規范化，規范化一定要有節制。尤其是，有些事情，過去這樣做是對的，今天，不這樣做可能才是對的。
04、誤區三：架構經驗的拿來主義
“架構師”這個職務名稱，聽起來比程序員或者開發，要高大上得多。這個名稱也就成為我們軟件技術人的重要追求之一。大家都希望自己被稱呼為架構師，而不是程序員。
不要小看這種力量，這種影響會讓技術團隊中的相當多人，以學習足夠多的和架構技術相關的名詞為榮。
學習知識還能有錯？這當然沒有錯，學海無涯，多學總是好事。但問題就出在“紙上談兵的故事”。學成孔乙己可不是什么好事。軟件架構這種東西，我始終不認為它是一種數理級別的定理級知識，我更傾向于它是經驗型知識。
怎么理解經驗型知識呢？
就比如，騎自行車、游泳，這些技能都是經驗型技能。這種技能有個特點，就是你沒有辦法通過閱讀甚至背誦一本《游泳技巧大全》而實現游泳技能的提升。你必須自己下水去嗆水，騎上車去摔跤，然后才可能真的學會。
我曾經和一個合作團隊的同事去討論一套合作的技術方案，我提出了一套接口用法，可以相對比較容易得快速的達成雙方的目標，然而我卻受到了對方合作團隊一個年輕同事的激烈反駁，他認為我的架構不滿足架構上的某某什么原則什么理論，講了一大串名詞。最后，我們還要花費大量的時間和精力，和他逐條掰扯這樣做的具體問題到底在哪里。如果真的按他說的做，除了架構上有一種莫名的數學上的美以外，沒有在任何維護成本、開發速度、質量控制上的明顯優勢。這個就是典型的經驗拿來主義。
所以我在做技術招聘的面試的時候，不管面什么內容，哪怕是問TCP和UDP有什么差別，這樣基礎性的問題，我喜歡反復追問的都是，UDP與TCP各自存在的價值分別是什么？為什么兩種方法要同時存在？我要的是這個分析過程，要的不是背誦TCP的各種基礎結構，各種理論定義。我要的是TCP的每一個結構為什么要長這樣？而不是那樣？它當初形成的推導過程有沒有思考過？只有學會了推導過程，在你遇到問題的時候，才能夠通過思考的方式去進行這個事情，應該怎么做？什么方法是可以拿來用的，對吧？
我們千萬要警惕團隊里有人把別人寫的書、做的學問、編的文章，當做像三字經一樣在你面前背誦，跟你說這是某某曰過，所以要按這樣做。我并不是反對去學習別人的經驗，反而我很提倡多學習別人的經驗，但問題是說經驗拿過來用的時候，我們用的方法一定是漁法，而非魚本身。要了解這個經驗它是怎么來的，經驗創造出來的一個過程，推導這個經驗的過程如果和我們當前遇到的情況很契合，所以我們才用它，而不是說因為這個經驗是一個牛人說的，是一個大佬寫的，是來自于一個很成功的項目得出的，于是得出我們要用，這是完全沒有邏輯的。
辨別和理解這些經驗的過程，或者說，自己創造屬于自己經驗的過程，是需要大量實踐的練習與深度思考一起進行的。其實，這條誤區的背后，是培養技術人才的核心技巧之一。如果有時間，我以后再寫專門的文章詳細講解。
05、誤區四：性能潔癖主義
這個誤區貌似比較容易理解，只是有時候，它的存在像一個陽謀，我們知道不對勁，但卻無能為力。
一般技術團隊，在人多了之后，隊伍里面會出現各種各樣角色的人，一定會有一些完美主義傾向的，有潔癖癥的一些人，他們會摻雜在里面，就會導致我們在做事情的時候容易偏離核心目的。
當然，寫到這里，有些讀者可能會誤解我的意思——會理解為“做性能要適可而止”。但這不是我想表達的！
做性能，我是傾向于能盡可能地做到現有條件下的極致化。只有極致化的性能才能在競爭中脫穎而出，這個非常關鍵的，如果我們做不到，往往是資源不夠，或者能力不夠，而不是決心不夠，這個不是什么誤區。我要講的誤區是：“我們往往因為追求常規的性能參數，而喪失更重要的體驗級性能”，這才是很多人，難以跳脫出來的誤區。
繼續舉一個例子：大家都在傳微信誕生之初，騰訊內部有三個團隊都在做微信，最后是張小龍的團隊勝出。這個故事不是完全真實，但是確實也是有故事的原型的。我就是當時其中一個團隊的技術負責人，也確實有在和張小龍的團隊競爭（當然，龍哥現在已經是我的老板了）。我們當時的產品叫做Q信，用Q信來發IM消息、語音消息、圖片消息。過程中，要解決一個問題“移動端信號不如有線網穩定的情況下，如何做到像系統短信一樣極高的發送成功率？”那時候，3G時代還在巔峰，4G尚未完全普及，一部分用戶還依然在使用網絡極差的2G。基于當時的條件下，我們對信號弱，發送失敗的情況設計了大量的重試策略、動態化的重試步長、網絡探測策略，等等各種復雜規則……
但是，我們發現，無論怎么做，發送消息失敗的概率，以及發送成功的速度，都還是明顯弱于微信。我們始終無法正確預測用戶什么時候突然進入電梯沒有信號了，什么時候又出了電梯，什么時候又進入隧道沒有信號了......而微信卻仿佛能夠預測未來一樣，總是在用戶走出電梯的一瞬間，把消息發送成功。
我們的問題出在哪？
我在反復琢磨了很久并對微信抓包分析之后，才后知后覺。其實一切都很簡單，是我們自己錯誤的性能追求框死了自己。因為我們做了多年的移動端App，對移動端App省電的經驗深入骨髓，這樣的經驗前提下，我們所有的重試策略都會制定時間間隔、重試次數，我們像潔癖癥患者一樣，不允許任何無畏的耗電。壓根不會跨出省電的大前提去設計技術方案。而微信的做法，簡單粗暴，在消息發送不成功的時候，快速、多次不斷地重試。當然可以在用戶打開電梯門，網絡恢復的一瞬間，馬上發送消息成功！我們犯了一個致命的錯誤，就是我們并沒有去計算我們通過這套復雜的省電規則，到底節省了多少電？節省的這點有限的電量（后來證明，由于異端場景的概率問題，節省的電量極少），能否比得上一個發消息速度極快且極其穩定不懼網絡波動的軟件，帶來用戶的信心的價值？一款產品的成功，摻雜著無數條類似這樣能勘破常規誤區，能直擊靶心的思維尖刀！而在當時欠缺這套能力的Q信，顯然差距還比較明顯。
再重復一遍，我當時犯的錯誤是：“我們往往因為追求常規的性能參數，而喪失更重要的體驗級性能”。
06、總結
坊間有流傳，企業微信以幾百人的產研團隊完成常規團隊需要數千人才能完成的工作。互聯網行業的八卦產業也著實無孔不入。但是，我也確實為企業微信的研發團隊而驕傲，這算是外界對團隊研發效率的肯定吧。
企業微信包含著Win、Mac、Android、iOS、Web、小程序、Server共七大平臺，合計超過6500W行代碼。橫跨教育、零售、餐飲、政務、工業、醫療、IT等等諸多行業的垂直功能。這已經是一套超大型的綜合型軟件系統了。其中的OA系統、HR系統、日程系統、協作系統、郵件系統、客服系統、CRM系統……這類大體量、獨立的、專業型的功能就有近百個之多，其中的相當一部分，單獨拎一個出來，就足夠養活一整家普通的IT公司了。例如HR系統，voip通話系統，對我們來說也就是10人左右的研發FT就能快速完成的系統，而某些友商產品可能需要數百人的長時間協作才能完成迭代。這其實有太多效率型的影響因素，從管理到技術再到人才，有非常多的經驗值得分享。如果這篇文章有足夠多的人感興趣，我會再繼續分享更多更深的知識。
當然，寫這篇文章，不是想說我們已經做得有多好，相反，企業微信的研發上也還有很多問題需要去解決，需要補課的地方還很多，以一敵十的背后也是有諸多犧牲的。只是，我們相信目前階段下，是抓對了一些重點。因此我想，把階段性有效的知識先記錄下來，并不斷打磨才是要務。企業微信在后續的階段，還有很多真正的更難的挑戰。當然，我們也無懼挑戰，去做到一些更NB的事情，人生才更有意義，不是么？
