项目总结：需要改善的地方

故事背景

1. 以为很认真读了如下好书就会变得厉害：
   设计模式：《Head First设计模式》和《设计模式 可复用面向对象软件的基础》
   代码结构: 《重构改善既有代码结构》《代码整洁之道》
   代码内容: 《修改Java程序151个建议》和《Effictive Java》
   整体提升： 《代码大全》

2. 技能是真的需要天天练习和思考的。以前以为自己编码技能提升上来，该注意的很多细节都能够考虑到，写得代码也十分简洁，可是当自己不在继续在这方面深耕的时候，这个时候即使以前会的，都慢慢地变成不会的。就是应了这句话：”学如逆水行舟，不进则一定退“

3. 如果没有大量看别人的代码，如果没有大量编写代码，以前掌握的技能或者说会的技能都会退步的。以前会从请求和响应的整个过程去思考和排查问题，但是如果没有项目让自己练习，那么就会遗忘或者技能就会退步。这是真的。

4. 以前会好好思考如何才能写出优美的代码，虽然花了时间在类的设计上，会仔细考虑类的名称和类的属性，以及方法名称和方法做的事情，这样写出来的代码非常简洁，而且后期维护起来也十分容易。可是这个世界告诉我，代码好不好不重要，重要的是结果。也许有一天成为了高级工程师这一切的问题，都不会是问题了，因为可以在较短的时间内设计好一个类，也能够在较短的时间内组织好类的架构体系。

需要改善地方

1. 单元测试。对于控制逻辑代码不用测试，对于数据访问层代码不用测试，如果有问题那就是数据厂商的事情了，应该好好把自己写的业务逻辑，一些必要的判断和计算问题好好测试一下。尤其是一些BigDecimal类型被Gson转成json字符串后，结果是自己预期的吗？很多自己以为的想当然的，在程序世界里可是不一样的，唯一能够做的就是尽可能多的测试。“程序世界，要通过测试来确定一些情况，不能主观地想当然”。
2. 日志调试。代码逻辑出现问题了，不应该去跟人争论，代码应该是或者绝对是怎样运作的。正确的做法就是，好好地分析日志内容，定位到问题位置，分析问题产生的原因。但是，一般可能会很难，因为可能是异步造成的。做一个标准的日志规范是非常重要的一件事，其他的内容虽然也重要，但是一定没有日志规范重要。就像航海日志一样，记录着整个行程。系统日志也特别重要，记录着系统的运作流程变更信息。
3. 未考虑到为Null情况。未使用common-lang提供的一些基本的字符串或者对象非空判断。
4. 代码写成if–else了。以后无论怎样，至少也用个switch case嘛。以后还是需要把过程式的代码写成面向对象的代码，这样会稍微好维护一点儿。尤其是方法的参数传参的时候，把基础类型的参数作为一个对象的属性来当成引起数据类型传递，好理解。
5. 业务逻辑和控制逻辑和基础设施代码隔离开。把基础设施代码采用aop的方式或者注解的方式去执行，这样就可以和业务逻辑解耦。把控制逻辑代码拆出来，不能和业务逻辑代码耦合到一起。这样，基础设施代码（日志记录，请求和响应的加密或者解密），控制逻辑代码和真正需要专注的业务逻辑代码就完全解耦出来了。并且控制逻辑代码和基础设施代码是研究好一次，以后在任何项目都完全可以拿来复用的，非常好的一种思路。
6. 代码写成了箭头式的或者一个个小部分整体。在核心业务逻辑中，应该是一句话式的写作方式。不要有try catch finally这样的块代码，像这些不必要的块代码都找开源工具来代替。核心逻辑中也不要有if else之类的块代码，弄个return截断都是比较好的做法。
7. 未考虑到事务，并发，异步，冥等性问题。这个是以后需要注意的问题，对于任何一个功能，哪怕是在小的功能，都需要考虑到如上4个基本的问题。
8. 在项目周期中，晚上回家未好好地梳理逻辑，以为累了，就躺着睡了。以后需要好项目中的核心逻辑好好地反复地梳理一下，这是一个特好的习惯，会走的更快一点儿。
9. 每天的任务也没有好好梳理。每天需要花个10分钟哪怕20分钟，好好整理一下需求量和任务量，然后根据轻重缓急去合理安排工作时间。
10. 沟通。无论项目需求变更的多么厉害，需求多么不确定都需要收住自己的那颗心。急，也是没有用的。沟通其实是最重要的一个环节，以前以为写好代码，写好功能逻辑就完了。越走越发现，软件行业，最重要的是对需求的精确理解，而对需求的精确理解是建立在沟通之上的。如果沟通和交流没有做好的话，后面的工作就不好做了。
11. 讨论。遇见问题，总是一个人死扛。遇见问题还是应该积极主动跟身边的同事讨论，寻求一些帮忙，别人就是擅长表结构设计，设计出来的表结构就是清晰易懂，也能够应对需求变更，为什么不主动学学，去追求真理呢。
12. 基础设施代码好好整理一下。
    日志规范最佳实践
    附件最佳实践
    必备文件的最佳实践(配置文件，README.md, init.sql, start.sh, stop.sh)
    响应码最佳实践（统一规范，制定标准，便于排错）
    开放接口设计最佳实践（rsa, aes,盐，冥等性）
    异常的最佳实践
    冥等性最佳实践
    异步事件监听最佳实践
    mybatis-generator的最佳实践。（自动代码的生成，使用criteria, BaseMapper，dao和mapper配合使用）
    okhttp最佳实践
    maven（gradle）最佳实践
    git最佳实践
13. 多讨论多问人没什么的。这不是脸皮厚，这是追求真理。现实就是这样的，想要的东西需要付出很多，包括时间和精力，甚至健康。

小结

1. 书籍是当自己刚接触一个新的东西的时候，浏览一下目录，了解一下大概内容，做到心中有数就行了。
2. 当自己有了实践经验了，发现了自己的不足，发现了自己并没有因为看看书就变厉害了，依然会暴露出无尽的问题。然后把需要改善的地方多注意一下，下次好好做就行了。这个时候在回过头去仔细读读书，也许才能够体会其中含义。
3. 路是这样一步又一步走的。以前特别着急，总想一口吃一个胖子，才发现世界上没有这么好的事情，还是需要一步一个脚印地走。走就是了，至于多远，已经不重要了。