您是否曾经创建了一个精心设计的、经过深思熟虑的设计系统，却发现它逐渐发展成一个不断增大和令人恐惧的代码库？我一直在 朝着相反的方向努力，继承了可怕的代码库并试图从中创建一个经过深思熟虑的系统。
以下是 Alex Sanders 对此主题的阐述，他解释了卫报团队如何在创建设计系统的同时对抗复杂性。
试图通过约定在长时间内控制复杂性的系统，最终会倾向于熵增，因为约定的一个重要特征是打破它非常容易。
你甚至不需要恶意。约定不是一条不可逾越的界限。你可能有充分的理由打破或扩展一个约定，但一旦一个约定不再被完全遵守，随后打破或扩展它的理由就会自动变得更强，因为约定已经削弱了。这种情况发生的越多，它就越弱。
复杂性和熵增可能是同一情况下的两种结果，但不必相互排斥。有趣的是，我们为了防止复杂性而做出的最佳努力可能在某种程度上具有破坏性。
我也很喜欢 Alex 解释为什么他的团队无法使用 Tachyons 式的方法来编写样式，因为他们的开发环境有点慢。对于团队来说，进行这样的切换会非常痛苦，尽管它可以解决其他一些问题。这提醒我，以这种方式衡量问题就是为什么不可能存在一种编写 CSS 的唯一方法。我们需要这种固有的灵活性，即使是以引入不一致性为代价。因此，约定更像是一个路标，而不是一条不可逾越的界限。
另外，我非常喜欢 Alex 如何将样式和属性描述为他的团队编写这些样式的原因。这与业务目标保持一致。
…数万条规则旨在描述一组可维护的响应，以解决业务和设计问题。
这很有趣，因为我不认为我们在这里花太多时间专门讨论 CSS 的业务方面以及 功能需求，即样式化用户界面需要完成的任务。
也许考虑这一点可以帮助我们在长期内编写更好的样式。这段 CSS 代码是否解决了问题？这个新类是否解决了将帮助我们客户的问题？在工作中牢记这些问题是很好的，但我知道我并没有花足够的时间思考它们。我经常将我要转换为代码的设计视为要解决的问题。
也许我们应该扩展网页样式的方式，因为也许，仅仅也许，它将帮助我们编写更易于维护的代码，这些代码是为了解决真正的业务目标而构建的。