新来架构师，为什么不急于抛出发现的问题？

果芽科技

GUOYA TECHNOLOGY

致力于写大家都能看懂的、有深度的

技术文章

04/2024

01

其他员工心声

新来的架构师，据说原来很厉害。但是来了之后看也没什么想法。什么问题也没提，只是解决被分派的任务。新到一个地方在没有被同化之前，应该能看到很多问题，是不善于发现吗？

02

架构师心声

要提出问题，对既有问题作优化，是首先要确认自己对解决程度的把握的。存在即合理。有些问题是问题，但是问题之所以存在，有其存在的原因。

03

问题原因分析

第一是不好解决。可能需要超强的推动能力。好解决早就解决了。

比如传统程序开发，先在本机调试，然后发布测试环境，经过公司标准的几套测试流程发布上线。现在的开发，在本地环境往往会遇到一些问题：

现在很多服务都云化了，本地环境要和云环境做打通对接，会遇到很多问题；再比如接口的测试数据很复杂，本地构造困难，但是测试服务器上有之前的测试用例。于是很多开发决定开发好了之后，只要能编辑通过就直接扔到测试环境做测试。

这与传统方式相比，对研发质量带来一定的影响：比如我习惯于开发完后，通过单步调试重新推演一下流程，看单步结果，能发现一些逻辑漏洞的问题和每一步细粒度是否符合预期。但是扔到服务器上测试，测试粒度就很粗。再比如，本来采用的是TDD测试驱动开发的方式，单体测试对开发是有指导作用的。而如果扔到服务器上测试，单体测试更容易演变为政治任务，很多甚至是为了达到单测覆盖率后补的。

这样看，给开发提供一个稳定的，可本地调试的环境必要性是非常高的。但是环境问题是业界难题之一。让整个公司统一标准，需要很强的推动能力。关键问题是大家很配合地使用了新建本地环境。但是用了一段时间，发现本地环境不好用，问题百出，不稳定。于是弃用，重新扔到服务器上执行。不仅解决完本地环境的问题后重新推这个环境不好推。这个项目让自身影响力降低，以后再推其他的也不好推。

第二是投入产出比。有些问题是问题，但是投入太大。

比如观察到公司没有回归环境。回归环境就是应用在真实上线前把所有既有的案例都跑一遍，保证本次修改没有对之前逻辑产生影响。

先来分析搭建这个环境的投入：

• 整套系统的服务器资源

• 系统的每个服务，因为涉及参数配置，观察服务运行是否正常，需要负责对应业务的开发人员具体搭建

• 测试用例采集，数据不论是从生产环境采集清洗还是造数据，都涉及专门的团队的巨大工作

• 我们之前要求过百万案例，这么多案例运行，整套链路的性能是否达标，能否在短时间内跑完结果

• 后续环境的维护，测试案例的维护。为此，不仅是搭建一个环境，还要配备整套的平台来做维护。

这种投入对绝大多数公司来说都是巨大的，但是多数公司对稳定性的要求还足以去搭建这样一个平台。

04

问题解决

所以更明智的做法是先不要急于反馈看到的问题。而是要先观察。

可以先应用自己之前非常成熟的经验，预计能短时间出效果的。比如之前一个负责人初来乍到，就新建了几套工具：

新建工具相对是很简单的事情，几个团队想和负责人建立友好和信任，就把任务承接了。没有历史包袱新建服务多容易。大家也很容易看到效果。

还可以先深入到具体的业务，帮助大家解决具体的问题，先一边建立信任，一边更深入地了解整个公司的系统和很多问题之所以存在的原因和来龙去脉。再提出一个整体的规划，然后任务拆解。