移動開發設計，用戶體驗之我見

我從事移動互聯網也有近兩年時光了，這個總結主要寫一下這兩年得體會，從用戶體驗，架構設計，編碼規則等方面寫，有寫得不好得地方，歡迎拍磚，畢竟這只是我個人體會，不能做到盡善盡美，面面俱到。

1.用戶體驗
把用戶體驗放在第一位，說明用戶體驗很重要，無論用什麼技術還是什麼平臺，首先要考慮的就是用戶體驗；如果一款應用技術很高深，用戶體驗很差，註定要失敗。
大家都在談用戶體驗，到底什麼是用戶體驗，我百度了下：用戶體驗（User Experience，簡稱UE）是一種純主觀在用戶使用產品過程中建立起來的感受。
說得太抽象了，簡單得說，就是讓你用得很爽，什麼叫爽？只可意會不可言傳，所以是一種體驗，我說幾種不爽的：
a).程序不穩定，用着用着突然閃退很不爽;
b).操作複雜，一個常用功能找了半天也沒找到也不爽;
c).最常用功能摸(現在流行電容大屏幕，以摸爲主）好多次才能完成也不爽；
d).同一類型操作，在不同界面表現不同，經常讓人很暈。
e).有效區域(除去特定功能導航區域，某個功能實際展示的區域稱爲有效區域）太少也不爽等等。

既然這麼多不爽，那怎麼才能爽呢，以下個人意見僅供參考。
a)，程序穩定，程序一定要穩定，如果經常卡主或者崩潰，誰願意用？個人認爲無論程序實現多複雜還是多簡單的功能，穩定性是第一位，如果追求界面炫麗或者技術複雜高深而放棄程序穩定性，是一種捨本逐末的作法，當然這只是個人觀點，不代表所有人觀點；這是一個指導思想，是關於架構設計的指導思想，將在後文中關於架構設計方面還會再提起。

b），功能單一，解決某些問題，這一點跟普通PC程序有很大不同，在PC，很多程序都是集大成者，功能很強大。這一套做法在移動應用沒有市場，原因有三：第一屏幕大小限制，屏幕就那麼大，很多功能怎麼體現？第二輸入限制，現在移動平臺基本都是觸屏，那麼小得屏幕，很容易誤操作，如果擺放一大堆功能或者東西，很容易給用戶造成干擾，其三CPU,內存，散熱，電池續航能力等等限制，在移動平臺上面做應用應該短小精悍爲主，試想一下，如果一個程序啓動或一個操作花掉幾十秒，誰能忍受？
c），設計太繁瑣，不經過培訓無法使用，本人有幸參與過一款基於通訊錄的羣組聊天軟件，在裏面有好幾種用戶名片信息（本地通訊錄信息，網絡名片，組織成員信息），各種名片信息可以相互轉換，有些名片可以修改，有些不能修改，有些用戶可以添加，有些需要高級權限才能添加，這一套東西，你不好好琢磨琢磨還真不會用。讓開發人員都會奔潰，何況一個小白級的用戶呢。
d）,同一APP內一些常用習慣性操作力求表現一直，比如在聊天軟件界面中，既有聊天內容，又有圖冊；習慣性做法是下拉獲取歷史記錄；有些應用在查看聊天曆史時用下拉，查看圖冊歷史時有用上拉；讓人着實很暈。
e).在ios中要利用好導航欄上面的左右按鈕，一般左側按鈕式返回上一級，個人建議沒沒必要修改；右側按鈕要合理利用起來，具體可參照ios系統自帶軟件。本人看過一些軟件，上面什麼也沒有，在最後一行加了一個提交或保存按鈕，完全讓鍵盤遮擋了，不滑動還真看不見。這樣做一兩個好處：一是方便用戶觸摸，減少滑動觸摸次數；二是此處位置比較顯眼，對用戶有一個明顯提示功能，也符合ios UI習慣。

2.平臺
移動互聯網包含很多內容，最主要得就是智能終端客戶端軟件；目前主流智能終端操作系統有iOS,Android兩個佔據90%以上市場，WP，Megoo,黑莓相對來說畢竟還是少數；在資金有限得情況下，一般公司都只選擇做IOS和Android兩個平臺，也有好多有錢得公司比如騰訊，好多移動產品都是隻推iOS和Android,著名得微信就走得這條路。

3.原生技術與跨平臺
參加過幾次技術交流會，看到好多跨平臺技術，PC,MAC,IOS,Android統統能跨，我個人利用業餘時間也研究了下QT，也做了個小程序測試了下，結果體驗很差。
由於我近兩年都做得是應用開發，所以在此討論僅限於應用；個人建議要做應用，還是用原生開發語言和SDK做UI用戶體驗比較好。

另外安卓SDK和界面UI有自己的UI和用戶操作規則，開發時要注意儘量利用自身SDK特性，符合本平臺上用戶使用習慣；本人看到一些應用在安卓上面仿照iOS某些效果和用戶習慣，結果搞得代碼很複雜，何必呢？
iOS儘量利用nav bar上面得導航按鈕，Android儘量利用功能鍵及菜單鍵，雖然說Android4.0以後增加了actionbar 類似於iOS nav bar但是目前2.x得程序還是佔大多數。


4.架構設計
這部分對於在CSDN裏面晃悠的人來說，都是一個熟悉的話題；越熟悉的話題越難談，原因很簡單每個人都有自己的設計宗旨和設計思想；我在此只是表達一下我數十年來對於架構設計方面經驗和教訓。如果對您有幫助，你一句謝謝我就很高興。如果對你沒幫助，那說明你的水平比我高，還希望多多賜教。本人雖不是真正的技術控，但也很熱衷一些鑽研自己喜歡的技術門類，相互交流共同提高嘛。

我對架構設計就兩個字-簡單；力求簡單，因爲簡單所以穩定。
下面主要對簡單做一詳細描述；
a).模塊簡單；設計模塊時能少則少，每個模塊力求功能單一，目前一般UI,DB,Network,protocol，util這幾個模塊都成系統標配了，不用我解釋看名字就知道了；其他處理模塊根據系統特點來決定；對於各個模塊直接的關係也很有學問，根據系統的不同能直接調用的儘量直接調用；最好不要套什麼外殼或者做一箇中間層，處理不好後患無窮；
b）.規則簡單：包括程序處理規則和編碼規則；首先說程序處理規則，對於a）中其他模塊都是爲UI服務的，所以滿足UI快速及時處理時第一位，對於UI調用其他模塊刷新界面一般都用異步，異步就牽扯到數據通知和刷新，對於刷新一定要確立好處理規則，整個系統就用這種規則統一處理；這樣做的好處多多；有兩種情況，一種是UI發起請求，請求後臺數據，對於這種情況一ios爲例，兩種處理最好:GCD和delegate;第二種情況是後臺有數據需要刷新界面，也有兩種處理方式KVO和Notifycation；我更喜歡後者，當然可以用其他方式，比如delegate，不推薦使用；條條大道通羅馬，我一般選擇少寫代碼容易維護的道路。多一行代碼多一個坑嘛。
對於編碼規則，我想我也不想說太多，這個必須要有；最重要的是一些命名規則，書寫格式和關鍵代碼的處理，大家都按照規則處理，代碼可讀性會增強很多，也便於維護。
c).關係簡單：各子系統或者模塊之間儘量減少交叉引用；要利用好每個操作系統或者變成語言提供的有效設計模式來處理其關係。

以上是個人基於架構設計關於簡單的理解和經驗總結，到現在肯定有人會提出疑問，按照我的設計規則來設計，如果有功能需要擴展，如何擴展？這個問題很好，各位先不要着急，下面我就回答一下：
首先，簡單並不表示沒有擴展性，在設計的時候要考慮有一定的擴展性，不能太過度；考慮太多，設計太複雜會變成過度設計，我參與過很多項目，有很多就是由於前期考慮太多，可擴展性太強最後導致項目很難維護，多了很多本來不必要的模塊和子系統。所以這個度一定得把握好，個人意見寧可少擴展，也不要多擴展。因爲少了我們可以通過重構來完成。
其次，重構是另一種設計，如果出現bug，或者有一些新的小功能需要實現，切記打補丁，一定要理清關係進行局部重構徹底解決問題，如果採取打補丁，久而久之就會成爲系統累贅，到最後換上幾岔人，誰也不知道突然出來的一段代碼是做什麼的，變成一個沒人敢動的孤島。如果整個系統架構簡單，處理流程和規則都簡單，發現不符合規則的進行重構，這問題可以避免。當然這樣做是需要領導支持的，因爲重構是需要時間成本，這個時間成本和讓項目失控比較起來，我想還是划算的。

這就是開始簡單，修改重構，過程可控。如果設計一個系統到最後變成一個不可控的項目，到最後都擺脫不了推倒重來的命運，因爲沒人能搞的定，還不如重新設計一套系統來得快，重新設計可以吸取老系統的教訓。

還有一點，就是一個系統設計好了，要和相關得人商量開會再定奪，這個過程叫review，畢竟一個人得能力有限，也有盲區，大家取長補短，三個臭皮匠還抵一個諸葛亮呢，何況一羣高級碼農呢。

所以一個項目的關鍵不是有幾個高手能解決問題，能當救火隊員；最好的情況是能有一個好的架構和和一套規則，讓項目變得可控，即使城頭變換大王旗，我自渾然不動可把控。

本人文筆實在不是很好，不能妙筆生花，力求能說明問題，我一向很隨意，也許沒有很強的邏輯性，大家湊合看懂就成。如果有好的建議和意見，還請多多提醒和賜教，本人會虛心接受，活到老學到老嘛。對於無禮謾罵本人一向拒絕，請有此想法的還是免開尊口。



小文寫至此處，也要快結束了，照我個人習慣，對自己也有個總結。對我來說2012很有收穫，當然主要是在碼農得技術生涯上得收穫，11年算是入行進入移動互聯網，開始移動方面開發，12年算是對移動互聯網有了一個更深得理解，在技術上面也更近一步，一個產品如何從想法到最終產品發佈基本有自己一套運作方式了，人多有人多得玩法，人少有人少得玩法，我是一個方法論的推崇者，只要掌握方法，靈活運用就能解決問題。

2013年已經來了，我們還得生活，只要你還活在這個世界上，就得忙碌，正所謂“生容易，活容易，生活不容易”；這年頭什麼都漲了，就一樣不怎麼漲，我不說你也知道是什麼，畢竟年景不好，想開點，別給自己添堵，喜也一天，憂也一天，有什麼理由讓自己放棄喜選擇憂呢？希望大家在2013年都有一個好得收成，天天好心情。