技术杂想

关于严谨

当别人称你为工程师的时候，至少是需要严谨的风格。技术的严谨是最基础的品质，不要说如履薄冰的心态。如果不严谨和没有一个颗如履薄冰的心态，生产问题只会越来越多。

关于八股文

看八股文的目的并不是死记硬背，底层的设计原理，在你系统架构设计和代码实现层面有什么可以借鉴的地方？比如jvm为什么这样设计，为什么要双亲委派等？

从运维角度方面思考

当出现一个问题的时候从应用的角度应该做哪些调整，从运维的角度应该做哪些调整，不能一股脑的去加机器和节点，也不能不考虑加机器和节点，怎么去权衡和取舍？就像JVM调优一样，当Java程序性能达不到既定目标，且其他优化手段都已经穷尽时，通常需要调整垃圾回收器来进一步提高性能。说实话的大多数都是有垃圾代码和结构不合理产生的性能问题。

从项目管理的过程去思考做事情

项目管理管理知识中的计划、识别、定性、定量、实施、控制，这些过程在任何一件事都是通用的步骤，项目管理也是一门通用的底层技能。

关于系统

通过拆解，把一个复杂问题拆解成多个不那么复杂的问题，再把不怎么复杂的问题继续拆解成简单的问题，最后通过解决一件一件的简单问题进而来解决原本的那个复杂问题。其思维方法遵循简单的法则：“部分之和等于整体”。这种拆分的思考方法在大部分情况下都比较有效，它让人产生了幻觉。就像“盲人摸象”、“快思考”等都指出这种思考方式的局限性，所以在我们的工作中，如果仅仅秉承着“拆分”的方法，是不能解决真正复杂的问题的。想要做好一个系统就要有深度思考，全局思考，动态思考。

关于架构图

有时候架构图这个东西可信度不高，架构图和实现是两码事，大多数说的业务中台可能只是用项目级的微服务实现解决问题而已，真正能通过业务中台去赋能业务的公司毕竟很少，业务中台需要很强的抽象能力，怎么能赋能业务，能用增强回路和平衡回路梳理出来。我们要做业务赋能？要做的事情其实不重要，怎么做才重要。

关于逻辑

说话有逻辑，做事有逻辑。前后的理论能自洽很不容易，是脑袋决定自己做的事情，还是屁股决定脑袋。牢记或谬原则，寻找反例。 程序员写代码的逻辑也要再勤加苦练。

精进自省：滑坡论证，按照现在的发展下去，得到恐怖结论。关于未来谁又知道呢？我们只能把握好当下。