13年上半年開發經驗小記

框架搭建：
1.統一常量、枚舉類。
2.統一各層方法返回值。
3.統一自定義異常。
4.統一日誌輸出。
5.ibatis文件規範。
6.關於分頁的統一。
7.ibatis文件中不要寫過於動態化的sql。
8.最煩開發時間不足，還沒開發好久給測試了，測試一天到晚盯着屁股喊。
9.一個好的開發工程師，任務分解越細越好，沒有底線，開發時間評估，執行力比什麼都重要。
前後端連調：
異步請求返回json列表，最好不要講普通的vo對象轉換後輸出，因爲這樣會有很多無用的值。
且無法根據入參動態決定要返回哪些參數。

表設計：

一開始要考慮全面。

靈活應對：
根據訂單id查點評的問題處理，換個角度，一切問題迎刃而解了。

縮減rt必經之路：
性能：
1.搭建search，避免多個數據源關聯查詢。
2.組裝好的結果放入cache，下次直接返回。
3.分佈加載，先加載軀幹信息，再用lazy方式加載額外信息。
性能：
1.搭建search，避免多個數據源關聯查詢。
2.組裝好的結果放入cache，下次直接返回。
3.分佈加載，先加載軀幹信息，再用lazy方式加載額外信息。


<res-loaders:file-loader basedir="D:/apps/vmcommon" />


存儲鍵值對：
<itemId,item點餐相關內容(id,title,oriPrice,price,soldNum,picurl,isDiscount,isRecommend)>
<localstoreId,<name-id,name-id,name-id,name-id,name-id>>所有寶貝title和id，支持根據寶貝和關鍵字查詢

<localstoreId+類目id+timeDesc，數組型的寶貝id列表>
<localstoreId+類目id+timeAsc， 數組型的寶貝id列表>

<localstoreId+類目id+priceDesc 數組型的寶貝id列表>
<localstoreId+類目id+priceAsc，數組型的寶貝id列表>

<localstoreId,類目LinkedHashMap>

<localstoreId+timeDesc,數組型的寶貝id列表>
<localstoreId+timeAsc,數組型的寶貝id列表>

<localstoreId+priceDesc,數組型的寶貝id列表>
<localstoreId+priceAsc,數組型的寶貝id列表>

容量：
每家店50個類目（1KB),500個寶貝(5KB),各種類目加起來每家店10KB的內存，1W家10M

數據初始化：
對於寶貝數據初次查詢並加入到tair，以後在變更時更新到tair，永久即時緩存。
各種不同key值索引緩存與寶貝緩存類似做永久緩存，在類目或者寶貝更新時觸發即時更新。


使用：
根據分頁參數，在緩存的數組或者list中找到(al.subList(fromIndex, toIndex))符合條件的id列表，再據id列表索引出對應寶貝集合，返回給前端。
tair失效：
所有店鋪的數據在初次查詢(第一次訪問該店鋪頁面的人)時進行初始化，壓力也不會過於集中。

性能推測分析：
目前
調用一次實時搜索大概,平均20ms：itemInstantSearchService.search
取一次ic的寶貝，平均10ms：getItemReadService().queryItemById
tair方案
從tair中取200個byte時間在2ms
foreach兩層嵌套循環300*6次在20ms
那麼：目前方案一家店20個類目20次查詢*20+500個寶貝各查一次*10=5s
而tair方案20ms+500*2=1s
實驗驗證：基本符合推測，性能提升5倍
一般web服務器超時時間是多少？
開發一個功能點，一個頁面，就必須對這個頁面負責，所有問題儘量早些處理，靠別人提醒的話可能就已經到線上或者是最後關頭了，那樣付出的代價要大得多。
對前端的過渡依賴已經嚴重障礙了工作的進展！！！
互利的交往纔會持續的交往和久遠！