这一年来（2019 总结）

雨翔河

首页列表关于

这一年来（2019 总结）

2020-02-10 09:39

>  本来是早就想写2019年的总结，前段时间忘记了，这几天肺炎疫情严重，在家办公，正好抽空写个给自己的总结，也没有做什么格式编辑，想到哪里写到哪里，就当作随笔写的年终总结吧。

2019年对于自己来说是变革的一年，年初做需求，年中的时候领导离职，赶鸭子上架接任了这个烫手山芋，起初我自己是不看好自己能做好这个小领导，几番推辞还是无奈受命，这不是矫情，其实当初自己也有点走的想法，年龄和阅历都不足以承担这个重任，特别是这还是整个公司的核心业务，但是自己的性格好像就是那种越刺激的事情越想搞定的人，随着慢慢熟悉，好像做的也还可以，哈。

从实习进入o公司到x公司，再到f公司。一切好像都是这么巧合，在o，老大说接任负责人，那年才毕业一年多，我感觉觉得自己好像不是很行，转去了n公司，在n公司刚第一次接触大数据，半年时间转为数据收集处理的技术负责人，带了个五六人的团队，一不小心成为了公司内某技术领域的专家（滑稽），在那里的确学习到了很多，技术的长进不是最重要的，是学习的能力，解决问题的能力和方法，但是好像在n公司做到最后发现数据处理得到的结果都给人做了嫁衣，一个大公司业务很赚钱是好事，但是遇见了中层勾结组建私下公司贩卖数据，我觉得这与我良心过不去，君子固然爱财，但是取之有道，为公司做完最后的数据采集之后毅然离职，离职那天我还记得是我入职整整一年零一个月那天。

之后就入职在f公司，做物流方面的开发，正好又是在公司核心部门，也是第一次接触一个组负责那么多项目，真正算起来没缩减前维护的上线应用个数高达30+，其他项目组都是个位数。

19年是在f公司的第二年，平稳的度过了双十一高峰，零故障，这恐怕是目前在f公司最值得骄傲的事情，也不枉我们研发人员日日夜夜的熬着就为了挺过这个高峰，还依稀记得18年双十一redis集群故障导致的雪崩惊动了老板。

2019这一年经历了很多，前半年是技术方面的进步，后半年是管理方面的摸索。

这一年依然保持了自己大学以来的好习惯，每个月必须写一篇技术博客，其中这一年终于敢于把实际生产环境遇到的问题和解决方案写出来（以前在n公司是不允许的，因为涉及到金融灰色地带的数据敏感性）。

这一年几乎所有的技术博客都是写在oschina，这要感谢老东家提供的优秀平台，致敬。

2019年开始解决了很多公司的技术问题，所有项目的spring组件升级和logback切换升级，之所以提这个并不显眼的事情，是因为来f公司之前我是没有在工作中接触过spring的，说来也尴尬，spring和mybatis我都是来了f公司才正式接触的，有的研发人员可能觉得奇怪，java的web开发没有用过spring？其实我觉得不管用什么，基本上都是那些原理，不一定是局限于spring，离开了spring难道javaweb的大厦就不存在了？我觉得对于研发人员来说，不管用什么，百川归海，学习钻研能力和沟通能力很重要，再绚丽的技术归根结底还是那些基础演变，大道至简。

对于公司管理层面和技术层面的很多东西感觉有好的也有不好的，任何一个公司都不是十全十美的，下面就想自我吐槽下遇到的优缺点

一个技术人员问问题是一个很有水平的问题（不局限于技术人员），见过了太多的研发人员上来一句话，‘服务启动不了，为啥’，其实不管你是实习生还是应届毕业生或者资深开发，这类问题不应该出自技术人员口中，不妨我们来分析下这句话，首先，假设我们是一个非常热心肠的大神来应对这个问题，服务是哪个服务，启动不了是什么报错，生产环境还是测试环境，时间点是什么，服务所在的地址是哪里，有没有自我分析过问题，详细结果是啥，这样别人才能帮你解决问题。之所以提出这个事情，是因为这类问题层出不穷，包括我写这篇博客这会儿，有技术人员询问我这类问题，这并不是发牢骚，我自认为自己是一个非常热心肠的技术人员，但是，这是提问题的艺术。包括工作中有人问‘在吗，在不在’这类问题，其实大多数情况下，在与不在不重要，重要的是把问题抛出来解决就好了。

软件的工程的问题也是很多的，比如协同开发，因为发版时间不规律导致分支过多，而使用git流的方式进行开发测试上线的话就会导致一个问题，需要多套测试环境，当后端服务都是以rpc这种方式提供的微服务的时候，会需要很多测试机器，大大的增加成本。

技术人员和产品经理的合作问题也一直是业界的一个梗，其实这是个交流问题和换位思考的问题，千奇八怪的梗就不说了，拿我司目前的这类问题来说吧，产品经理对产品本身的逻辑不清楚（因为铁打的营盘流水的兵，产品人员很多是转岗过来的，且更换太过于频繁），产品经理的需求和下一次需求没有任何联系，且产品经理仅对需求上线那天的uat测试和上线负责。这在我看来是一个错误的做法，产品经理，技术负责人，测试人员，应该全程跟着项目走，或者中期加入跟着项目走，优化方案提出问题解决问题，这样才能做出好的产品，而不是只求结果，这样得到的结果不一定会是当初要的结果，因为事物的演变并不是会完全按照需求文档来的，如果只求结果，我觉得这适合当老板。我还是那句话，对于研发人员和产品经理都适用，没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件拥有者已经死了，死在去改需求的路上。

协同开发还有一些有趣确却真的发生着的事情，比如一个项目评估单人10天可以完成，因为紧急情况，需要缩短工时到5天，于是乎增加了一个人一起开发，其实看过《人月神话》的都知道，打个比方，孕妇十月怀胎，那么两个人一起怀孕的话，是否可以五个月内把孩子生出来，答案大家都知道是不可能的，但是在大环境下，我可以告诉你，可以生出来，不要问我为什么，哈。

谈论了研发人员和产品经理，接着讨论测试人员，测试环节是必不可少的，有的公司的产品没有测试人员，凭开发人员自测上线，这对于用户量不大的产品来说是没有问题的，可以充分的利用人力减少成本做最多的事，但是对于用户量大的产品来说，f公司有一个核心算法（滑稽，没有嘲笑的意思），需求的研发工时／3=测试工时，我不知道这个算法对还是不对，但是对于有些需求来说，改几行代码的研发时间可能是十分钟的事情，但是引发的问题之大和需要测试的环节时间可能需要一天，不知道这个观点有没有人反驳。
其次，测试人员本身应该对产品逻辑熟悉，对产品质量负责，我是由衷的希望bug和产品不好的地方都能是测试人员发现提出，当然这是一个美好的愿景。现在有很多产品逻辑需要研发告知到测试，需要测试哪里，功能的逻辑是什么样的，测试方法是什么，这其实有点可怕，因为这意味着你随时可以被替换，因为随时换一个人来做这个事情也是可以的，这也导致了产品质量和用户体验会很不好。

接下来是运维人员，每次项目需求发布生产环节，研发人员和运维人员打交道的次数是最多的（偶尔的生产故障也会打交道。。。），我们的项目目前还是没有做到自动化发布，需要研发人员介入，这一点颇为遗憾，不过目前正在努力向这个方向前进。问题一，每次发版需要研发人员盯着日志，如果发现有大量错误，需要手动通知到运维需要回滚，这种问题不仅仅是运维人员的问题，也是研发人员自己要思考的，是不是应该做到，生产环境无error日志，如果有就认为是问题。其次是应用监控问题，因为监控的不到位，很多潜在的问题就像连环地雷一样埋在地下，（我2019年的很多生产环境问题解决的日志都是靠临时的日志捕捉到的），为此我自己私自写了一个公司的告警机器人来周知到研发人员，但是这远远不够，因为还有太多可以做的事，比如最基本的每一台虚拟机或者k8s，cpu，内存，磁盘，网络，这些最基本的监控必须到位，我们引入的pinpoint和sentinel等中间件只是做到了应用层面的监控，但是很多次故障都是机器导致的，这里有太多的事情可以做。。。

最后再谈谈自己吧，用两个字来形容自己的工作就是，‘辛劳’，这一年很多时候都在担心双十一，因为往年的双十一都是会出故障的，通宵达旦的去修复问题，今年多次的技术优化终于避免了这个问题，我自己细想了下，组内也好，别组的负责人也好，好像年龄最小的是我，工作经历最小的也是我，负责的又是公司最核心的业务，说没有压力是假的，出问题了要第一时间去解决，跟打战似的，都说好的将军是跟我冲，而不是给我冲，要让兄弟们做的开心，不妥的需求要敢于纠正和反驳，工时的评估要兼顾到很多非研发问题，自己在外吃点亏可以，不能让组里的同事吃亏，好像蛮怀念高中的时光，打架也好，溜冰场惹事也好，抽烟被抓也总有bobo和j在前面扛着。2020年说实话我有点迷茫，现在互联网的大环境也很迷茫且低迷，看起来百花齐放，其实很多技术吹和泡沫，我其实想在技术这条路走的更久更长远些，一直以来都在避免自己过早的走入负责人的角色，解决技术问题带来的快感是无法言表的，这是一种瘾也是一种执着。

类型：随笔标签：2019,总结