軟件的體驗障礙與解決之道

原文</i>  http://timyang.net/tao/app-failure-solution/ </span>

目前好的app會將數據存儲在云上，給我們生活帶來很多便利，我們可以方便的多屏之間獲取到數據，也不用擔心數據在本地清除后丟失的問題。但很多基于云平臺的優秀軟件到了國內就會出現一些使用上的問題。

比如Day One是一款跨平臺筆記工具，得過蘋果設計獎，也得到不少人推薦，功能確實很簡潔實用。白天在路上用Day One寫了一些文字，回來后發現uploading一直卡住，不知道是否跟文章中某些詞語相關。打開iPhone V*N后，終于上傳成功，但在電腦上還是半天下載不回來。忙了一些其他事情之后，發現終于同步完成了。

Day One底層可以選擇用iCloud，Dropbox等云平臺存儲。這些云服務在國內訪問速度及穩定性方面會存在一些問題。Day One可能出于功能簡潔的考慮，將同步設計成后臺進行。當同步出現問題時，界面上通常看不到相關提示，系統自動在后臺重試同步。界面上也找不到任何同步按 鈕及菜單，也沒有狀態信息顯示何時會進行同步，因此在同步失敗時候，一個普通用戶只會一籌莫展了。

在國外，由于云平臺在基礎網絡鏈路及帶寬方面都具有優勢，因此同步階段不會出現這么多曲折的情況，這更多是國內特殊的網絡環境造成。軟件開發商只是無辜的被躺著中槍了，這是app存在的一類問題。

但并不是說國內的app就可以處身事外了，國內也有自身奇特的網絡問題，比如一些廠商的DNS不定期的被劫持指向一些奇怪的IP。但開發商即使了解到這個反饋，未必有有效的手段短時間解決，這也是app存在的一類問題。

做互聯網分布式系統的通常也有這樣一種情況，在主從同步等場景下，數據只能保證最終一致性；互聯網業務通常不會使用transaction來保證 數據提交一致性，因此可能會存在半狀態的數據，用戶會碰到這種情況并且會存在困惑，但廠商通常會采用時候修復的辦法，而不會首先考慮引入事務來徹底解決， 這又是一類問題。

上述問題是否能有效的解決？是否值得化大的精力解決？從“用戶第一”的角度，所有用戶的問題確實需要第一時間第一優先級解決，特別在影響用戶范圍足夠的情況下。但上述這些問題都是小眾群體及場景出現，而且都是在使用標準化方式的情況下出現了異常。

從架構師的角度，我是極力贊成使用通用化技術而反對自建輪子，比如不贊成用自己維護的UDP代替TCP，不贊成使用非主流或自己開發的數據庫、框 架、工具包；不贊成通訊上使用自定義的協議來代替XMPP，或者為了防止DNS劫持而去搭建自己的DNS方案。可以預見，這些自建方案的決策在一定程度上 打開了一個潘多拉盒子，社區通用技術體系經過5-10年或更長時間的演進，經過較多問題的修改與避免。比如上面的DNS問題意料外的第101個問題，但是 前面它已經解決了100個不同場景的問題。但是自建的體系更有可能是從0開始修改，可能需要將大量時間放在重復業界已經完成的功能上。

因此從工程師體驗來說不太傾向于對各種復雜惡劣的環境都做一個適配方案。如果有機會能做這樣一個比較，在“工程師體驗第一（類似非死book 的Hack文化)”與“用戶第一”做一個優先選擇的話，究竟誰的成效很更好一些。老板們通常會傾向后者，類似有阿里的“客戶第一，員工第二”文化。一些聲 稱工程師文化主導的公司可能會選擇前者，而且某些持這種理念的人也認為工程師主導產品改進的環境會激勵工程師的主動參與及改進精神，而導致成效更好。另外 一方面文化層面的東西很難直接比較優劣。