架构师日常-技术or业务

Posted 2022-03-09 Q博士

背景

最近在思考一个问题，就是在业务团队是以业务为主，还是以技术为主？什么情况下要做技术优化呢？

其实这个问题应该对很多人来说不难回答，占比较高的应该是以业务为主，技术就点到为止就行了，但是有的时候也需要技术介入解决问题，那什么时候需要技术介入呢。有一些技术范的人，会说技术为主，但是如果做技术优化影响了业务，该如何抉择呢？

今天就跟大家来探讨下这个问题。

业务发展初期

一个业务起步的时候，大多数都很紧急，快速搭建一个可用的系统才是主要目标，所以这个时候不会有太多技术思考，比如什么架构设计，模块设计都不会太认真。这个阶段一是人少，不需要太考虑维护成本，开发效率的问题，主要就是疯狂堆砌代码。二是不确认业务能不能活下来，搞太多技术也没啥收益。这一点在我们公司尤为突出，因为成立之初，在疯狂探索各种不同的业务，所以做了很多业务，大多数业务也没存活下来，这种情况搞技术也没啥意思，因为代码都没用了，技术建设是不会有意义的。

当业务起来后，订单量持续增长的时候，是不是就要开始技术建设了？我认为还到不了技术建设的时候，因为一个业务被证明可行后，还要经历一段业务高速迭代期，这段时间还是要以业务为主，原因还是有2个方面：这个阶段一是人不够，因为需求可能两三天就能想出来，但是人可不是两三天就能招来的，所以有很长的时间，原来的几个人要负责的东西更多，所以只会更忙。第二个原因就是还没到系统瓶颈出现的阶段，业务是不会认可听下业务去做技术的，因为做技术的事情，一定占用人力，这也不惯业务这么想，主要人家会认为你要做技术是“狼来了”的心态，人家见到狼才会真正认可狼是有害的，才会让你去打狼。

等业务高速发展一段时间后，订单量上来了，然后原先的一些设计慢慢的扛不住日日增长的量，主要有两方面体现

• 开发效率越来越低，加一个功能，要改一堆地方：这种往往分工不明确，分层结构，模块功能定义也不清晰，反正是出抽象的问题。不知道啥问题，但是就是觉得开发一个功能比以前花的时间长了。
• 系统天天出问题，线上问题频发：这种是客观问题，就是天天有问题，业务骂，研发哭，领导天天愁着个脸

这种情况下，就是起技术的时候。

业务发展中期

刚才说了，业务发展个几年后，问题出现了，这个时候你说要起技术了，人家也是认可的，因为看到“狼”了。

这个阶段对于想做技术的人，要赶紧抓住，因为往往要人有人，要时间有时间，我就是在这个阶段来到现在团队的，我来了后，成立了架构组，招了一堆高工，然后把之前遗留的问题，各个击破，升级了开发框架，搞了压测，报警监控再加上慢查，推出了各种规范，代码规范，mysql规范，上线规范，稳定性规范一堆，模块合并拆分一堆弄。反正经过1年的时间，消灭了一些核心问题，稳定性提升了点，提测质量好了，线上问题少了。

但是肯定不会1年就能解决所有问题，不过经过一年，倒是建立一种技术氛围。有两点主要目的

• 提升研发在业务的开发过程中，兼顾技术优化
• 提升研发的技术规划能力，了解现在的问题，合理安排时间落地

但是业务也有低落期，在经历告诉发展后，业务发展遇到点阻碍，这个时候人员会进行优化，团队会缩容，这个时候技术的事情也要相应的停停，减少成本支出，只留必要人员支持核心业务。我现在就处于这个阶段，不过还好去年搞了一波技术，现在歇歇也是可以的，我也把精力投入到业务，转变成业务架构师，多去支持业务的事情。

总结

本来的我，是以技术为主的人，但是今年业务的一些变化，也改变了我的一些思维。没有业务何来技术，技术相对于业务其实是个附属品，业务发展好了，技术才能更好的被建设，如果技术建设的很好，业务没了，一些都只是1后面的0，没有1，0再多也没用。