入职快手三年啦～
一路酸甜苦辣，一路也算收获满满
有间歇性斗志昂扬，也有有时来的失落感，也有被线上问题搞的焦头烂额，也有和合作方争论不休
有源源不断的产品迭代，也有十分有意思的技术需求，还有幸参与些大型活动比如春节活动
我的代码可以说也算是遍布在我们组各个工程的很多角落了，堆满了屎山，现在再回头看头大
业务和技术上还是能感觉到自己的进步的，下阶段要更专注于深度了，上次老板问我怎么提升深度呢？觉得比较有意思，我乱七八糟回答了一通，最后也不知道说的是啥玩意？想来，提升业务和技术的深度，无非就是业务上多思考些为什么，多看下产品数据，多关注下AB结果，多与产品定期沟通业务，技术上多关注底层、原理、源码，不再仅仅局限于使用，以前都是被动接受一个项目，后面看看是否自己能从当前系统主动思考出优化方向，给出规划意见，做方案设计时一来是多给几个方案对比方案的优缺点，再来是多关注和调研行业内的实现方案。
下一个话题是如何推动一个技术项目的落地呢？技术项目是由研发侧推动的，一般不是由产品需求的形式提出，那么推动起来势必会困难重重，第一步就是拉各方做项目宣讲，这个宣讲非常重要，一定要描述清楚背景、痛点、目标、大致方案，方案的一些细节可以在执行时再慢慢优化调整和对齐。有了这次宣讲，基本可以获得相关合作方的老大们的支持，如果分歧，还需要再多沟通几轮，对一些分歧点做trade off。
还有一个关键点，做技术项目，看看能否站在产品需求、业务安全角度出发，这样背景的技术项目往往更好推进，如果纯纯只利于服务端的成本和效能的优化，推动起来相对困难些，要站在合作方的痛点、利益出发，推动起来要顺利很多。
总结下几个关键的要素：
1. 是切实能解决痛点，做的事情是有意义的，从合作方的痛点、利益点出发
2.一场关键的项目宣讲，描述清楚背景、痛点、目标、大致方案
3.争取各合作方老大们的支持，争取产品的支持
之前我经常能听到这样一句话 “架构的本质就是降本增效”，以前还不以为然，直至最近2年，这个词越来越多被提到。其实近一年整个快手乃至国内互联网所有公司的一大目标就是降本增效，非技术手段我们就不说了，站在技术的角度，降本增效，降低资源成本、研发成本、测试成本、运营成本，一般来说就是通过一些优化手段充分压榨服务器的性能，让服务器支撑更多的流量；降低成本的另一个手段其实就是提升效率，开发工具提效、研发流程的提效、合理的业务架构优化工程拆分的提效、搭建后台的运营提效等。
还有一个比较相近且我们经常听到的词“治理”，治理一般分为下面几块：研发效能治理、业务架构治理、稳定性治理
1.研发效能治理：其实就是研发流程、开发工具
2.业务架构治理：业务架构演进优化、工程拆分、依赖治理
3.稳定性治理：故障规范、发布规范、监控报警治理
如果我们不停下来专门做这些治理，会出现什么问题呢？研发效率低下，线上问题和故障频繁，现有架构已不匹配当前业务规模，报警泛滥，监控缺失等等致命问题。
好了，本文水到这里，继续去搬砖啦，哈哈，最后祝快手越来越好，祝互联网农民工们越来越好 =-=
说点什么
您将是第一位评论人！