导语
一个优秀的程序员，应该有自己的个性和风格。而这种个性可以在自己的代码里体现出来。我们写的最多的是业务代码，因此我们应该在写代码的过程中，总结出优秀的习惯，并持之以恒的实践它。
这样做有什么好处呢？
除了可以让后来看你代码的人在心里默默的念叨：原来还可以这么写啊？以外，最重要的是一眼看出这是我自己写的代码，就想能认识是自己写的字一样。有自己的风格，才不会是一个只会CV的码畜。当然，风格一定是要规范的。
开篇明义：会不会合理规范的打日志是辨别一个程序员是不是一个好程序员的最简单的方式。所以，为了不被轻视，一定要记得打日志哦。
异常
异常是我们编码过程中不可避免的元素。我们既要处理别人抛出的异常，同样也要学会在合适的上下文抛出合适的异常。使代码的逻辑性变强。
- 异常日志三要素：在什么地方（业务场景名称，便于快速定位，如撤销订单），产生异常时的上下文是什么(方法入参)，发生了什么异常，。
- 业务异常使用info日志，未知异常使用error日志。避免如参数错误(业务异常)等异常导致的error日志。因为error日志一般会被监控并邮件通知相关人员。业务相关的可以预期的异常可以用info日志来记录。
- 使用自定义异常来进行业务逻辑处理可以使代码简洁明了。在业务处理逻辑合适的地方抛出异常并在业务入口catch后统一处理统一响应，可以避免各种冗长复杂的if卫语句。可使用jdk自带的很多语义化的标准异常，一般为运行时异常，避免了编译期的异常处理样板代码：如
IllegalArgumentException,IllegalAccessException,IllegalStateException等。同时可以定义语义化的业务异常,自定义异常书写时比较繁琐，但是好处很多，一个优秀的程序员为了写出易读易拓展易维护的简洁代码，应该在写代码时不厌其烦，这样对自己对同事都有好处。 - 自定义异常类可以自定义字段携带异常上下文，这样可以在catch时做出详细的log记录或者响应。
日志
日志就很关键了。有经验的工程师都会合理的打log。不怕你多打log，就怕你不打log。多打log使用低点的日志等级就行了，不打log的话就很尴尬了。同时打log要注意携带log的上下文，就是说必须在log里说明这个log输出的条件是什么，比如一个文件名，一些方法参数，if条件的判断值。要学会把我关键节点，如关键分支开始，关键循环结束，长时间线程静默开始。
- 在我们的日常编码过程中，对于日志记录的重视程度总是不够重视。先想着逻辑走通了再补日志，走通了之后又懒得再去看自己写的代码了，这是极其不好的编码习惯。在我们的编码过程中，尤其是业务相关的代码，对于打日志这件事不能偷懒。虽然打日志会对服务器造成io负担，但是如果合理的使用日志等级，规范的记录日志可以有助于的开发时的调试，上线后的监控和问题追踪定位。让我们可以不透过代码，而是随便ssh到服务器上看下日志就知道发生了代码正在干什么或者代码里发生过什么问题。
- 日志中记录最重要的三要素：时间戳，线程名，内容。根据线程名和时间戳可以在文本工具中还原一个业务请求的执行逻辑路径。
- 异常日志需要打印堆栈，也就是异常对象。
- 记录日志是一个优秀的编码习惯。不应该只简单的打入参日志和异常日志。如下几种情况也应该记录日志：
- 重要的逻辑分支处。在重要的if逻辑分支处应该记录日志，便于监控和调试。
- 一些耗时很长的操作，如长循环，图片上传，excel解析等，此时线程会阻塞，提前记录日志可以通知调试人员线程即将阻塞静默。
- 异常日志要记录异常上下文。
- 一些标志性的动作或者事件发生时应该记录日志。如，监听器开始处理spring发布的某个事件时，缓存初始化完成时。
工具
每个手艺人经过日积月累，都会积累下自己使用的最趁手的工具，并且非常熟悉它。我们程序员，其实也是一种手艺人，因此，熟练的使用一些别人封装好的轻量级类库，可以使我们的java代码更干净更简洁同时更有效率。在这里，首推Guava。
数据库相关
- 表设计的通用字段，
ID，IS_DELETED，CREATE_TIME，UPDATE_TIME，COMMENTS。与此相关最关键的是，在进行增删改查时要记得更新相关状态字段。如果不更新，那就跟没有这些字段一样了。必要时可以在mybatis的sql中硬编码。如：
<if test="isDeleted != null">
IS_DELETED = #{isDeleted,jdbcType=VARCHAR},
</if>
UPDATE_TIME = NOW(),
<if test="comments != null">
COMMENTS = #{comments,jdbcType=VARCHAR},
</if>