1.数据库字段命名的3种方式。
  uid、user_id、userId。
  从数据库角度来说，最好的是user_id。
  从Java程序来说，最好的userId，查询的时候，不用再做字段映射。
  从简洁的角度来说，uid最好，看了简单，而且也不用做字段映射。

  目前主要使用的是user_id这种风格，再考虑是否使用uid和userId这种。按照数据库的标准来定义字段，感觉也没啥实际好处样的。
强迫症扔扔纠结啊。
  类似的，还有3个时间字段create_time用ctime，update_time用uptime，delete_time用deltime。

2.冻结资金也是有类型的。
   投标、提现、转账等场景可能都有冻结需要。
   项目中，用的少，简化了，没有要这个冻结类型字段。

3.收费接口。
  收费，不一定要实时去扣费。 

  插入收费log后，维护一个待处理的数组，待处理的收费id。定时，去处理。而不是定时去数据库查询，耗费性能。
  启动服务器时，需要新建一个线程，加载数据库中待处理的收费id到数组。
  因为，服务器异常关闭时，上次没有处理完的数组，需要再次加载才行。

4.收费统计等统计功能的表结构。
  2种不同形式的表结构
  第1种：我以前主要用这种。
 id、user_id、interest_management_fee、service_fee
  好处是，可读性很好，更新也方便。
  不好的地方是，如果需要新增收费类型，升级的时候，需要修改数据库，升级比较麻烦，而且存在风险。
 

 另外，根据Boss的经验，一套系统卖给不同客户时，每家支持的收费类型可能还不一样。

  因此，有了第2种，Boss比较推荐这种：
  id、user_id、type
 用type来标记收费类型，新增收费类型，升级，应对不同客户需求时，都很好扩展。
 
  缺点嘛，自然是有的。

5. 现在的产品，越来越拼体验了，而不是以前那样堆功能。

  worktile和淘宝钉钉的默认头像是，首字母或者姓名的第一个字母，比如“雷文”的“雷”。这个时候，不同用户的默认头像是不一样的，感觉非常友好。

   产品体验方面，支付宝、worktile等越来越好了，功能感觉倒是不太多。

   以前感觉很多产品，都是拼功能，现在拼体验。
   我觉得，应该是现在的产品太多了，用户的选择多了，光拼功能是不能应对市场竞争的。
   这一点，正需要注意。 

简要总结最近遇到的5个问题