1.早期的技術(shù)選型，沒有準(zhǔn)確估計實際業(yè)務(wù)量，一定不要參考一線公司的技術(shù)選型，首先實現(xiàn)起來很復(fù)雜，其次技術(shù)面鋪的太寬。
（夠用即可，出生階段，需要能快速實現(xiàn)產(chǎn)品。從0到1的時候需求上的假設(shè)都沒有驗證，沒必要折騰APP。）

2.早期的技術(shù)選型要考慮高內(nèi)聚、低耦合。
（不是不為未來考慮，而是分清主次，高內(nèi)聚、低耦合的方式能在未來業(yè)務(wù)擴張的情況下實現(xiàn)業(yè)務(wù)的拆分，讓系統(tǒng)間的依賴性減少）

3.人力成本衡量，最新的技術(shù)往往依賴核心的技術(shù)人員，以最新的技術(shù)做框架，要做到關(guān)鍵崗位有備份人選。
早期的手段可以粗糙，云服務(wù)是一個特別好的選擇，幫助企業(yè)和團隊節(jié)省大量成本。

4.電商，流量是最大的成本和Keyword，解耦流量這個詞：賣給誰以及怎么賣。
（目前線上流量成本很高，其次都是一次性的，再次喚醒用戶的成本很高，例：我買完手機以后，再買第二個，很久，很難，并且不一定在你這里買）

5.線上+線下。
提到微信，近場能力線下拉人并配合微信支付進(jìn)行營銷?？焖衮炞C，高效拉人。
線下的好處可以最大發(fā)揮：通過選擇地點，圈定潛在用戶。所以初期技術(shù)的選型務(wù)必考慮微信的元素進(jìn)去。實現(xiàn)相關(guān)營銷。

6.購買流程上必須完善，不能有技術(shù)短板，其次做好產(chǎn)品為核心的營銷數(shù)據(jù)流。
可以考慮memcache，redis等分布式緩存系統(tǒng)，應(yīng)用改成與狀態(tài)無關(guān)，方便擴容及增加節(jié)點。
片面的追求百分百可靠都是異端，滿足80%的高質(zhì)量用戶需求即可。量力而行，做人如是，技術(shù)也是如此。

7.一個靠譜的CTO，他的經(jīng)驗決定了未來產(chǎn)品的技術(shù)棧。

技術(shù)總結(jié)：前端、業(yè)務(wù)層、數(shù)據(jù)層。

前端下分為：移動端（IOS,Android）PC端。

業(yè)務(wù)層開發(fā)restful接口給前端調(diào)用，http協(xié)議json傳輸數(shù)據(jù)，前后端分離，分開部署，接口文檔工具采用阿里的RAP，減少前后端溝通成本。

前端nginx分流，（不一定適用nginx+lua）lua可能會把控不住。靜態(tài)文件考慮七牛和又拍。

后端業(yè)務(wù)層采用springmvc+mybatis，應(yīng)用服務(wù)器XXX（待定），搜索業(yè)務(wù)采用soir，訂單業(yè)務(wù)用隊列服務(wù)器rabbitmq。數(shù)據(jù)層，分布式緩存--豌豆莢開源方案codis。

數(shù)據(jù)庫層我了解的不多，基本一些點：減少表的關(guān)聯(lián)查詢，為后期的分離、服務(wù)、可讀性做考慮。