【2020年中总结】

2020年上半年也算是神奇的一年，发生了大大小小的事，让我的情绪也受到起起伏伏的冲击。回望半年的时间，感觉在公司工具人的路上越走越远，对于程序的思考越来越少。

将上半年的工作笼统地划分为业务和技术：
业务部分是在toB业务上做一些公司技术的搬运，把公司原有的技术功能通过现存的接口包装一层部署在我们的集群上，给老外们使用；部分是在修改技术债，把一些以前错误的、不合理的代码逐渐修改成适应当前业务环境的代码。

toB业务上，因为对于公司技术架构上比起去年来了解更加深入，各个业务方也混熟了脸，对于功能分析、把握也更进了一步。像是往年复杂的需求，到了今年基本上先按照设计图做上几个拆分，按照用户使用的业务逻辑合理脑补一下，基本上代码逻辑就差不多了。之后，就本着现在有的功能或者业务中台，步步深入下去，把需要的功能模块和我们自身国际站的业务逻辑整合起来，组成一个新的接口，就完事了。然后本着国外用户跨国访问的速度，大致估计一下体验快感，做上一些简单缓存。不用多费什么脑子，最多寻思一下用Java代码实现的时候背后的原理，这方面倒是唯一能感受到乐趣的，比如说：我之前一直以为我看的HashMap线程不安全的代码是Java8的源码，上次用的时候，戳到代码里看的时候，居然连函数名都没有找到。。。。。。

对于技术债来说，头就比较大，果然写自己代码要比改别人代码的时候要爽很多。看别人写的代码真是越看越生气，根本觉得对方写的代码就是脑门一热，大腿一拍，根本不考虑向前向后兼容性、历史逻辑也不考虑，完全想当然地在写。当然很有可能，别人看我的代码也是如此。总之，改历史代码的时候，需要考虑的东西就有很多，从头捋一捋地话，就首先要考虑历史上业务逻辑，这一块修改掉的话，会对用户产生什么影响，是在什么情况下提出的业务场景，达到的业务效果是啥，需要保障在修改掉代码之后依然是这样的逻辑（虽然也有可能这逻辑就是错的，但是还是需要考虑产品经理的意见）；其次，还遇到过一个和现有逻辑冲突的问题，就需要考虑到到底是向新逻辑改，还是向老逻辑改的问题，这里的修改涉及到修改的功能量，并不能说新的就不好，老的就好，当然，反过来说也一样。还有一些是当时做设计的人完全没有考虑用户量大了之后地情况，所以想这个我个人觉得倒是情有可原，因为一开始做一个高大上地模块设计，可能并不是合理，而是过度设计。

在技术层方面，上半年基本算是在和Kubernetes–Istio体系打交道，勉勉强强说自己也算在DevOps混的了。总感觉这一部分干起来，彷佛自己成为了一个架构师。考虑Istio版本升级的兼容性，升级版本的时候是否会对线上用户产生不良影响，是否会对依赖的组件产生影响，如何保障切换时的可用性等等。干的大事勉强来说有两件，一件就是刚刚说的升级基础框架，第二件就是把原本部署在阿里云上的业务搬迁到AWS上。虽然对我来说，AWS并不是很顶。小事情就比较多了，比如说整理Kubernetes-VirtualService的路由优先规则，实现第三方域名的自动化接入，部署集群的高度自动化等等。但是这些虽然听起来非常的高大上，但是实际上我个人觉得对服务编排的使用理解还停留在非常表面的阶段，举个例子来说，就像是刚会用石头来砸贝壳的卷毛猩猩一样。

想不到其他说的了，做一个简单的总结。总体来说，这半年的思路是再沿着之前定下来的基调，少搞纯理论，要理论实践齐步走的方式在推进。所以这半年的时间大多数是在看别的公司怎么对业务进行优化升级，并思考这样的方式是否能够对我们公司自己的有所帮助，不过话说了回来。。。好像大多数都没有。。。。。。