本文是個人的一些總結，有些因爲是內容和數據是機密就不詳述了，主要記錄了一個算是大型項目開發過程中需要考慮的地方，當一個用戶量多後，很多東西都不能用常識來估量，也會出現各種奇妙的情況。
1、項目初期
瞭解項目需求、功能點分析、整個項目的業務流程、需要接入的外圍系統及其產品負責人、開發負責人。當前項目的週期、開發人員、測試人員。
和市場人員確認活動影響力，評估訪問流量UV、PV、QPS（峯值），後繼問題如果影響力不足，如何降低門檻；如果超出預期如何做。
2、項目開發
o 開發：
§ 代碼開發時候後使用的框架、代碼架構模型，不同的團隊可能有不同的思維和方法，大家約定好之後按照統一的方式來編碼才能避免之後代碼風格不同、雜亂乃至失控。
§ 開發過程中的單測很重要，即使在初期因爲趕項目進度，也要把單測的環境準備好，而且因爲數據訪問層基本沒有業務邏輯，這個部分的單測一定要有，在開發的時候進行數據驗證、SQL檢測用處很大，在自測聯調的時候就不用因爲數據庫訪問部分代碼的錯誤頻繁重啓服務。
§ 業 務種類分爲2種：活動業務和常態業務。最杯具的情況是活動業務只做一次（如果3-4/年那就是喜事了），而且業務規則和常態業務基本沒有相同的地方。在短 時間內爲了實現這些規則寫了很多一次性代碼：例如因爲節省前端資源，所有的運營數據的全部用excel導入，後臺編寫了大量的excel解析和數據驗證邏 輯。需要設計人員區分這些一次性的代碼、易變的代碼、以後有可能被用到的代碼、肯定會被用到的代碼，儘量擱置在不同的類中：有些當做基礎共用的代碼、有些是臨時的數據邏輯轉換代碼，通過面向接口的設計來兼容不同的數據導入和解析方案（例如從excel轉爲web傳入、生成展示數據的策略由每日改爲每小時 等），用單測來保證無用代碼被刪除後對整個業務影響度爲0。
§ 根據業務複雜度來決定是否進行模 塊切分：業務功能來縱向切分成不同的子模塊、同一個業務功能的優先級來進行分組切分（可以通過代碼配置進行軟切分）、基礎服務相同但是使用場景不同進行橫向切分（Web端、MobileNative端、MobileH5端用的都是同一套基礎服務，但是使用不同的接口API）
§ 根 據預估的數據量來決定是否使用數據庫or使用配置；使用哪種類型的數據庫，配置的數據是否經常會變化。在本次活動項目開發中初期因爲數據量少，需要創建的表少，爲了加快開發的進度，開發初期直接使用了另外一個項目的測試環境的數據庫，之後上預發環境才讓DBA單獨建庫。使用配置文件，如果配置的數據會有機率變化（雖然比較低，而且數據量少），這種數據量小而且有一定變化機率的數據可以考慮依賴內部配置平臺：diamond/configserver，例如系統早期時候的用戶權限配置模塊、一些枚舉型數據
3、測試與產品體驗
· 測試同學在產品啓動初期就開始參與進來，熟悉產品需求，review開發人員的架構和設計方案，編寫測試用例。進入測試階段之後，彙總每天的測試狀況，根據測試結果提出產品改進的方案，決定產品是否能上線。
· 測 試同學全程參與產品整個生命週期，在開發階段任何實現的調整都應該通知到他們，否則使用舊的測試用例來測試修改後的產品-conflict！！！開發同學 在編寫代碼的時候一定要注意功能的易測試性，例如：如果產品是和時間有關係的：某個時間點功能纔會有效，一定要有後門界面供測試使用；如果業務的最終數據是流向其他系統，要考慮數據查詢工具供測試同學驗證數據；業務出錯後的信息提示是否明確，作爲首批用戶而且是瞭解業務的用戶都不瞭解錯誤信息，那就說明設 計出問題了。。。
· 在每次做項目/產品的時候，發現UED同學佔用開發的時間，開發同學佔用測試的時間，測試同學佔用？？？他們沒得佔用，只能在deadline之前苦逼的加班，開發同學也只能陪着苦逼的解bug。上線日期確定的情況下，如果時間 不充足，每次的需求調整對開發，特別是測試同學都是很大挑戰，本次活動大量的時間在做功能回顧，有些產品上的體驗細節大家都沒有注意到，導致上線之後又發佈緊急修復：頁面刷新導致用戶之前選擇消失，這種體驗細節只需要幾分鐘的開發成本，但是對於用戶來說是很不友好的情況都沒有精力去關注了。。。
· 爲 了產品的進度，會要求開發人員分模塊開發，然後按模塊提交測試，有個問題就是開發同學剛剛完成代碼開發，並沒有充分自測，這個時候測試同學就開始介入，會出現大量的bug，開發一邊開發新的功能，一邊修復bug，會導致bug reopen率高，開發效率降低的問題。需要測試同學排出每個bug的優先級和緊急程度。
4、項目穩定性
功能提交測試之後，開發人員的任務只是進行了一半。根據之前預測的訪問量，需要理出每個業務流程耗時、耗資源的步驟、哪些依賴是必須的、哪些依賴是可以容錯的（在必要時候可以進行依賴降級）、在壓力過大的情況對外提供的服務是否可以進行服務降級。
- 依賴：在本次活動中，商品信息、交易系統是強依賴，用戶購買資質的判斷是弱依賴（即使這個服務出問題，做好相對的規劃進行依賴降級，依然不會對整個購買主流程產生影響）。任何和金錢相關的交易（包括優惠信息）都是強依賴，在整個業務流程中是不可以被繞過的。
- 限 流：當前當前服務接口被訪問的次數超過預估的峯值或者服務內部出現異常，需要考慮使用根據訪問者的業務優先級、訪問的頻率對部分訪問或者全部訪問進行限 流。這些限流降級措施需要和服務使用者預先進行討論，告之做好相應的容錯預案。至於限流的技術可以通過代碼、通訊協議層、硬件路由實現。
訪問頻率、系統依賴之類的數據需要有相應的監控系統完成，這是公司基礎技術設施必要的組成部分。例如：eagleeye可以查詢系統依賴及其某一個業務流程在不同系統之間的調用頻率和訪問路徑。至於QPS/RT/機器負載之類的監控已經有很多開源解決方案。
爲了真實模擬線上真實請求的壓力，引入雙11巨牛的“全鏈路壓測”來分析業務中是因爲哪個依賴系統導致的木桶短板。然後確認造成短板的原因：編碼原因（鎖、多餘數據庫訪問步驟、cache） or 系統硬件環境（虛擬機情況下的io瓶頸、跨機房時候的網絡瓶頸）
當這些降級限流方案確定之後，由相應的開發人員完成並且提供給業務方集中使用，每次開啓使用之前應該明白相應的後果、應該如何回滾。
5、上線運營
· 本次活動時間倉促，有些數據錄入頁面可能只使用一次，故未開發，使用excel的方式導入到系統，數據是由運營同學整理錄入。這種方式有點是沒有負責的前後端交互，但是缺點很明顯：錄入的數據因爲沒有頁面交易，很容易出現不符合格式的數據：格式錯誤、數據重複等等，有些可以預料，以後由代碼處理，但是有些已 經超出想象。時候反省：任何數據如果沒有校驗，都是不可信的，即使明確告之單元格的內容完全是固定的，這樣需要後臺代碼校驗。這也是做UGC產品的尷尬之 處，有很多代碼就是用來校驗數據有些性的，真正涉及到業務的代碼可能只有50%
· 上線之後開發應該和PD、運營確認需要哪些維度的彙總數據，這個時候已經有時間來做數據彙總和顯示的開發了。有些數據可以由兄弟部門幫忙的話，需求最好在產品發佈在預發環境的時候就要提出來-早些提出來時間更充裕。
· 運營和PD會根據銷售數據統計分析，基於日期、地址來分析銷售狀況，臨時決定使用哪些營銷推廣策略來拓展市場不好的地區。不能對自己估計過高，提前找好退路，指定一些營銷補救措施。
· 有些異常狀況是程序無法補救的，需要制定好規則幫助用戶彌補：相應的賠款方案、退貨規則。例如:
o 用戶購買需要線下使用的電子券，當輸入的手機號錯誤，要有可靠憑證證明用戶在線下能夠合法的使用訂單，例如通過交易記錄、卡券包信息之類的。
o 或者用戶忽悠導致自己購買的東西有效期、使用時間不正確，要想辦法統計這些交易數據，並通過短信、應用消息的方式儘早通知用戶。
o 有些商品有購買門檻的限制，如果因爲某些原因誤夠，導致沒有資格再次購買，後臺需要有工具來恢復用戶的資格，否則就要面臨用戶的多次申訴
後記
- 3.7 日活動已經進入尾聲，對於技術人員來說已經可以放鬆了，運營同學還要繼續忙一段時間，這種O2O業務前一半任務是如何把商家的SKU數據全部展示出來供用 戶容易購買，後一半任務是如何保證用戶購買的東西被線下接受、覈銷，這一部分的流程更重要，線下需要和商家的服務人員接觸--服務質量難免參差不齊，用戶 不爽，以後基本上會被用戶拉到黑名單中，線上業務也基本遭殃。
- 個人感覺，O2O業務和互聯網業務區別在於：互聯網沒有地域侷限，在互聯網上用戶是真正處於地球村，任何信息、網絡虛擬服務都不受距離的限制（不要拿那些傳 說中的網站和我擡槓~(≧▽≦)/~）。O2O服務是幫商家把所有的SKU以跟友好、方便的方式提供給用戶隨時查看，用戶不需要打電話給商家諮詢哪一天能 提供哪一種服務，去之前要不要預定，等等（最惱人的是遇見你撥打的用戶正忙，請稍後再撥的提示）；用戶使用O2O業務一般是因爲能夠便捷、優惠購買自己物 理距離之內能享受的線下服務，這也意味着O2O不會如互聯網業務那樣有了流量就有了一切，O2O更應重視在當前線下客流總量下盡力培訓忠誠用戶，回頭客和 口碑比流量更重要。