两种技术乱象：为什么前者更容易让程序员背锅？

在实际的技术开发中，开发者将已存在的有效工具应用到当前面临的业务问题之中，并在业务上进行快速迭代，远比无休止地陷入技术术语的漩涡更为重要，而这一点被普遍低估了。

本文作者曾在两种类型的公司工作过，第一种是只追求可衡量的业务成果，忽视技术债务，并在没人愿意使用他们的代码库时，对工程师提出苛刻的指责；另一方面是过度追求技术的花哨和复杂，让他们的高级工程师整天配置代码检查工具并编写很少有人读的RFC，进而忽视了核心的业务逻辑。这两种极端都不利于企业的长远发展，尤其是后者，危害可能更大，但技术管理层很容易抨击前者，对后者却保持无知的幸福感。

或许这是因为没有足够的激励来解决这个问题，而以履历为导向的开发确实能获得更好的回报。只要公司继续让人们解决与工作无关的晦涩难解的问题，或者招聘经理继续使用自动化系统来搜索简历中的关键词，一群聪明的人将始终追求技术的极致，为下一个重大机会做准备，而将基础产品置于失败的境地。

当公司规模逐渐扩大、业务逐渐成熟时，第二种情况变得越来越常见。中层管理人员对底层工作的理解有限，导致资源浪费在微观优化和复杂工具的引入上，而忽视了核心的业务需求。他们过度依赖代码检查工具和技术方案，却忽视了开发人员应专注于产生最大价值的核心业务逻辑的重要性。

更糟糕的是，一些公司引入了无用的度量标准来衡量开发者的生产力，比如代码行数、Pull Request 数量或功能票数。这种行为导致开发人员只关注表面的指标，而忽视了核心业务逻辑。他们陷入了无休止的讨论最佳实践、微观优化和多余细节的循环，而忘记了核心业务逻辑的重要性。如果开发人员对核心业务逻辑的工作得不到回报，他们为什么还会专注于改进它呢？

当下，微服务已不再流行，许多公司在没有 Netflix 那样的收入或人力资源的情况下，依然采用 Netflix 的工作方式，这也造就了网络上有大量的文章来说明当使用 PostgreSQL 支持的 Django 单体应用可能已经足够时，采用面向服务架构的坏处。还有一些文章批评GraphQL，认为一个简单的去规范化的二级索引已经足够，或者 JavaScript 前端框架的高流失率浪费了时间、精力和金钱。然而，很少有文章提到组织结构和政策如何迫使人们采取这种方式。

我们需要找到技术与业务的平衡点。这并不是一件容易的事情，需要技术负责人、经理和业务所有者的共同努力。只有通过专注于核心业务逻辑，并避免技术债务的积累，我们才能够实现最大的业务价值。

然而，目前还没有一个完美的解决方案。我个人也没有在这样的公司工作过，因此无法给出确切答案。但我希望借此机会，邀请那些具有技术负责人、经理或业务所有者身份的人，与我们分享他们或他们的组织计划如何解决这个问题。只有通过共享经验和智慧，我们才能够找到更好的平衡点，实现技术和业务的和谐发展。

在当今科技驱动的世界中，我们需要意识到技术只是达到目标的手段，而不是目标本身。通过关注核心业务逻辑，我们可以避免陷入技术的极端主义，拥抱实际的业务需求，实现持续的创新和成功。

希望这篇报道能够引起广大程序员群体的关注，激发有关技术与业务平衡的讨论与思考。让我们共同努力，摆脱技术陷阱，迈向业务的成功之路！

原文链接：https://rednafi.com/misc/oh_my_poor_business_logic/

注：未经授权，禁止转载！

推荐阅读：

▶ “五分钟内为公司节省了 50 万美元，要求涨薪 3 万美元却无果，我有些后悔了！”

▶深夜炸场！OpenAI 首次开发者日：新模型发布，支持 128K 上下文，价格直降，GPT 商店要来了

▶深圳一公司奖励程序员38g黄金空格键，价值近2万元，网友：“每次敲击一下都是钱声！”