作者 | Oto Brglez

译者 | 弯月

出品 | CSDN（ID：CSDNnews）

在软件开发中，总会遇到一些不同的难题。在本文中，我将介绍一些关键的主题，由于这些领域的“投资”很难短时间内在ROA/KPI/OKR仪表板上看出成效，远远比不上那些“客户非常喜欢”的闪亮新功能，因此常常被忽视、遗忘或排除在外。

复杂性

第一个摇摇欲坠的“支柱”就是复杂性。在做技术规划时，我们常常会忽略复杂性引发的各种问题。虽然只是添加了一个小小的库，然而其背后引入的依赖性却无法预知。很多人会因为患得患失而不断添加各种微服务，然而这会引发一系列的后续工作：部署、版本控制、发展，乃至逐步淘汰。不仅如此，这也会加剧组织的复杂性：随着产品、团队和公司的发展，组织成员、文档、利益相关者等的数量也会增加，导致组织的灵活性降低。

在考虑复杂性时，你还应该想到另一个可怕的问题：每个工程师每天都在构建功能，但这些构建工作都是正确的吗？就目前来看，这些构建工作都是正确的？那么，再过两年、三年、五年乃至十年，还正确吗？该问题的回答越复杂，你就越应该感到害怕。我们应该通过良好的需求定义、明确的目标和持续的“简化”来对抗复杂性。

在谈论和思考复杂性时，应该采用记录时间的方式：记录下为了支持某些功能而浪费的小时数，记录下为了让 X 进入生产环境而不得不在 Y 上浪费的小时数。还有为了寻找与 Z 相关的信息而花费的时间。总的来说，我们不仅要知道需要什么，还要知道为什么需要。

技术负债

这就引出了我们的第二个“支柱”，技术负债不仅会破坏士气，影响计划和截止日期，而且在极少数情况下还会导致整个组织瓦解。每个项目，每个组织都有技术负债，就是因为他们不愿意谈论这个话题，而且即便谈论也是因为延误项目而受到指责或以此为借口。

当然，你可以打一个补丁，然后再打另一个补丁，不断累加。你可以调整界面，以便进度条在屏幕上多停留几秒钟；也可以将负载均衡器的超时时间延长至几分钟，让服务“消化”有效负载；甚至可以用另一个服务打包整个服务。

这些不恰当的解决方案确实可以争取一些时间，而且很多产品，尤其是年轻的产品，都采取了这样的措施。然而，你必须做到心中有数，这些都是技术负债，最终仍然不得不偿还。不偿还这些债务，就会威胁到团队和组织。技术负债是一种风险，尤其是当你身处管理职位时，必须时刻关注技术负债。

你需要记录并公开讨论技术负债，向其他工程师解释为什么某些实现采取了蹩脚的做法。此外，还需要与管理层沟通，向他们澄清技术负债引发的各种问题：收入损失、系统停机、开发周期延长、错误和 bug 频发等等。

资源

这个“支柱”比较显而易见，且不同的组织有不同的称呼：资产、人员、基础设施、构建产品所必需的元素等等。我们经常讨论将来的计划，比如我们需要招聘 50 名工程师、20 名数据科学家，我们需要扩大云预算、购买新的 SaaS 服务等。

然而，我们应该多花些时间思考如何留住现有的人员、利用现有的服务，并以更有效的方式利用我们的资源。

从风险的角度来看，培养团队内现有的专家比招募新成员的风险更小，尤其是在当前。尝试新技术意味着，你的技术栈中将出现一条你不知道如何驯服的“猛龙”。

我建议多花些时间认为思考如何利用当前的资源，以及如何提升他们的价值和性能。

实验

我很喜欢这个“支柱”。实验有一种特殊的力量。然而，很多组织都会忘记实验，或者更直白的说，他们会严格限制实验和创新，他们希望“一切照旧”，甚至还有人说“被迫如此”。

我希望鼓励每个人勇于尝试以前从未接触过的框架和技术，同时也希望每个人都能积极地想办法解决符合组织愿景和挑战的难题。

作为一名工程师，你应该积极地向管理层提出有关公司如何创新和提高竞争力的问题。作为管理层，你应该多投入一些时间和资源开展相关的活动，思考如何将一些不成熟的想法变成出色的解决方案。

总结

当然，对于各个组织、项目或产品来说，关键性的支柱肯定不止这四个。常见的还有优先级、预算、销售等等，但是我认为这些支柱能够让组织保持良好的发展，而且还能帮助组织保持领先地位。

参考链接：

https://www.linkedin.com/pulse/four-dusty-pillars-software-engineering-oto-brglez/