技术KPI

继续自我修养。
日常生活中会出现这种现象，我们大部分时间都在谈论业务，每个人都在聊做什么，技术大会也在聊业务，周会上也在强调各种业务指标，demo的时候也在阐述业务的走向...我们是不是离技术有点远了，不怎么关心技术的发展方向和趋势？

屏幕快照 2020-01-30 16.04.11.png

那么技术不重要吗？回答是肯定的。就好比一座房子，业务只是要求一个经得起风吹雨打的房子，技术就是架子，以及实实在在的钢筋混凝土。好的技术抗地震，抗台风不在话下，不好的一吹就倒。因此我们在编写user story的同时，也需要排技术story，关注一些NFR（非功能性需求）。
那么技术KPI怎么设定？可以关注这些方面：业务贡献（需求把控，业务项目和业务创新），技术贡献（设计重构，技术影响力，code reviewer，创新提效，代码质量），团队贡献（招聘，新人培养和团队氛围）。
TL（Tech Leader），不仅仅需要掌握技术，在团队需要的时候能够顶上，同时也需要一定的管理能力。要主动承担各种开发规范以及交付责任。文中提到的异常处理规范中的熔断机制，提到了Netflix 开源的 hystrix 容灾框架。简单了解了下原理，是通过封装原先直接调用api，在里面加入http请求的超时时间，一旦超过这个时间，系统就会判定该api服务不可用，进而取消该通路。当然我们一般也会有队列处理消息机制，一旦服务不可用，就会堵塞整个queue。那么熔断就是检测整个queue容量，一旦发现容量满了，一方面告警，另一方面将该queue的数据导入其他可提供服务的hander里去。
代码评审需要关注的几个地方：1. 确认代码功能。2. 编码规范。3. 潜在的bug。4. 文档和注释。5. 重复代码。6. 复杂度。7. 监控与报警。8. 测试覆盖率。
技术 TL 要有良好的技术视野，不需要各种技术都样样精通，但是必须要所有涉 猎，有所了解，对各种技术领域的发展趋势，主流非主流技术的应用场景要非常了 解。知道在什么场景应用什么技术，业务发展到什么规模应该预先做哪些技术储备。 产品架构的设计要有足够的弹性，既能够保证当前开发的高效率，又能够对未来产品 架构的演进留出扩展的余地。

什么才是有价值one on one的沟通？

1. 你有没有认为自己的价值和能力被低估了吗?为什么?
2. 你觉得在工作中能学到东西吗?你最近学到了什么?你还希望在哪些领域进行
   学习?
3. 近期这段时间，对自己有哪些满意、不满意的地方?
4. 目前工作中，有哪些困惑?希望我如何去帮助你?
5. 对团队和我的一些期待和建议。
6. 在公司战略和目标方面，你最不清楚的是什么 ?

文中还提到一点让我深受启发就是：无论大小难易，永远不满足于做出来指定的事情，一定要给人惊喜。我想这是一种目标，也是对自己成果的一种激励吧。