断更的原因and思考

先交代下断更的原因。最近系统开仓多、需求多，又适逢临近618，需求想在618之前推广，加之最近推行的加班多，时间更少了，回家就想补觉。

这段时间也踩了坑，分享出来，仅供借鉴。
由于项目调整，最近接手了一个老项目，代码风格陈旧。又接的新需求，也就按照原来代码风格编写了。临近项目验收，测出了问题，需要代码评审。这个时候问题来了，原来的代码风格try catch随处可见，公共方法也没有抽取等等，结果。。。。被架构师怼了。

1.只要你接手了，项目就归你负责了，之前的代码可以慢慢调整，但是新的需求、接口、方法、类等等。要按照公司最新的要求来。不能延续原来的风格
(笔者采坑了，是认为不破坏原有的风格是一件好事，也能降低接手项目修改的风险)

2.代码一定要遵守规范，方便后人阅读，也是工程师文化，验证你内力有多深。简单点的，比如变量命名，更新对象update**开头命名，驼峰命名；方法参数不要过长；if else优化。
方法注释一定要全。特别是特殊场景下的业务逻辑，注释要写全，否则半年后，自己在看，也不清楚了。