互聯網信息化咨詢/技術開發/整合營銷
請通過以下方式免費咨詢
提交
誤區三：架構經驗的拿來主義
“架構師”這個職務名稱，聽起來比程序員或者開發，要高大上得多。這個名稱也就成為我們軟件技術人的重要追求之一。大家都希望自己被稱呼為架構師，而不是程序員。
不要小看這種力量，這種影響會讓技術團隊中的相當多人，以學習足夠多的和架構技術相關的名詞為榮。
學習知識還能有錯？這當然沒有錯，學海無涯，多學總是好事。但問題就出在“紙上談兵的故事”。學成孔乙己可不是什么好事。軟件架構這種東西，我始終不認為它是一種數理級別的定理級知識，我更傾向于它是經驗型知識。
怎么理解經驗型知識呢？
就比如，騎自行車、游泳，這些技能都是經驗型技能。這種技能有個特點，就是你沒有辦法通過閱讀甚至背誦一本《游泳技巧大全》而實現游泳技能的提升。你必須自己下水去嗆水，騎上車去摔跤，然后才可能真的學會。
我曾經和一個合作團隊的同事去討論一套合作的技術方案，我提出了一套接口用法，可以相對比較容易得快速的達成雙方的目標，然而我卻受到了對方合作團隊一個年輕同事的激烈反駁，他認為我的架構不滿足架構上的某某什么原則什么理論，講了一大串名詞。最后，我們還要花費大量的時間和精力，和他逐條掰扯這樣做的具體問題到底在哪里。如果真的按他說的做，除了架構上有一種莫名的數學上的美以外，沒有在任何維護成本、開發速度、質量控制上的明顯優勢。這個就是典型的經驗拿來主義。
所以我在做技術招聘的面試的時候，不管面什么內容，哪怕是問 TCP 和 UDP 有什么差別，這樣基礎性的問題，我喜歡反復追問的都是，UDP 與 TCP 各自存在的價值分別是什么？為什么兩種方法要同時存在？我要的是這個分析過程，要的不是背誦 TCP 的各種基礎結構，各種理論定義。我要的是 TCP 的每一個結構為什么要長這樣？而不是那樣？它當初形成的推導過程有沒有思考過？只有學會了推導過程，在你遇到問題的時候，才能夠通過思考的方式去進行這個事情，應該怎么做？什么方法是可以拿來用的，對吧？
我們千萬要警惕團隊里有人把別人寫的書、做的學問、編的文章，當做像三字經一樣在你面前背誦，跟你說這是某某曰過，所以要按這樣做。我并不是反對去學習別人的經驗，反而我很提倡多學習別人的經驗，但問題是說經驗拿過來用的時候，我們用的方法一定是漁法，而非魚本身。要了解這個經驗它是怎么來的，經驗創造出來的一個過程，推導這個經驗的過程 如果和我們當前遇到的情況很契合，所以我們才用它，而不是說因為這個經驗是一個牛人說的，是一個大佬寫的，是來自于一個很成功的項目得出的，于是得出我們要用，這是完全沒有邏輯的。
辨別和理解這些經驗的過程，或者說，自己創造屬于自己經驗的過程，是需要大量實踐的練習與深度思考一起進行的。其實，這條誤區的背后，是培養技術人才的核心技巧之一。如果有時間，我以后再寫專門的文章詳細講解。
誤區四：性能潔癖主義
這個誤區貌似比較容易理解，只是有時候，它的存在像一個陽謀，我們知道不對勁，但卻無能為力。
一般技術團隊，在人多了之后，隊伍里面會出現各種各樣角色的人，一定會有一些完美主義傾向的，有潔癖癥的一些人，他們會摻雜在里面，就會導致我們在做事情的時候容易偏離核心目的。
當然，寫到這里，有些讀者可能會誤解我的意思——會理解為“做性能要適可而止”。但這不是我想表達的！
做性能，我是傾向于能盡可能地做到現有條件下的極致化。只有極致化的性能才能在競爭中脫穎而出，這個非常關鍵的，如果我們做不到，往往是資源不夠，或者能力不夠，而不是決心不夠，這個不是什么誤區。我要講的誤區是：“我們往往因為追求常規的性能參數，而喪失更重要的體驗級性能” ，這才是很多人，難以跳脫出來的誤區。
繼續舉一個例子：大家都在傳微信誕生之初，騰訊內部有三個團隊都在做微信，最后是張小龍的團隊勝出。這個故事不是完全真實，但是確實也是有故事的原型的。我就是當時其中一個團隊的技術負責人，也確實有在和張小龍的團隊競爭（當然，龍哥現在已經是我的老板了）。我們當時的產品叫做 Q 信，用 Q 信來發 IM 消息、語音消息、圖片消息。過程中，要解決一個問題“移動端信號不如有線網穩定的情況下，如何做到像系統短信一樣極高的發送成功率？”那時候，3G 時代還在巔峰，4G 尚未完全普及，一部分用戶還依然在使用網絡極差的 2G。基于當時的條件下，我們對信號弱，發送失敗的情況設計了大量的重試策略、動態化的重試步長、網絡探測策略，等等各種復雜規則。
但是，我們發現，無論怎么做，發送消息失敗的概率，以及發送成功的速度，都還是明顯弱于微信。我們始終無法正確預測用戶什么時候突然進入電梯沒有信號了，什么時候又出了電梯，什么時候又進入隧道沒有信號了， 而微信卻仿佛能夠預測未來一樣，總是在用戶走出電梯的一瞬間，把消息發送成功。
我們的問題出在哪？
我在反復琢磨了很久并對微信抓包分析之后，才后知后覺。其實一切都很簡單，是我們自己錯誤的性能追求框死了自己。因為我們做了多年的移動端 App，對移動端 App 省電的經驗深入骨髓，這樣的經驗前提下，我們所有的重試策略都會制定時間間隔、重試次數，我們像潔癖癥患者一樣，不允許任何無畏的耗電。壓根不會跨出省電的大前提去設計技術方案。而微信的做法，簡單粗暴，在消息發送不成功的時候，快速、多次不斷地重試。當然可以在用戶打開電梯門，網絡恢復的一瞬間，馬上發送消息成功！我們犯了一個致命的錯誤，就是我們并沒有去計算我們通過這套復雜的省電規則，到底節省了多少電？節省的這點有限的電量（后來證明，由于異端場景的概率問題，節省的電量極少），能否比得上一個發消息速度極快且極其穩定不懼網絡波動的軟件，帶來用戶的信心的價值？一款產品的成功，摻雜著無數條類似這樣能勘破常規誤區，能直擊靶心的思維尖刀！而在當時欠缺這套能力的 Q 信，顯然差距還比較明顯。
更多新聞
