從“馬蜂窩數據事件”談軟件開發

來源：創世紀 發布時間：2018-10-23瀏覽：3364次

從“馬蜂窩數據事件”談軟件開發

　　我是在世界杯期間才知道有個旅游網站叫“馬蜂窩”的，后來一直也沒關注。沒想到最近幾天，馬蜂窩重新回到了大眾的視野，只不過，這次亮相好像是從廣告的另一面出現的，因為這幾篇文章對螞蜂窩進行了數據分析，得出了若干結論。

　　目前來看，馬蜂窩網站對這幾篇文章提出了異議，但是似乎還沒有給出合理可信的解釋。事實的真相如何，或許還要等等才有答案。不過我還是推薦大家閱讀這幾篇文章，相信大多數人會從中獲得不少啟發。

　　說到數據分析，似乎許多人都會一點，無非是算算總數啦，算術平均啦，看看極值啦，好一點的還知道方差、標準差。但是光這樣做數據分析，能得出的 結論相當有限。怎么辦呢？更復雜的數據分析要怎么做？許多人一看到“更復雜”，就想起復雜的數學公式、建模、曲線擬合等等，讓人不勝頭痛。

　　其實數據分析也可以不用那么復雜，搞清楚數據之間的關聯就可以有不少發現了。比如這幾篇文章就提供了非常有趣的視角，比如：

　　?所有創造內容的賬號中，最活躍的1萬5千個賬號，他們的行為似乎有共同的節奏，同時活躍，同時沉寂；

　　?所有餐飲點評的發布日期分布，周一到周五保持了相對平緩的變化，周六周日則猛跌，大眾點評則以周末兩天為高峰；

　　?所有酒店點評的發布日期分布，周四到周六開始驟降，而攜程藝龍則以周末為高峰；

　　?所有餐飲點評的發布時間分布，中午12點-13點，下午18點-20點為低谷，這兩個時間段對應大眾點評為高峰；

　　看到這些分析的時候，我忽然想起許多年前看過的一部破案電視劇。犯罪分子為了打劫資金，苦心孤詣提前半年做準備，有人提前“出國打工”，有人男 扮女裝，時間選擇大年三十以鞭炮聲為掩護……劫案完全按照預先的設計進行，可謂天衣無縫。警方翻來覆去偵查，始終找不到任何破綻和線索。最終，案件的突破 來自一個小細節：犯罪嫌疑人說自己某年某月某日乘火車回來，所有的行程都能對上，都有證明。然而警方檢查當天車站記錄的時候，發現當天那次火車晚點了。沿 著這條線索，之前那些精心設計、嚴絲合縫的環節就像多米諾骨牌一樣悉數倒下了……

　　這幾天的螞蜂窩事件，讓我想起了之前的電視劇，它們說明的都是同樣的道理：制造幾份漂亮的數據（證據）是很容易的，但是制造內在邏輯統一的數據（證據）是很難的。

　　那么，上面說的這些事情，和軟件開發有什么關系呢？

　　要知道，我們開發的軟件大多是要運行在現實世界里的，是要與現實世界打交道，與現實世界保持一致的。只不過真實世界的內在邏輯——火車晚點了就 不能直接坐上當班汽車，飯點才有事件和興致發餐館點評——往往不能原樣進入軟件世界，所以軟件系統里只剩下數據作為真實世界的載體，用數據來反映世界。雖 然大家常說“要用數據說話”，但許多時候數據也是會愚弄人甚至騙人的。那么怎樣避免被數據愚弄，怎樣識破數據的騙局呢？簡單的經驗是，不能僅僅就數據來看 數據，而要看到許多數據之外的東西。

　　數據之外有什么？最明顯的是現實世界的約束。比如汽車上坡當然要比下坡慢，口袋里沒有鈔票了就買不了東西等等。在生活中，這些東西都很好理解， 似乎是“不言自明”的，甚至你沒覺察到也擺脫不了這些約束。但是進入到軟件的世界里，程序員開發的時候往往就把這些約束忘在腦后了，或者完全依賴于產品經 理給出的規則。所以有的游戲里汽車上坡和下坡的速度竟然是一樣的，有的賬戶系統可以可以“逆向”充值給銀行卡，儲值余額卻變成負數…… 

　　我剛剛工作的時候，在書上看到的一個例子讓我印象深刻。天上的飛機需要知道航向，所以Plane對象有個成員變量是heading。通常我們會 用一個整型數值表示它，但是那本書上提到這是不對的！因為航向只能在0到360度之間，所以你用整型數值時一定需要給setter加上一段邏輯，確保這個 值只能設置在0到360之間。否則，難保其它系統讀到heading時不會出錯。“只有加上了對應的約束，變量才不再是原始普通的數字，而變成了能承載業 務價值的數據”。

　　許多年過去了，我仍然記得當時的驚訝：原來竟然可以這樣！原來竟然應該這樣！

　　后來我自己在開發中一直保持這樣的習慣，雖然麻煩，也因此避免了許多故障。再往后看到《領域驅動設計》才明白：在設計軟件系統時，領域知識往往 是最重要的，而領域知識的一大部分就在于識別領域中的各種約束。這些約束很難由產品經理巨細靡遺地窮舉出來，而必須由參與開發的所有人達成共識，在系統里 實現它。但是無論如何，這些約束都是必不可少的，沒有它們，系統就很可能出現各種稀奇古怪的現象。

　　我曾經見過奇特的倉儲費賬單，數額大到讓所有人吃了一驚，大家伙查來查去才發現入倉時間竟然在公元229年。如果約束落在系統里，第一時間發現 異常并且報出來，就可以省去后面的許多折騰。當時我說“公元229年這還是三國時期呢”，所有人都笑了。其實這個例子一點也不好笑，看看我們常見的系統， 身高、年齡、體重、車速、生日等等數據，許多時候就是想當然直接用原生數據類型來表示的，所以取值為負數、甚至幾千萬上億也“無可厚非”，當然后果也非常 嚴重。

　　數據之外的天地不只有約束，數據的內在邏輯和關聯也是相當重要的。

　　在分析馬蜂窩的文章里提到，馬蜂窩做了些修改，比如清空了某些賬號，所以看起來數據正確了。但是稍作一點拓展就會發現，數據完全對不上，比如之 前這些賬號留下的那些牛頭不對馬嘴，“身份今天是男明天是女”的點評仍然存在著。如果數據真實，并不會發生性別劇烈變化的情況；如果數據關聯可信，也不會 出現“刪了賬號帖子還在”的情況。

　　不過，這種“按下葫蘆浮起瓢”，“顧頭不固腚”的現象并不是個例，我就見過許多系統有這種問題，稍微改動某個細節，就會全盤大亂。這還不是最要命的，最要命的是發現異常的時候根本不知道因果鏈條是怎樣的，從哪里萌發，中間經歷了哪些環節，下面還會影響什么……

　　之所以會出現這種問題，不少時候是系統開發過于想當然，過于圖省事，假設其它一切都是“按部就班”正常發生的，所以只記錄了“最核心”的數據， 相關的數據和狀態則完全沒有保存。于是，系統的狀態就只能靠一堆零散孤立的點來承載，點與點之間沒有明確關聯，不能彼此印證，也無法回溯歷史上的各個片 段。

　　這方面最明顯的例子就是記賬系統。許多人都見過“想當然”的記賬系統，每一筆賬目發生的時間、金額都要記錄下來，但也僅此而已了，絕沒有記錄所 涉及賬戶的即時余額，涉及的賬戶里也沒有對應的記錄。結果某天發現賬戶出錯，只能手工一筆筆地追查，效率極低，而且容易額外引入錯誤。

　　出現這種情況當然很糟糕，但也有一定的道理。記賬這回事已經有幾千年的歷史，但“在會計活動中對每一項經濟業務按相等金額在兩個或兩個以上有關 賬戶相互對應地同時進行登記”的復式簿記法，直到12世紀才在意大利誕生，引入我國更是要等到晚清時期。如今許多做軟件開發的人未必學過會計知識，做出的 記賬系統沒有復式簿記的思想，也情有可原。

　　其實按我的經驗，往往越是復雜的系統，越是復雜的功能，越是應該學“復式簿記”，也就是不怕麻煩，清楚記錄因果鏈條，提供詳細回溯能力。以前我 們曾做過一套計費系統，其實就是把一大堆階梯價目表做到系統里，上線后經常有客戶來吵架，說計費出錯了，每次都要勞心勞力來核對。即便系統沒有出錯，也沒 有辦法第一時間否認系統出錯，第一時間證明給用戶看。

　　后來大家痛定思痛，花大力氣把計算過程做成了“自解釋”的：每一步都有詳細的記錄，按照哪一份標價表格的第幾條規則，具體是怎么計算的……總 之，每一筆費用都有詳細的計算過程可查，而且各子系統之間需要維持狀態關聯，保證彼此的數據和狀態實時一致，如果出現問題及時報警。 這樣做繁瑣是繁瑣了點，但上線之后不久就解決了爭議，程序員有了更多不被打擾的時間，用戶也有了信心。

　　最后，在我們分析問題時也應當注意數據的關聯。

　　我經常說，正確合理的分析，一定有多個獨立數據來源可以彼此驗證。之所以這么說，是因為看到了太多的分析，給出的原因、理由看似合理，卻根本無 法得到多重驗證，所以其實根本沒有找對原因。比如某個程序異常的原因是“網絡瞬斷”，那么它用的是什么樣的網絡？哪一段在當時發生了抖動？共用此網絡的其 它應用有沒有受影響？如果我們再模擬一次網絡瞬斷，程序的表現是否相同？…… 只有得到這一系列答案，掌握多種數據，我們才能最終下結論說是“網絡瞬斷”。否則一口咬定“網絡瞬斷”，往往要么是能力不及，要么是偷懶甩鍋。

　　總而言之，螞蜂窩的事情或許還要“讓子彈飛一會兒”，但檢查自己手頭的代碼有沒有落實約束，有沒有實踐“復式簿記”的思想，定位問題時多找一些數據彼此驗證，卻是馬上就可以做的事情。