时间总是过得很快，一眨眼三个月就过去了。
我很感谢荔枝的导师文化，当然，最感谢的还是我的导师！虽然工作上我们有时意见不一致而争论，但工作就是这样。
我的导师是个做事认真严谨的人，生活中也不擅于交际，我同样也是一个不擅于交际的人。但他经常找我聊天，总是希望能帮助我快速融入团队，解答我的疑惑，因此我非常感激他。除此之外，在工作中，也给予了我非常多的帮助。
我是怀着激动的心情入职荔枝，加入现在的团队的，也是怀着热情做现在的工作的，这都源自于心底里的那份对所从事的事情最真诚的喜爱。
三个月时间，在这份工作中，让我认识到自己的一些优点，以及一些不足。
我无意间听到老大说过这么一句话：程序员的缺点就是太谦虚，我们应该把我们做的产品的优势说出来，而不是藏着掖着。所以，这次工作总结，我不仅总结缺点，也会总结优点，否则就过于虚伪了。
我老大经常问我一个问题：入职那么久了，你觉得你现在做这方面的工作（指中间件/基础架构）跟以前有什么不同？我每次都没认真想过，然后每次老大都给我同样的反馈，就是要适当给自己做个总结，所以才有这篇文章。
没错，我以前也算有这方面的经验，无论是应用在工作中，还是个人开源项目。并且也觉得自己做过的那些作品并不算差劲。但个人作战与团队作战还是有非常大的区别的。
个人作战，自己实现的是个人的想法，自己做出来的东西当然自己不会觉得有什么毛病，同样自己也不会排斥自己的作品，但别人就不一定会接受。即便是工作中，也是只要上级点头就干。个人开源作品都是别人觉得好用就会用，不好用就不会用，也很少会有人给你反馈。
团队作战就不一样了，做出来的中间件/基础服务如果没人用，那就不是好产品，这个团队也就没有存在的意义了。这个团队要做出成绩，就必须要往同一个目标发力，就要解决业务方（客户）的痛点。
因此，并不是自己想做什么就做出来就好了，首先需要知道有哪些需求/问题待解决，然后要把自己的设计用文档表达出来，接着要过内部设计评审，用口语再表述一次设计，确保方案可行性，是否达到解决需求痛点/问题的目的。实现之后还要推进业务方（客户）升级，如果是新的产品，需要产品本身具有说服力，同时也需要推广说动业务方使用这个产品，如果是旧的东西，需要跟业务方说清楚升级解决了什么问题。
这整个流程下来，我们的优缺点就很容易显现出来。
刚入职那会，我开始负责消息中间件客户端组件的升级工作，由于刚入职，需求是同事已经整理好的，我就直接从设计这一步开始了。
我入职后的一周，就是在设计、写文档、修改文档。这事我印象非常深刻，因为，就在那一周，在导师的指导下，设计文档我改了七八次才过了导师一关，导师指出了很多问题。
在文档写作方面，我只擅长写使用文档以及原理分析类文档，这是由于经常写公众号文章的原因，这是我的优势，但架构设计文档就写的不好，因为需要用图表述清楚脑子里的所想。这就是我的一大缺点。
除了导师之外，带我做事的大佬也指点过我，如何写好架构设计文档，他是我们公司技术委员会的大佬，能力非常强。
这次消息中间件组件的升级，我认为做得好的地方就是整体框架更具扩展性，也更解耦了。在实现延迟消息功能的设计上，考虑到了性能问题，能够结合各方案优缺点；通过实现topic路由功能，支持Kafka集群版本平滑升级；在实现支持Topic跨区域同步上，通过主topic与副本topic绑定同一消费者消费，提高了易用性；在性能方面，更是提出支持独占/共享式订阅，解决消息量很少的topic占用一堆线程资源的痛点。
而缺点就是，在api易用性的设计方面更偏向自己的主观意愿了，测试用例的覆盖率也低，导致早期的几个版本，业务方使用过程中经常出现各种小问题，让业务方对此失去了信心，总是抱怨问题多、不好用。
入职第二个月开始，我便加入到全球统一流量接入服务的开发工作中。这与组件的开发不同，这次开发的是基础服务，我更多的是关心产品的功能实现，而不用考虑使用上的易用性问题。
全球统一流量接入服务是基于百度开源的BFE二次开发的。由于BFE是用GO写的，为了看懂BFE的代码以及快速实现产出，我花一天时间学习GO语法（以前有看过书），三天时间看懂BFE项目代码，一周时间了解各种历史遗留兼容、了解一些运维知识。这体现的是我的自学能力强的优点。
目前为止，在BFE上，我接了三个大的需求设计与开发工作，一个是资源调度需求，一个是多租户的需求，还有限流、指标统计。一共写了三个设计文档，在架构设计图方面依然体现出短板。
与之前开发消息中间件客户端组件不同，这次不再是只有自测，而是有专业的测试人员负责测试工作。因此，我在设计开发完后，还需要开会，将此次的设计与改动向测试人员表述清楚，这样他们才能设计出测试用例。而这几次会议上，我都能从测试同事的表情看出，我在口语表述方面有待提高。
做基础服务需要与运维打交道，这是因为，我们需要了解一些运维方面的知识、以及一些项目部署现状，才能做出设计。而在几次会议中，我都感觉自己跟不上节奏，都是大佬会后给我补课。这体现我的缺点，运维知识储备严重不足，很多名词都没听过。
大佬说，做中间件/基础架构，我们自己就是产品经理，需要自己去发掘业务痛点、运维痛点，所以要多与业务方交流，关注业务与基础架构对接群里的信息。
未来，我将努力克服自己的缺点，多学习运维方面的知识，补充短板。
据我了解，公司技术发展战略也在向云原生方向靠拢，将各个基础服务多租户化、产品化、云原生化，因此，我也会继续学习云原生方面的知识，跟公司朝着同一个目标前进。
目前为止，我的表现都是很被动，会议上也没能提供意见，会后还需要大佬补课，这都是因为对公司技术的发展历史包袱不了解，对一些服务的部署现状也不了解导致。还是需要更多的去了解公司的技术栈。
