关于后端:分享后端开发最佳实践

本次的课题让我很头疼，后端开发最佳实现 — 我感觉我并没有资格来领导他人要怎么实际才是最佳，但如同也只能硬着头皮上了。

什么是最佳实际？

我已经参加一个零碎，有个物品治理性能，产品提出需要：物品名查问不仅仅要反对中文查问，还要要反对拼音查问。过后有个共事想要引入 ElasticSearch，用ElasticSearch 的拼音分词器 来实现。这看起来的确是一个很好的实现形式，谷歌上按关键字查问，排在后面的基本上也都是这种形式，那它是不是最佳实际呢？
过后的背景是：这个物品表只有几十条数据，因为业务的局限，将来在可预感的范畴内也不会过千。
基于这一点，ElasticSearch计划其实就是“杀鸡用牛刀”，还进步了保护老本。起初采纳的计划是减少一个 拼音字母 字段，保留时由工具类生成值，尽管看起来比拟 挫，然而胜在简略疾速。

回到什么是最佳实际这个问题：在联合过后的环境下，适宜本人的就是最佳的。
比我接手过一个比拟老的零碎，为了晋升性能，在批量查数据时对 MySQL 有些当初看起来比拟奇怪的用法，而那些奇怪（繁琐）的用法，对于当初的咱们来说，只是引入 redis 就能够解决的，然而那种实现计划，在没有（或者还未风行）分布式缓存的过后，可能就是最佳计划了。
零碎始终在更新，技术始终改变动，咱们的团队 / 集体技术水平也始终在变动，有时候你认为的最佳的计划，随着工夫的推移、团队 / 集体的的成长、零碎的扩充等，最初发现还有更佳的计划。所以我本节课要讲到的一些最佳实际，当前也可能被我本人全副颠覆掉。

零碎指标

同任何事物一样，软件也是有 生命周期 的，咱们开发的零碎，要么追随业务一起 死亡 ，要么因为无奈保护（保护老本过高）而被 废除 。当设计一个零碎时，咱们的指标就是 用最小的人力老本来满足构建和保护零碎的需要 ，终极目标就是做到 不能比业务先死亡 。
要构建一个好的软件系统，应该从写整洁的代码开始，代码于零碎，就像砖头于房子，砖头品质不好，那房子品质必定也不会好。软件行业通过了几十年的倒退，前辈们依据踩的坑总结了一些教训，当初咱们能够站在他们的肩膀上，遵循他们总结的一些最佳实际。

所以本次分享，我也只是总结了一些前辈们的设计准则。

SOLID 准则

SOLID是由罗伯特·C·马丁提出，面向对象编程的五个根本准则，能够帮忙咱们开发一个容易保护和扩大的零碎。

SRP：繁多职责准则

A module should have one, and only one, reason to change.
一个软件模块都应该有且仅有一个被批改的起因。

这个准则常常被说成是 一个办法只能做一件事 ，但这并不是SRP 的全副，SRP应该是 一个模块应该只为某一类行为负责 ，它蕴含了 一个微服务只负责一类服务 、 一个类只负责一类职责 和一个办法只做一件事 。这样做的益处是，咱们对一个业务做批改时，确保不会影响到另外一个业务。
比方

public interfacer DemoService {void saveUser(User user);
    void saveOrder(Order order);
}

以上 DemoService 很显著就违反了 SRP：当多人为了不同业务（目标）批改同一份源码时，首先代码合并就很容易产生问题。如果咱们将DemoService 拆分成 UserService 和OrderService，那我在批改 User 相干逻辑时，我能够确保 Order 业务不会被我影响到。
以上的例子，我事实中很少发现，但如果我把 一个类只负责一类职责 反过来讲成 同一类职责只由同一个类来负责，那以下的例子我就常常见到了。

public class Demo1ServiceImpl implements Demo1Service {
    private UserDao userDao;
    public void demo1() {
        ……
        userDao.save(user);
    }
}
public class Demo2ServiceImpl implements Demo2Service {
    private UserDao userDao;
    public void demo2() {
        ……
        userDao.save(user);
    }
}
public class Demo3Controller {
    private UserDao userDao;
    public DemoResp demo3() {
        ……
        userDao.save(user);
        ……
        return resp;
    }
}

以上例子，该当把 User 的save办法对立收拢到 UserService 里，其余 Service 不应该间接调用 UserDao（特地是Controller 层更不应该跨层间接调用 Dao）。如果后续咱们心愿User 在保留时，能判断某些字段如果没有值就设成默认值（比方 createTime 设成 以后工夫），不收拢的话就要在多个中央批改了。

OCP：开闭准则

A software artifact should be open for extension but closed for modification.
对扩大凋谢，对批改敞开。

咱们还是以代码为例：

class Rectangle extends Shape {
    private int width;
    private int height;
    public Rectangle(int width, int height) {
        this.width = width;
        this.height = height;
    }
}
class Circle extends Shape {
    private int radius;
    public Circle(int radius) {this.radius = radius;}
}
class CostManager {public double calculate(Shape shape) {
        double costPerUnit = 1.5;
        double area;
        if (shape instanceof Rectangle) {area = shape.getWidth() * shape.getHeight();} else {area = shape.getRadius() * shape.getRadius() * pi();
        }
        return costPerUnit * area;
    }
}

如果这时候减少一个 正方形 ，那么咱们就须要批改calculate 办法的代码。这就毁坏了开闭准则。
依据 OCP 准则，咱们不能批改原有代码，然而咱们能够进行扩大。咱们能够把计算面积的办法放到 Shape 类中，再由每个继承它的子类本人去实现本人的计算方法。这样就不必批改原有的代码了。

public abstract class Shape {public abstract double calculateArea();
}
class CostManager {public double calculate(Shape shape) {
        double costPerUnit = 1.5;
        return costPerUnit  * shape.calculateArea();}
}

咱们在浏览 Spring 源码时，会发现 BeanPostProcessor 无处不在，Spring的很多个性都是基于 BeanPostProcessor 扩大的。

LSP：里氏替换准则

Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it.
子类能够代替父类

依据 里氏替换准则 ，咱们能够在承受抽象类（接口）的任何中央用它的子类（实现类）来代替它们。
子类能够代替父类 这个规定看起来很简略，但事实中还是经常出现问题。
长方形 / 正方形问题：

class Rectangle {
    private int width;
    private int height;
    public void setWidth() { ……}
    public void setHeight() { ……}
}
class Square extends Rectangle {……}
class User  {public void operate() {Rectangle rectangle = new Square();
        rectangle.setWidth(5);
        rectangle.setHeight(2);
        ……
    }
}

以上例子，Square是不能代替 Rectangle，因为Rectangle 容许别离批改高和宽，而 Square 高和宽必须是一样的，而对于 User 来说，它是不晓得 Square 的规定的，因为它操作的是 Rectangle。
还有经典的 企鹅是鸟的子类 问题，Bird类有个 fly 办法，因为 企鹅 不会 飞，只能在 fly 办法里抛出异样。然而对于应用方来说，他们并不知道会有不会飞的鸟，就会呈现零碎问题。（当然能够在 fly 接口定义上做正文或者显示 throw 异样，然而这就减少了应用方的应用老本，并且也让人困惑。）
在零碎的设计和编程实现中，咱们应该认真地思考零碎中各个类之间的继承关系是否适合。

ISP：接口隔离准则

A client should not be forced to implement an interface that it doesn’t use.
不能强制客户端实现它不应用的接口。

以商家接入挪动领取 API 的场景举例，微信反对 免费 和退费 ；支付宝接口只反对 免费。

interface PayChannel {void charge();
    void refund();}
class WeChatChannel implements PayChannel {public void charge() {……}    
    public void refund() {……}
}
class AlipayChannel implements PayChannel {public void charge() {……}    
    public void refund() {// 没有任何代码}
}

第二种领取渠道，基本没有退款的性能，然而因为实现了 PayChannel，又不得不将 refund()实现成了空办法。那么，在理论运行中，使用者明明是能够调用这个办法，但调用了却什么都没有做!
能够改成以下形式：

interface PayableChannel {void charge();
}
interface RefundableChannel {void refund();
}
class WeChatChannel implements PayableChannel, RefundableChannel {public void charge() {……}    
    public void refund() {……}
}
class AlipayChannel implements PayableChannel {public void charge() {……}    
}

依据不同场合，提供调用者须要的办法，屏蔽不须要的办法。
比如说电子商务的零碎，有 订单 这个 畛域对象，有三个中央会应用到：

1. 门户，只能有查询方法。
2. 内部零碎，有增加订单的办法。
3. 治理后盾，增加、删除、批改、查问都要用到。

interface OrderForPortal {String getOrder();
}
interface OrderForOtherSys {String insertOrder();
    String getOrder();}
interface OrderForAdmin {String deleteOrder();
    String updateOrder();
    String insertOrder();
    String getOrder();}

任何档次的软件设计，如果依赖了它不须要的货色，就会带来意料之外的麻烦。
我以前在写我的项目公共包时，建了个 common 模块，所以封装的公共类都放进去，比方 Redis 工具类、Kafka工具类等。到最初我发现我的管理系统（manager）明明没有用到 Redis、Kafka，但因为引入了common 包，导致也被动地引入了 Redis、Kafka 的依赖包。这样我的项目公布时打进去的 jar 包里，就会变得很大，同时如果因为平安等问题要降级第三方包时，manager明明没有用到，却因为引入了相干的 jar 包而只能跟着从新公布。起初我学 apache 的commons做法，将 common 拆分成 common-base、common-kafka、common-redis 等。

如果降级到 java11，也能够用模块化来解决。

DIP：依赖倒置准则

High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.
高层模块不应该依赖于低层的模块，它们都应该依赖于形象。形象不应该依赖于细节，细节应该依赖于形象。

DIP准则通知咱们：如果想要设计一个灵便的零碎，依赖关系就应该多援用形象类型，而非具体实现。

public class MySQLConnection {public void connect() {System.out.println("MYSQL Connection");
    }
}
public class PasswordReminder {
    private MySQLConnection mySQLConnection;
    public PasswordReminder(MySQLConnection mySQLConnection) {this.mySQLConnection = mySQLConnection;}
}

下面的例子里，高层模块 PasswordReminder 依赖于低层模块 MySQLConnection 的，这不合乎依赖倒置准则。如果想要把 MySQLConnection 改成 MongoConnection，那就要在PasswordReminder 中更改硬编码的构造函数注入。应改成以下形式：

public interface Connection {void connect();
}
public class MySQLConnection implements Connection {public void connect() {System.out.println("MYSQL Connection");
    }
}
public class PasswordReminder {
    private Connection connection;
    public PasswordReminder(Connection connection) {this.connection = connection;}
}

KISS 准则

Keep It Simple, Stupid.
零碎的设计应放弃简洁和简略，而不掺入非必要的复杂性。

计划和架构的准则，就是尽量简略，越简略出问题的概率越低，也越好保护，然而也不能为了简略而摈弃了扩展性等，这要依据理论状况找到平衡点。
我发现很多人，包含我，要搭建一套零碎的时候，总是习惯性地按微服务思维拆分出几个模块，但实际上很多零碎曾经没必要再拆了。每多拆出一个服务，申请就会多转发一次请次，服务节点多保护一个。零碎 / 流程越简单，出问题的概率越大。

当你做的是管理系统简略的用户治理性能时，就别想着搞什么简单的设计了。

我以前参加前公司推送服务零碎开发，咱们按微服务思维将零碎依据业务拆分成 APP 推送、 短信推送 、 邮件推送 等服务。
每个业务上面又会按职能拆分成多个模块，以 APP 推送 为例，咱们按 对接公司外部业务 （被动推送）、 对接互联网 APP 用户 （被动拉取）、 管理系统 （manager） 定时工作 （job）拆分模块，这几个模块必定都会有雷同的逻辑，比方 获取音讯内容 、 推送黑 / 白名单 等，所以就抽出一个 common-service 公共服务模块，我过后拆的更细，把调用最频繁的 音讯相干的操作 再独立拆出一个 message-service 服务。

这个零碎也没什么问题，线上始终运行的好好的。只是一个推送会通过多个服务，出问题排查的老本就比拟高。而且服务越多，部署老本越高。
起初我始终在反思我是不是适度设计了，开始尝试回到最后的单体利用模式，把公共服务作为 jar 包的形式被引入。

改为这种模式之后，不论是开发（不必写服务接口对接）、问题排查还是运维施行，都晋升了效率。
单体利用的劣势：

1. 开发简略。
2. 测试简略。
3. 快：只有过程内的提早。
4. 部署简略。

当初当我在拆分零碎的时候，我都会想下“你真的须要微服务吗？”。当业务比拟小、或者曾经拆的足够细的状况下，不肯定非要用 微服务模式。甚至能够说，在中小企业，大多数应用程序采纳单体架构就足够了

本准则举的例子，两个计划哪个好，其实是 仁者见仁智者见智，只是从我集体的实际后果上，我更喜爱前面那种计划。

YAGNI 准则

You aren’t gonna need it.
不要适度的设计。
程序开发的后期阶段为了程序更好的扩展性，有时候会做一些超过目前需要的设计，然而臆想中的需要事实上往往是不存在的。
我以前做一个广告投放零碎，零碎有：广告打算 、 广告策略组 。他们之间的关系是：一个 广告打算 下抉择配置一个对应的 广告策略组 ，一个 广告策略组 能够被多个 广告打算 配置，也就是 广告打算 与广告策略组 的关系是多对一（n:1）。我问咱们的产品，一个 广告打算 当前是不是能够抉择多个 广告策略组 ，产品的答复是“短期内没有这布局，当前不敢保障”。我过后思考到这个可能，代码上设计成 广告打算 与广告策略组 的关系是 多对多 （n:m 蕴含了 n:1）。因为简单的投放逻辑，理论开发中 多对多 的复杂度比 多对一 高了好几倍，后续需要迭代时我都会想：如果过后做成一对多我应该很快就能实现了。再起初我终于受不了了，花了两个礼拜工夫把零碎重构了一遍。直到我把我的项目交接给他人，多对一 的关系始终都没变。
然而这个事件始终困扰着我：我这种做法到底是不是正确的，如果前面产品真的提出 多对多 呢。只是从后果上看，我前面改回 多对一 的做法是正确的，这也是 YAGNI 准则 的一个核心思想：大部分的超前设计，最初都不会被用到，反而会蛊惑其余的开发者。

TDD：测试驱动开发

测试也是零碎的一部分，无论怎么强调测试的重要性都不为过。
龟兔赛跑的故事通知咱们：稳才是最重要的。

TDD 的基本思路就是通过测试来推动整个开发的进行。原理是在开发性能代码之前，先编写单元测试用例代码，测试代码确定须要编写什么产品代码。

• 先写测试，并执行，失去失败的后果。测试后行并不是说不须要思考，间接开始写代码，而在开始写代码之前要进行需要剖析，测试代码其实是产品代码的“用户”，在写测试代码时你就要思考如何“应用”产品代码

// step1
@Controller
public class DemoController {public boolean greaterEqualThan0(int value) {return false;}
}
@Test
public void greaterEqualThan0() {Assert.assertTrue(demoController.greaterEqualThan0(0));
}

• 疾速实现代码，让测试通过。以最快的速度让测试变绿，意味着咱们通常用最间接但可能并不优雅的形式，比方复制代码。

// step2
@Controller
public class DemoController {public boolean greaterEqualThan0(int value) {return true;}
}

• 增加新的测试用例，并反复“开发 - 测试”直到所有的场景都测试通过。

// step3
@Test
public void greaterEqualThan0Negative() {Assert.assertFalse(demoController.greaterEqualThan0(-1));
}
@Controller
public class DemoController {public boolean greaterEqualThan0(int value) {if(value >= 0) {return true;}
        return false;
    }
}

• 重构代码，去掉 坏代码，并保障测试通过。

// step4
@Controller
public class DemoController {public boolean greaterEqualThan0(int value) {return value >= 0;}
}

• 反复上述以推动性能实现。每个周期的批改局部应该尽可能小，软件开发是复杂性十分高的工作，小步后退是升高复杂性的好方法。

TDD 的长处：在任意一个开发节点都能够拿出一个能够应用，含大量 bug 并具肯定性能和可能公布的产品。
TDD 的毛病：减少代码量。测试代码是零碎代码的两倍或更多，然而同时节俭了调试程序及挑错工夫。

不同代码的测试应该互相独立，比方 Controller 类里的办法尽管依赖了 Service，然而它测试代码不应该去测试用到的 Service 办法，能够通过 Mock 来解脱依赖。
能够借助 IDEA 查看以后测试覆盖率。

对品质负责

认真对待本人的代码 / 架构。

• 理解本人所应用的框架的原理：只有理解本人所应用的框架 / 工具，能力更好的应用它。

  • 我见过一个零碎，因为开发者对 redis 性能的低估，导致原本一个 redis 就能搞定的事件，他用了 4 个redis来分担压力。
  • 最好的学习形式是分享，分享过程中，可能会面对各种发问，这种压力迫使你必须分明各个细节，当你能给他人讲清楚的知识点时，才是真正的把握了。
• 器重监控：我刚进上家公司接手的 APP 推送服务，因为一些非凡起因，这个我的项目之前在海内有个云服务器节点，云服务器上部署了 Tomcat、 数据库 并独立运行服务。这台云服务没有任何监控，咱们过后把“对这海内服务节点的革新”排进了打算，然而因为这个节点曾经跑了很久都没有出问题，所以优先级设的并不高。忽然有一天，局部用户的 APP 不停的收到弹窗音讯，排查发现是因为磁盘空间满了，导致 mysql 无奈批改数据状态（要改成已推送状态）（磁盘空间满导致 mysql 无奈写入 binlog），推送工作扫描未推送的音讯始终反复推送。过后影响到了 10W 用户，最初公司给了这些用户一些弥补。

• 心态很重要：开发排期压力、无休止的做反复工作、不停歇加班、需要频繁批改等，都会影响咱们的心态，必须要留神的是负面心态很可能影响咱们的开发品质。

  • 我在厌倦的时候，会本人写一些与具体业务无关的代码，比方通用工具类，来调整本人的心态。
  • 提交代码时，我会从新过一遍本人批改的中央，批改不洁净的代码。提交代码就示意曾经实现了某一阶段的开发，这时候心态是不一样的，会比拟有急躁地走查、优化代码。

不要让交接代码的人吐槽你的代码。

参考：

【译】浅谈 SOLID 准则
SOLID Principles-simple and easy explanation
面向对象的 SOLID 准则文言篇
单体到微服务是一个演化过程，别在一开始就适度设计
测试驱动开发
测试驱动开发的概述
测试驱动开发是否已死