代码库与社区

有一天早上醒来，我意识到自己一直都错了。我发现代码和设计无法解决设计系统团队的所有问题，即使很多问题可以通过整天在黑暗的房间里编码和设计来解决。等等，什么？这怎么可能说得通？好吧，这是因为好的设计系统工作也关乎招聘。

让我解释一下。

首先，让我们看一下一些常见的设计系统问题。一个问题可能是你的组件是一个厚厚的 div 汤，这会给用户带来问题，而且对可访问性很不利。另一个问题可能是你有很多自定义组件，它们很脆弱，而且使用起来非常困难。或者也许你有八种不同的插图风格和四种不同的模态组件。也许你有一千种不同的颜色值，它们的使用不一致。

组织中的每个人通常都能感受到这些问题，但它们非常难以描述。人们可以看到，构建事物需要比预期的时间长得多，而且沟通不畅非常普遍。我们的 Web 应用程序可能存在糟糕的 Web 性能、重大可访问性问题和设计严重不一致。但为什么会这样？所有这些问题的根本原因是什么？

设计系统奇怪的一点是，很难看到所有这些不一致和问题背后的根本原因。即使你看到了问题，答案也不总是显而易见的。

设计系统团队可以编写组件文档来解决这些问题，或者进行重构，审计模式，进行更多重构，重新设计组件，并提供培训和指导。但是当应用程序达到一定规模时，一个人（甚至是一个完整的团队）解决这些问题是不够的。

当然，设计系统团队可以花费大量时间帮助解决问题，但这真的是他们时间最好的利用方式吗？如果他们说服公司中的另一个团队聘请一名专门的前端工程师来构建可持续的工作环境呢？如果他们聘请一名插画师来确保整个应用程序的一致性和高质量呢？

这就是为什么设计系统工作也关乎招聘。

设计系统团队处于最佳位置，可以围绕招聘提供指导，因为他们将是第一个发现组织中问题的团队。他们将看到组件是如何被拼凑在一起的，或者存在多少不必要的自定义组件，这些组件不属于库或样式指南。设计系统团队将看到代码库中其他团队看不到的弱点，并且他们可以展示哪些团队缺少哪些特定技能集——并通过聘用具有这些特定领域技能的人员来解决这个问题。

如果你在管理层，并且每天没有看到所有这些不一致，那么很可能不会有任何行动。我们不太可能解决我们看不到的问题。

因此，作为设计系统人员，我们最终需要关注招聘，因为代码库是一个社区。

修复代码库的唯一方法是修复社区。