项目总结：做得不好的地方

故事背景

1. 我一直以为读了《聊聊架构》，就是架构师了。原来，真的是自己想得太多了，也把事情想得太简单了。书分两类，一类是大量的理论思想的解释，另一类就是操作实践。没有所谓的对与不对，这个需要根据自己的需要，然后选择当下自己是需要思想呢，还是需要操作实践呢。
2. 读书，如果只是读书，则读完后会自我感觉特别好，以为自己会了，其实，真的不会呀。知识没有在真实的项目中运用过，永远不知道其细节，又谈何说会了呢。
3. 赞同同事的一句话。搞这么多理论干嘛，跟一个完整的项目，什么都会了。就好比，学英语就应该多听多读，整天背单词，这不是在骗自己吗，又辛苦又没有什么作用。
4. 学习真的是一件痛苦的事情呀，还是躺在沙发中，听着歌儿，就这样舒服地活着好。为什么有时候，我们总是这样呢。明知道有些方式是错误的，但是还抱着侥幸心里，依然原来那样。
5. 以为读了 《聊聊架构》，理解了所谓的架构究竟是什么，以为揭开了它的神秘面纱。其实，好像不是这样的。是需要自己在实践真实地设计一个架构体系，才有可能理解这个架构究竟是怎么回事，其他的，几乎就不太可能理解了。

---

做的不好的地方

1. 粗心。看文字信息不细心，把调用redis-server指令搞错。这给自己带了很大困扰，既浪费了大量不要的时间，也浪费了自己的精力。因为以为自己对了，排错的时候，就不会往这个指令的正确与否进行思考。以后要仔细，要细心，在细心。
2. 没有弄明白redis指令就开始编码实现。因为也是赶时间，没有仔细跟完成指令的负责人沟通，没有理解到那几个指令相互之间的关系，以及它自己本身的含义就盲目地开始使用。急，太急了，这个世界逼迫人。以后要对不明确的东西，要勇于询问，大胆追求真理。
3. 定时任务 + 死循环。没有理解到，定时任务其实就是一种循环，为什么要在定时任务中写一个死循环呢？
4. 单元测试不过关。时间太紧了，需求不明，因为需要把功能做出来，然后给客户看看，然后在修改呗。以后每完成一个功能，要进行测试，反复地测试，不开玩笑。如果代码是普通的简单的顺序调用。比如跳转，比如访问数据库的逻辑或者访问缓存的逻辑，这些逻辑是不需要测试的。单元测试指的是一个小的业务逻辑方法。单元测试用来测试软件工程师自己写逻辑，如果代码里没有逻辑就不需要写单元测试了。
5. 未好好梳理任务。未好好对项目的bug进行整理，未好好地梳理需要量和预计估时间，也没有认真思考任务的轻重缓急。
6. 对应用中的任务未设置线程池。并未把spring中用到的异步线程，用线程池去管理。
7. 对okhttp的使用也没有使用线程池方式进行管理。
8. 日志记录不规范。
9. 附件做法不标准。

---

小结

1. 理论终究是理论，能说跟动手做事是不一样的境界。

2. 把这些做得不好的进行改善就行了。

3. 科学就是记录实验数据，分析出规律，也许是上百次的试验，但只需成功一次。而技术的背后其实就是自然规律。找到问题了，找到规律了，下一次一定能够做到自己满意的。

4. 引用《聊聊架构》中的话来结束：任何技术都是为了解决某种问题而存在的，学会了很多技术，并不代表能够利用这些技术来解决问题。学会的技术的多少，所带来的差别只是解决问题的手段多了些而已。但是手段多了就一定是好事吗？学会的技术越多，很多时候越不知道采用哪种技术更好，所谓“乱花渐欲迷人眼”。