在程式設計的江湖中哪些人能成為江湖高手，取決於思考！
在開發的很多時候，理論一直被忽視，很多程式猿（以前也包括我）只關注怎麼實現某個功能，而並不關注為什麼要這樣做？這樣做的好處是什麼？如果能在開發中帶著這兩個問題去思考，我相信成為ACE將會事半功倍！
一個成熟的架構設計者，會對架構中每個模組甚至每個功能做非常成熟的考慮！

1-業務邏輯和需求功能
在專案開始前，先考慮幾個問題：
a，正確的登入邏輯是怎樣？
b，快取機制？
c，移動和PC端資料同步問題？
d，Native如何與HTML5互動？
e，資料統計，為運營部門提供準確使用者喜好，以及為產品設計提供可參考資料
f，APP推送系統
g，

正確的登入邏輯
看到問題的小夥伴是不是有點驚訝。我開發這麼久了，還不知道登入流程是什麼麼？？？有這樣的一問的小夥伴很正常，當初我也是這麼想的，哈哈！其實登入大家做的都大同小異。使用者輸入賬號，密碼，一定要帶上裝置ID，然後點選登入，後臺會返回一個sessionId或者是token給移動端。很多家的APP會儲存賬號的密碼，其實是不推薦儲存密碼（最好是賬號也不儲存）的這麼做的，因為考慮到iOS，Android兩種系統，密碼儲存到客戶端存在一定的風險，所有資料互動使用sessionId或者是token來標識使用者。這樣可以很好的解決c,d

快取機制
根據具體的邏輯來處理，如果不是剛需，那麼可以考慮使用快取，或者資料庫。但是像秒殺這種就必須是實時，每次需要重新獲取資訊。

APP推送系統
相信很多小夥伴都很熟悉，極光，友盟（哈哈，我就用過這兩個）。還自己用Java給iPhone推送過訊息，本來iOS 可以完全不用第三方，自己後臺實現推送。但是由於Android在國內的Google伺服器被禁。所以Android

還有比如推送活動，如何讓資訊Push到指定頁面？ 都是要考慮到的問題。推送還有一些高階篇的，比如靜默推送
但是如果使用者沒有同意推送呢？怎麼辦？而且有些資訊必須然使用者知道。eg：使用者資金變化了。
第一，APP內提醒他去設定；
第二：和簡訊協同，因為簡訊傳送需要money，所以在使用者同意推送時，就不要使用簡訊了。

2-架構選型

很多人一上來就是MVC，MVVM，MVP，XXXX，當然這個架構本身是沒錯，這麼說也無可厚非。但是有認真想過嗎？為什麼會出現MVC？既然有了MVC為什麼又會有MVVM，MVP？
每個人的程式語言學習，從入門到精通的過程其實就是 面向物件程式語言發展的縮影！
怎麼理解這句話？你想一想：你開始接觸開發的時候，寫的小專案。是不是沒有什麼設計模式，也沒有什麼設計理念和思想。就是把你用到的程式碼寫在能執行的Controller裡面。剛開始嘛，沒關係的！寫著寫著你就發現不太對。有些Demo重複使用，有些Config重複配置，有些Controller邏輯混亂，，，反正就是隨著專案的變大每個地方都不好用了，這個時候你就開始接觸設計模式 了；追本溯源，MVC的發展也就是這麼來的。先驅們發現專案大了，不對功能，業務邏輯分類（或者分層），不對程式碼解耦，後面就很難在寫下去了。

MVC不多說，重要的分析和思考他的來源，出現場景以及優缺點！！筆者請看這裡