Code Review

让大家对代码质量的标准是在一个线上， 是一个相互学习的过程。 blog主要是用来记录当时的笔记与自己的一些感想

用户中心的接口，需要查用户之前捐过的一些订单

ContextUtil.getUserId(()不建议使用 限制了使用线程的场景，可能每一段代码执行的线程可能不在一起了 讲究的是 变量来源应该是外部的,参数是传入的 swing local ？本地的东西 context 在子线程中是无法工作的，Util这个工具类，不应该涉及到线程这种复杂的东西

interceptor， implements HandlerMethodargumentResolver，//可以直接解析参数（将token解析的过程，就放到这个里面了）
(@LoginUidAttribute String uid)

拿到userId的，isDelete()可以不用判断

解决泛型，warning 加

PageHelper是用的swing local

mapper上面的select 一定要体现一个sql,查询条件一定要解耦，不要太复杂了

不要写太多的if OrderBizMapper.xml 这样可以更好的去维护索引

不建议使用copyProperties，只要一个属性对不上可能就会

使用long不建议使用int，java中一直诟病的，就是java中的对象看不出来到底是不是long null

新的语言都解决了 null会不会有问题的东西。 创建一个 optional 约定就是，可能为null int 是不能为null的 interger是可以为null的 这样可以增加代码的意义的传递，这个就是一种约定 ，使用原生的类型比较好

链式的一个使用的方式，每一个点放一个行,因为一个点就表示一个操作了

order.stream()
.map(OrderBizVo::new)
.collect(Collection.toList())这样会更加java 8一点
.map()
.distinct()
.collect(Collections.toList()) //就可以

返回给前端最好返回是一个空的集合而不是一个null，这样前端会更好处理一点

每一个表建表的时候都需要加一个 isDelete

update 不涉及索引的，不能一味使用

查sql，一般不应该根据sql来加，先是业务来看怎么查的？（冲突与建议）查询的时候只能将sql交给dba，沟通的简洁

连点增加锁的操作，token不用放在数据库中，这种没必要持久化的东西，就放到redis中

为什么是double check?

是处理单例的时候才会使用double check，早起的java处理指令重排的时候，会导致一个check会被跳过去的，所以才处理了double check （在说什么？我怎么开始听不懂了），两次的话，就总有一次会成功

e.printStackTrace()是禁止的

使用

log.error("",{},e);

token的延长时间

一个是长效token,一个是短效的token,这样子的话会更加安全一点

左边代码行的地方右键使用annotation

可以看见是谁写的代码 这个功能就很尴尬啊（原来是可以知道代码是谁写的啊）

不要在异常中处理业务逻辑

每次抛异常的时候，会把栈中的东西都抛出去，使用runtimeException来处理（对性能要求高的时候，code优先，返回ErrorCode）

批量长链接转短链接url

使用key value，放在redis中，同时可以存在db，在上边加一个缓存加一层redis toC查询的过程

连续插入

上一个请求insert来了，马上又来了一个 批量 insert ignore 就行了，插进去就行了 通过一个id，md5（效率很快）的碰撞概率，smartcode 短连接然后就可以返回给 这个算法的奥义是六位，然后保证不会重复

The MD5 message-digest algorithm is a widely used hash function producing a 128-bit hash value. Although MD5 was initially designed to be used as a cryptographic hash function, it has been found to suffer from extensive vulnerabilities. 维基百科

我们尽量不要使用事物，transaction，并发性会很低

这是一定可以避免的，使用最终一致性 更新很多表的问题，应该很少出问题 后台打log,都会有专门的人来进行数据的修复，不要为了这个牺牲性能 （先跑，然后就人来修） 使用事物的话，还会对数据库造成锁的问题 事务的话应该尽量的小

批量更新的建议

整个这个东西，最开始的时候一定要分批的去搞 超过100个的时候就是一批？

redis

redis 有pipeling来做，速度会比较快 zSet是排序， mSet是大量的，但是好像没有超时的时间， 批量写缓存

StringUtils

有isEmpty(),也有isNotEmpty()