避免过分设计

文章首发于公众号:松花皮蛋的黑板报

做者就任于京东,在稳定性保障、敏捷开发、高级JAVA、微服务架构有深刻的理解

许多文章都在强调不要过分设计本身的系统，可是没有道出个因此然来，因此本文列出一些经典的过分设计，但愿能给你带来启发，在工程上作一些平衡，避免过分设计把咱们推到另一个复杂度上

一、Engineering is more clever than Business

工程师一般认为本身是最聪明的，这第一个错误容易让本身过于工程化。咱们计划了100件事，业务方会提出咱们以前没有考虑到的第101件。若是咱们解决了100个问题，那么接下来还可能会有1000个问题。咱们觉得一切都是掌握之中，然而实际彻底不知道将来会发生什么

在研发生涯中，从未碰到过业务在需求上是收敛，它们老是发散的，这是业务的原本面目，不是产品经理的错

二、Reusable Business Functionality

当业务方提出了愈来愈多的需求时，咱们第一反应是尽可能分组和泛化业务，这是大部分MVC架构最后成为由大量模型或者控制器堆积的缘由，正如前面所说的，业务永远不会是收敛的，它们老是发散的

在系统中，共享逻辑和抽象应该是趋于稳定的，然而随着功能迭代愈来愈多，它们要么会保持平稳，要么会变得脆弱。当相反的状况发生时，就会成为太大而失败的系统

好比说，有个业务是实现用户属性管理，咱们持着任何东西都是类似的这种观点，首先完成通用的CRUD逻辑，可是这个需求实际上要求知足13个不一样的注册流程，也就是说通用的逻辑代码没有任何意义。同理，一个订单视图和订单编辑视图流程是彻底不同的，可恰恰有些人会合并视图

咱们在横向分割业务前，应该先尝试纵向分割，同时也要考虑从一种方式切换到另一种方式的可操做性和便捷性，不然重写系统将是灾难性的工做，也就是说分离行为比强行合并好

3、Everything is Generic

须要链接数据库，那就写个通用的泛化适配器
须要查询数据库，那就写个泛化查询
须要对参数进行校验，那就写个通用的参数校验器
须要对结果进行包装，那就写个通用的数据映射器
等等

当在实现需求时，浪费大量的时间尝试总结出完美的抽象层，甚至本来业务问题的答案很是显而易见。即便奇迹般地总结出了一个完美的抽象时，它每每会很快变得不适用，目前最好的代码设计侧重点应该是编码易于被删除的，而不是盲目追求易于扩展

实际上，重复代码比错误的抽象更好，只有当你看到系统里有逻辑重复的代码，才能更好地进行抽象，同时重复代码暴露了许多用例，有助于使得边界上下文清晰

四、Shallow Wrappers

咱们习惯使用外部库时都封装一层，这种封装是浅层的，不幸的是，咱们容易在提供功能和编写好的包装器之间模棱两可，混淆着大量的业务逻辑，使得它既不是一个好的包装器，也不是一个好的业务解决方案。实际上要封装一个优质的库，须要投入大量的时间编写，同时保证高代码质量和完善的代码测试，具有清晰、可测试的、可测量的API。须要注意的是，封装应该是例外，不该该是常态，不要为了封装而封装

五、Applying Quality like a Tool

高质量的代码一般知足SOLID原则，使用相应的设计模式和代码技术，好比factory、builder、strategy、generics、enums。若是你不加思索地运用质量概念，好比说将全部的变量修饰修改成private final，这并不能将编码质量提升，或者改变过去链式继承的方式，每一个类都有接口和实现，而后注入到下一层，看似知足SOLID概念。实际上SOLID的设计初衷是为了反对滥用继承与其余OOP概念，然而大部分工程师没有搞清楚这些概念从哪里来，如何出现，只是照单全收，没有从思惟上消化，只是工具化地盲目应用

学习一门其余语言，尝试以另外的思惟模式去作事情，这样会成为一个更好的开发者。新瓶装旧酒对咱们没有任何帮助，咱们没必要为了应用一个新概念而弄乱一个清晰的设计

六、Overzealous Adopter Syndrome

发现了泛型技术，将一个简单的 “HelloWorldPrinter” 修改为了“HelloWorldPrinter”，那怕事实上只会有特定的数据类型，或者有足够的普通类型签名

发现了策略模式，如今每一个条件语句都是一个策略

处处使用枚举/扩展方法/Traits等各类炫酷的技术

上面都体现出了过分适配问题

七、<X>–ity

例子一、实现一个CMS系统，要求具有可扩展性，业务人员可轻松添加字段
结果：业务人员历来不使用这个功能，当他们须要时，会要求工程师在旁边协助，也许咱们所须要的只是一个简单的开发人员指南，能够在几个小时内添加一个新字段，而不是点击式界面

例子2：设计一个可轻松配置的一应俱全的数据库层，咱们能够经过文件配置轻松切换数据源
结果: 过了很长时间由于某种缘由须要切换数据源，可是修改配置文件没法知足咱们的要求，如今业务有了不少的功能差距，致使不兼容

实际上，建议将数据库视为解决方案的一部分，抛弃可配置性，不然很难保证兼容性。当设计时，多问本身使用场景是什么，而后深挖下去，你可能会发现大部分特性都是没有必要的，包括可配置性、安全性、可扩展性、可维护性、可继承性。总之，不要在没有被要求时加上各类特性，应该明确地定义与评估场景、用户故事、需求、用途

文章翻译修改自:

medium.com/@rdsubhas/1…

文章来源：www.liangsonghua.me

做者介绍：京东资深工程师-梁松华，在稳定性保障、敏捷开发、JAVA高级、微服务架构方面有深刻的理解