先确保解决方案简单可用，再考虑通用性和复用性

作者：凯佛林·享尼（KevlinHenney）

许多用来实现基础设施的代码，包括组件框架、类库、基础服务（fundation services），普遍存在一个问题，它们的设计一味强调通用性而不考虑具体应用，导致出现许多令人困惑的可选项和不确定因素，这些功能常常不是被闲置，就是被误用，甚至毫无价值。多数开发者开发的是专用系统，无限制的通用性对他们的帮助不大。寻求通用性最好的办法是研究现有的具体案例，抓住问题的实质，从根本上得出通用解决方案。通过经验提炼的简单方案，远胜过不切实现的通用性。

如果存在多个可实施方案难以取舍，“先简单后通用”原则可以成为最终的评判标准。挑选基于具体需求的解决方案，放弃鼓吹通用性的复杂方案。而且简单的方案在实践中完全有可能表现出更好的通用性。退一步来说，修改简单方案满足需求，也比修改通用方案容易，因为通用方案常常在关键的地方使不上劲儿。

虽然许多的能用设计的初衷是好的，但还是难逃失败的命运。设计组件的首要任务是抓住具体需求，满足需求，通用性来自对需求的理解，理解之后才能简化。提炼通用性可以使我们更加接近问题的本质，通过分析己有案例可以获得清晰、简洁、有依据的规律和方法。然而提炼通用性往往流于形式，南辕北辙，不但无法减少复杂性，反而增加复杂性。追求理论上的通用性通常会导致解决方案脱离实际的开发目标。由于这种通用性基于错误的假设，所以无法提供有价值的方案，只会带来棘手的问题，增加开发人员和架构师将来必须面对的偶发复杂性（accidental complexity）。

虽然很多架构师重视通用性，但这样做是有前提条件的。并非所有人都需要通用性，愿意为它掏钱，具体情境要具体分析，有针对性的解决方案才有价值。我们提供具体解决方案时，无须排斥通用性和灵活性，但是如果过早脱离具体情况，只会迷失在无限的可能性里，被复杂的配置选项、超负荷的参数列表、冗长啰嗦的接口，以及存在缺陷的抽象所淹没。追求随心所欲的灵活性，会使人们在无意中错失（有些人甚至故意忽略）更简单的设计和更有价值的特性。