【推荐】极限编程的十二大原则——简单设计

简单设计：通过所有测试，没有重复和费解的逻辑代码，简单的设计能保证代码的简单。

每次在对用户需求的讨论时，最花时间的往往是一些特殊场景下的需求，这些功能需求往往仅占用了整个业务需求的20%，却花费了80%的时间去争论是否需求、如何实现。这就是著名的2/8原则。

开发人员往往是完美主义者，在开发的过程中精益求精，希望自己的软件一旦应用改动尽可能的少，于是程序的可扩展性成为我们经常考虑的问题。

一直不能忘怀的是当自己刚入行的时候，在客户现场维护“前辈”们的程序，竟然发现了一段代码是用来实现“复活节彩蛋”的！

关于简单设计原则，自己就不多写了，转载一篇文章献给大家，因为我觉得看得很有共鸣！

Kent Beck在《解析极限编程——拥抱变化》中为简单系统制定了4个评价标准，依次为（最重要的排在最前面）：

— 通过所有测试；

— 体现所有意图；

— 避免重复；

— 类或者方法数量最少。

说易行难。知道这些标准并不等于说我们已经遵循了这些标准。开发人员并不是喜欢故弄玄虚的空谈家，实干家的精神使得他们视复杂为猛虎，却同时明白追求简单往往意味着设计力度上的百倍付出。在设计时，我们不仅要考虑软件的功能，还要考虑软件的性能、可扩展性，模块间的耦合关系，系统的稳定、部署和更新，版本的管理，系统的安全，界面的友好程度。要想实现简单系统，可谓是蜀道之难，难于上青天！

Do the simplest thing that could possibly work! 这是XP（Extreme Programming，极限编程）人士大声疾呼的口号。还有一个响亮的口号是“You aren't going to need it”。这其中包含的核心意义就是不要为了考虑程序的可扩展性，把目前不需要的功能加入到软件中来。极限编程提倡开发人员不要“杞人忧天”，既然未来的天是否会塌陷还有待考证，不如脚踏实地关注目前需要做的事情，至少在态度上更为务实。虽然，这种做法颇有几分“目光短浅”的嫌疑，然而软件开发人员毕竟不是预言家，未来的功能扩展无法估计，与其花费精力与时间去考虑整个架构的可扩展性，倒不如集中精神对付眼前的需求。我们也许会承担未来因为扩展而承担的巨大代价，但还有一种可能是，在付出了巨大代价解决了系统可扩展性后，又因为系统的变化脱离了预期的轨道，从而导致此前的心血付诸东流。

所以，演进的设计更符合极限编程的核心准则。然而简单并非意味着简易，所谓“大道至简”，自简入繁并不难，化繁为简才真正需要大智慧。我们必须理解的一点就是，所谓的“简单系统”同时还应该保证它的有效性。举例来说，如果我们要开发一个数据库管理系统，按照当前的需求，由于数据库访问并不频繁，我们可以采用按需创建数据库连接的方式，一旦结束访问就关闭连接。但随着该系统使用人数的增多，数据库的频繁访问会使得原有的数据库连接策略成为系统的性能瓶颈，此时，我们就需要修改系统，将原有的数据库连接策略改为连接池方式，专门负责连接资源的分配与释放。

如果我们从一开始就考虑引入连接池，对于之前的简单需求而言，是否意味着过度设计呢？按需创建数据库连接的方式确实简单，但它对于客户的需求而言，是否又是最有效的解决方案？在此刻，或许被指责为过度设计的方案，在彼刻或许又被推许为最完美的方案，那么我们应该按何种标准来评判解决方案是过度设计，还是简单设计？

事实上，问题并不在于设计是否过度，而在于设计的理念。是只做目前需要的事，还是未雨绸缪，想好今后的功能扩展？这个问题的答案还需要实际的项目开发来检验，根据不同的需求，答案会因此而异。最流行的未必就是最好的，极限编程自有它的适用场景，迭代开发模式在特定的场景下也会成为最佳的软件过程方法。