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服务器超时时间是多少？
开发一个功能点，一个页面，就必须对这个页面负责，所有问题尽量早些处理，靠别人提醒的话可能就已经到线上或者是最后关头了，那样付出的代价要大得多。
对前端的过渡依赖已经严重障碍了工作的进展！！！
互利的交往才会持续的交往和久远！