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

复杂性

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

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

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

技术负债

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

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

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

转载请注明:http://www.aideyishus.com/lkyy/1035.html