Outline
- 2022 年产生了什么
- 大环境行业感悟和思考
- 集体工作内容变动思考
- 工作打算
- 将来瞻望
2022：github star 2.5k、年薪 70w
2023：价值闭环
2022 年是疫情 3 年的一个“小尾巴”，但它一点也不小，因为它是 3 年内大家感触最深的一年，也是影响最大的一年。身边共事们换工作、四周见闻都能够印证这个论断。
宏远的局部就不谈了，经济大环境和政策对互联网的影响、以及人们对经济预期的变动，都在扭转着咱们。之前大行其道的消费主义也变了，人们回归感性，从居民储蓄率这一点就能够看得出。
除了失常的每个月的月供，我会每隔半年会提前换一波房贷，22 年可能还了 35 万。不过当初不打算遇到还房贷了，想着多留一些现金在身边有安全感（身边有人还房贷，说银行那边排队到 23 年了）
对于从事互联网行业的咱们，影响最大、感触最深的就是互联网的投资逻辑变了，所谓的用户量曾经不再具备吸引力了，现金流和盈利才是吸引行业资金、人才歪斜的逻辑，互联网的高速增长的步调刹住车了。国家在政策上和资本也是偏向偏实体制造业小户的，比方新能源汽车。因为能带动的产业上下游很多，包含软件开发和制造业等。很多意识的从互联网进去的人去参加到新能源造车畛域发光发热。有个阿里的产品敌人聊完发现，新能源车畛域互联网信息化和流程较弱，过来带着互联网那一套有“降维打击”的成果。
要是让我概括下，互联网这边有什么好的特质和思维，我尝试概括下：不舍边界、Owner 意识、数据意识、价值追踪、问题拆解思维。
Owner 意识谈得是做事件的态度和思维，为了正确的把某个我的项目做完，不去因为职能和岗位问题只做“份内”的事件。只做份内的事件不对吗？挺多的，不过这是大多数人的思维，强人会推动我的项目进去，被动协调各个角色做好事件。所以这样的人必定是更难得的。
数据意识谈得是，做一个我的项目或者优化，须要有数据撑持。面临的问题是什么？当初的现状是什么？比方当初一个人须要花 3 个工作日才能够实现某个流程。当新的零碎开发后，一个人花 0.5 个工作日就能够实现某个流程。那这是假如，我的项目上线后如何追踪？埋哪些点，去量化掂量价值。我的项目上线几个月后散会去复盘梳理，要不要迭代，本次上线的我的项目符不合乎当初的构想。所以须要数据思维去量化定义和跟踪问题。价值追踪也在下面的例子谈到了，具体不做开展。
问题拆解思维谈得是某个我的项目须要哪些资源，某些资源不具备，我须要内部哪些部门提供资源，如何让内部部门更被动去帮忙你。那如果有一个独特指标，让他人也有一个好的后果，相互成就，这样的事件更具备主动性，而不是他人买集体情或者迫于更高层的压力，那么优先级可能就会给你排低，不是一个最优的计划。
还有局部优良的大佬，不认可字节的文化，去 Zoom 这样的外企工作了，尽管钱略微少了一些，然而问到他，他会讲有更多的集体工夫了，工作也不须要那么卷了。之前的有赞的 TL 去浙大实验室带我的项目了，问过一次为什么做这样的决策，答复“稳固，能够有更多的工夫陪伴家人，尽管薪资方面可能会比互联网打折扣一些”。一个没加入过高考，输送浙大的人，参加过支付宝、微策略、有赞挪动 TL 的人做这样的决策，必定有本人的了解（衡量之后的一个后果吧）。
我也从有赞到职了，在有赞的工作内容能够分为 2 局部：后期是写业务、起初去中台写基建。在中台次要负责跨端（Weex 打包平台、性能监控、异样监控、Flutter 组件库、热修复）APM、业务异样监控等。在有赞写过业务，也做过基建开发。写过 iOS、Weex、Flutter、Electron PC 收银，写过挪动端 mPass（前端 React + UmiJS，后端采纳 SpringBoot）写过业务异样监控。能够说是全栈了。做的有余的中央，我记得挪动总监坐我边上的时候，常常和我探讨 APM 的原理和技术细节，为了挪动端性能，为了统计口径的一致性，制订了公司层面的北极星指标，然而在北极星指标的时候，调研了行业内不同公司，发现每个公司的定义也不太统一，后续咱们也定义了本人指标（为了更好的服务于业务，也为了更好的裸露和量化性能问题），制订好指标和去业务线宣讲，也经验了一些挑战，最初一直打磨，因为 APM 不只是一个技术命题，同时也是一个业务抓手，同时又是一个产品（不过产品的使用者是公司内部人员，比方开发者、TL、产品负责人等）所以须要全面思考并落地，那段时间是我最工作最头痛、同时也是最高兴的一段时间，被挑战的越多，倒逼我去思考更粗疏、更全面，成长也越大。过后也发现腾讯 Matrix 的一些 APM 问题。发现尽管是大厂的我的项目，然而也要对品质和用扫视的眼光去对待。
年度环评和时候，挪动总监对我说了一句话“你在技术方面挺优不错的，然而须要进步的一点是价值闭环，比方你在做 Weex APM 的时候，尽管我的项目上线了，然而还没推广到各个业务线，就去做挪动端的 APM 了，心愿你把最初一公里走完”某个我的项目哼哧哼哧做了那么久，就差一步就拿到一个更高的后果了，而后没做，马上去做其余事件了。对于这一点我也很认可，心愿接下去几年一直正视这个问题。
每个公司策略呈现调整的时候，对于技术中台会影响更大一些。所以这次后我抉择从事业务开发，业务开发上的架构设计、性能优化也同样有意思。业务背景下做优化做出价值更快，如果是做基建，价值和意义体现可能会较为被动，须要从侧面（业务宿主 App 的一些数据来体现价值）。另外业务更能摸清公司的主营业务，更具备不可替代性。
到了业务后我将业务代码的单元测试覆盖率从 30% 进步到 93% 以上。业务代码拆分为 Core 外围逻辑层和 UI 层，单测次要针对 Core 开展。所以从基建转到业务开发后，将会聚焦于业务架构，设计出面向未来可拓展的业务代码。另外从业务侧去做一些性能监控和优化，比方最近在做的 CI 我的项目，将一些品质问题收口到 pipeline 阶段，去监控品质，不合要求的代码，没法合并到主工程。针对业务代码提交 MR 后，gitlab hook 去触发脚本，review 进去的一些评论和互动都会通过 robot 主动发 lark 音讯，不须要线下发音讯通知对应的人去 review。另外能够依照肯定的策略去 lint，保障提交代码的品质。
当然 APM 性能监控和性能正向优化也很重要，先发现问题，而后隔靴搔痒。
将来，心愿在业务上一直学习，对于一些伪需要敢于说不，业务尽量用数据谈话，价值追踪。也能够帮忙 PM 提出有成果意见，不只是一个执行者的角色。致力成为一个业务领域专家、业务架构师和技术专家。
生存方面尽量做减法，没必要的社交不去参加。区别于宅和社恐，是有社交能力，然而回绝一些低质量的社交。聚焦于一些有意义的事件下面，比方健身、静止、多看看书、写写技术文章、学学英语。
本文参加了 SegmentFault 思否年度征文「一名技术人的 2022」，欢送正在浏览的你也退出。