vandort
2021-02-10 23:45:09 +08:00
同意 11 楼的说法。你可以先问自己三个问题：
1 、团队技术积累够不够？
2 、公司基础设施建设有没有到位？
3 、出了问题谁负责定位、排障、解决？
除非你打算半年内跑路，不然研发团队的可持续发展跟个人的技术成长同样重要。团队技术积累不够，基础设施建设不足，都是很要命的事情。比如你做服务拆分，拆成了很多个微服务，但是没有 ELK （或者其他类似东西），没有配置管理，没有链路跟踪，测试也是手动黑盒点点点，有了问题你要怎么去定位呢？开一屏的终端 tail -f 吗？如果客户要求配置额外的安全策略，要逐个配置文件的去改吗？
考虑另外一个情况，如果为了去贴“集群”的概念，不小心用了 k8s （或者其他类似东西），碰见大坑了要怎么办？外面招不来懂云计算的人，内部的团队又爬不出去。以你们团队领导的风格，是会 997 爆肝刷苦劳、扣发奖金解散团队，还是会重金聘请顾问解决问题，然后公正地复盘问题，亡羊补牢呢？
另外，其他的研发同事的能力足以上手这些新的技术吗？输出的文档可以帮助阅读的人理解系统吗（真的有文档吗）？测试团队能不能理清服务拆分之后的整体架构？交付团队能不能消化新架构带来的学习成本呢？
如果领导不参与具体的研发工作，我建议不妨先用自己的能力范围之内的技术完成需求（然后包装一下对外汇报），再一点一点的在自己的舒适区边缘向外试探。进可向先进的、有前景的技术方向演进，退可迅速回滚到你能掌控的版本，降低风险不可控的概率。这样你可以跟公司一起成长，即使想另谋高就，也会更加从容一些。