2020 年 1-3 月在工作中遇到了很多之前没有遇到的事情，主要目的是为了总结，同时这篇博客也算是《编程人生》专栏的开篇。
背景
由于工作项目上的变化，主管让我尝试去写框架性的代码，不再是原有的业务代码。在写代码的时候也发现了自身的很多问题，的确是需要总结一下今年 Q1 的工作。
我是 15 年的时候在 CSDN 创建了账号，当时也写过博客，博客主要的内容是一些问题的解决方案。现在回过头来看，的确在一些工具类的使用方法会上百度查，而且很多解决方案在 CSDN 上有，在这里也感谢 C 友的辛勤记录，后续我也会记录一些工具类的使用，比如 Netty 的简单上手教程。
Q2 的博客计划
- 完成【面向对象编程思想】的专栏。这个专栏可能看着很无聊，主要是还是自己经历了编写非业务性框架后的一些总结和结合其他大神的面向对象思想总结出的经验。
- 将 19 年中刷过的 LeetCode 题目的解题思路补充到【LeetCode】专栏。
- 记录一些基础框架比如 Spring，Netty 的使用。这一部分也会做成一个专栏。
- 在 20 年 Q2 中遇到一些难解的 Bug 和坑也会相应记录到 CSDN 的专栏中。
- 补充一些面试的技术理论知识到 CSDN 的专栏中。
整体来看，Q2 的计划主要体现在这几点：面向对象编程，LeetCode，面试理论和平时遇到的坑的记录。
专栏的一些展望
面向对象编程专栏
这块主要是想沉淀自己对于面向对象编程的理解。因为接触了不一样的项目后，发现之前把 SSM 从 Controller 到 DAO 这一套面向过程的贫血模型重复了这么多年，其实自己在编程思想上没什么进展。对于设计模式的理论也知道，但是在项目中使用得不够顺滑。现在才明白，只有摒弃之前面向过程思想，从对象建模出发，才能正确地结合设计模式。上述说了那么多，其实最重要的就是，不要着急写代码，先要想明白，要完成这个逻辑，需要用到哪一些对象。对于抽象类不需要提前创建，只要在提高代码复用性的时候提取抽象类即可。不然这抽象类会显得是一个过度设计。
LeetCode 专栏
LeetCode 的题目，我在去年也刷了不少，虽然题目难度没那么难，但是都是一些面试中常见的题目。有一些解题思路，也可以记录下来，供 C 友们和自己参考和回顾。曾经有一道 “岛问题” 的变种题，也得到了阿里面试官的好评。
面试理论专栏
CSDN 上面试有关的博客一直收到 C 友的青睐，因为出来工作都是为了钱，找到好工作就需要面试，只有面试过了，才会有加薪的机会。所以这一类的文章有好多人在看。同时自己在工作中也面试过小几百人，负责的是高级和资深开发工程师的初面，初面看重的是基础技术能力和理论以及面对常见问题的处理。对于项目经验的话，一般会交给后续更加资深的面试官。因为我自己去询问候选人的项目经历，由于自己水平有限，筛选的时候也拿不准。
在自己面试候选人的过程中，也发现了很多问题，我觉得这些问题都可以记录在这个面试理论专栏中。记得第一次面试候选人的时候，也没啥经验，心里也有担心。后面发现要明确自己部门用人的标准，比如我负责基础能力的面试，那对高级和资深基础技术能力的期望值，一般是 JDK 中重要的包需要了解到原理级别，用过的框架和技术同样也需要了解到原理层次。
其实这个也不是很难，在工作中需要多思考和多问自己几个为什么。比如：为什么要用这个框架和技术？不使用这个框架和技术可以吗？那么不用的话会碰到哪些问题？那么使用的话，这个框架是如何解决这些问题的？这些框架解决问题的思想是否可以应用到业务领域中呢？如果让我自己来解决这个问题会怎么来处理和解决？有更加优雅的方案吗？说实话，这也是我考察候选人的某个知识点常用的思路。
记录平时遇到的坑的专栏
这个记录遇到的坑的事情说的简单，但是能坚持下来说实话不太容易。
这个专栏的意义在于：在之后碰到相同问题的时候，可以快速找到解决方案，避免再次趟一遍这坑。其实不仅仅是为了自己，也为了团队内的同事和各位 C 友。我想这也是 CSDN 存在的最重要的意义之一。现在很流行一句话，“你怎么不去百度一下呢？”，其实百度本身没有内容，有解决方案内容的是这些技术博客网站。
工作方式总结
打通业务流程
在写代码前，需要将整个业务流程链路打通，形成一个技术文档。如果打不通，需要沟通对应的接口人。
举一个例子，我们的服务需要对接第三方服务的回调通知，此时要确认第三方服务是否可以调到我们的服务（一般来说在公网上都可以调通，但是我这边的情况比较特殊，具体不展开了），掉不通的时候需要咨询第三方服务接口人有没有备用方案。如果有，需要验证一下备用方案是否可以走通。如果走不通，需要反馈给产品和上级领导，由他们去沟通这个问题。比如可以向第三方服务提需求。
打通业务流程的意义在于，不会出现自己开发到一半，发现流程不通，此时需求发布的时间所剩不多了，导致会影响依赖于自己业务的同事。这样的话，这个锅只能自己来背。
想明白了再写
想明白了再写的意思说，拿到需求后，不要着急写代码，需要先打通业务流程，再思考实现的步骤是怎么样的，然后再根据实现的步骤来建模，最后形成技术文档进行团队内的评审。
有人会说，这步骤一走，所剩的开发时间就没有了。其实我想说，技术评审过了之后，写代码的速度是很快的，因为整个业务流程链路是通的，对象和对象间的关系也定了，说实话，只要画好类图，通过 UML 工具都可以自动生成代码。自己需要做的只是补充一些业务逻辑而已。这样做的效率反而比不做技术评审的高上不少。
做事的责任心
根据以上两点，需要制定出一个工作量的计划。每天按计划走，尽量将计划在今天完成。
如果完不成，或者中间碰到一些问题，都需要记录下来。
我们做工程的，领导只会看结果，除非是出了问题，才会关注你的过程，从过程中发现问题。此时之前的问题记录就会发挥出作用了，问题记录的文档可以非常直观地反应出在哪一步出了问题，为什么会出问题，是谁的问题。对于后续的改进，可以发挥出指导性的作用。
结语
平时工作中，还是需要多思考，多记录，多总结。
专栏的部分还需要自己抽出额外的时间来整理，其实这个过程也是自我学习和提高的过程。
