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等越来越好了，功能感觉倒是不太多。
以前感觉很多产品，都是拼功能，现在拼体验。
我觉得，应该是现在的产品太多了，用户的选择多了，光拼功能是不能应对市场竞争的。
这一点，正需要注意。