高效的工作方式都有一個(gè)共性：把大任務(wù)拆分為多個(gè)小任務(wù)肩刃，再一一破解祟霍；較小的任務(wù)可以減少我們的心智負(fù)擔(dān)，也幫助我們更高效的分配盈包、解決問題沸呐。
用在軟件工程上，就是通過分治手段呢燥，將軟件模塊化崭添，實(shí)現(xiàn)高內(nèi)聚低耦合。
OK叛氨，本文以 IoC（控制反轉(zhuǎn)） 入手呼渣，介紹我總結(jié)的一套高效開發(fā)方式棘伴。
Bad Practice
我們先不解釋什么是 IoC，以一個(gè)簡(jiǎn)單的 Controller 調(diào) Service 的例子屁置，看一個(gè)高耦合的 Bad Practice：
-
UserService.ts
export class UserService { getUsers(): Promise<User[]> { ... } } -
UserController.ts
import { UserService } from "./UserService"; export class UserController { private userService: UserService; constructor() { this.userService = new UserService(); } getUsers(): Promise<User[]> { return this.userService.getUsers(); } }
我以前就是這么寫 JS 代碼的——Controller 的依賴（Service）在構(gòu)造函數(shù)里實(shí)例化焊夸。這個(gè)就是經(jīng)典的源代碼依賴：
源代碼依賴：當(dāng)前模塊（module，class 等等）需要依賴多個(gè)其他模塊才能編譯
對(duì)于底層小職員來說蓝角，考慮編譯速度還是太過遙遠(yuǎn)了阱穗；現(xiàn)實(shí)生活中，我們通常遇到的難題是：KPI 考核里有一項(xiàng)叫測(cè)試覆蓋率的東西使鹅。
上面的代碼就很難寫單元測(cè)試揪阶，因?yàn)?Service 很可能還需要再依賴 ORM 框架，甚至需要連接 DB 才能運(yùn)行患朱；這樣的測(cè)試不僅僅是麻煩的問題鲁僚，調(diào)試速度還特別感人；測(cè)試一多裁厅，還有 DB 連接池等一系列問題蕴茴。
Better Practice
如何讓測(cè)試變得簡(jiǎn)單呢？DI——Dependency Injection姐直！
依賴注入（DI）: 組件之間的依賴關(guān)系由容器在運(yùn)行期決定；通俗來說蒋畜，即由容器動(dòng)態(tài)地將某個(gè)依賴關(guān)系注入到組件之中
實(shí)操如何声畏？我們稍微改寫一下 Controller 代碼就可以了：
import { UserService } from "./UserService"; // Still Bad!
export class UserController {
private userService: UserService;
constructor(userService: UserService) {
this.userService = userService;
}
getGetUsers(): Promise<User[]> {
return this.userService.getUsers();
}
}
變化很小，就是不讓 userService 在 UserController 內(nèi)部實(shí)例化姻成；而是交由外部容器通過構(gòu)參的形式注入 userService：
// UserController.test.ts
describe("Unit test of UserController", () => {
let userController: UserController;
beforeEach(() => {
const userService = new UserService();
userController = new UserController(userService);
});
}
不過插龄，上述代碼這樣還是沒能解決源代碼依賴的問題——UserController 依舊在import { UserService }。 So科展？
Best Practice
我們還得用到依賴倒置（Dependency Inversion）
依賴倒置原則: 高級(jí)模塊不應(yīng)該依賴低級(jí)模塊均牢，而是依賴抽象
什么意思呢？我們先不解釋才睹，看一下代碼改造：
-
UserService.ts
export interface IUserService { getUsers(): Promise<User[]> } export class UserService implements IUserService { getUsers(): Promise<User[]> { ... } } -
UserController.ts
import { IUserService } from "./UserService"; export class UserController { private userService: IUserService; constructor(userService: IUserService) { this.userService = userService; } getGetUsers(): Promise<User[]> { return this.userService.getUsers(); } }
改造后代碼的最大區(qū)別就是：UserController 不再 import UserService徘跪， 只import了它的抽象IUserService。
我們看一下 UML 類圖琅攘，UserController 直接從源代碼層面解耦了 UserService 以及 UserService 的所有相關(guān)依賴垮庐；而 IUserService 只是一個(gè)接口類型，不值幾個(gè)字節(jié)坞琴。
Mock Test
通過依賴倒置解耦后哨查，我們的單元測(cè)試也變得更簡(jiǎn)單了——因?yàn)槲覀兛梢詫?Mock 測(cè)試了：
export class MockUserService implements IUserService {
getUsers(): Promise<User[]> {
return Promise.resolve([]);
}
}
由于 MockUserService 繼承了 IUserService，我們可以利用多態(tài)直接將 Mock 實(shí)例注入到 Controller 里剧辐。這樣寒亥，測(cè)試也和 UserService 以及后續(xù)一系列 DB 操作解耦了邮府。
// UserController.test.ts
import { MockUserService } from "./UserService";
import { UserController } from "./UserController";
describe("Mock test with UserController", () => {
let userController: UserController;
beforeEach(() => {
userController = new UserController(new MockUserService());
});
it("Return an empty array of users", async () => {
const users: User[] = await userController.getGetUsers();
expect(users).toStrictEqual([]);
});
});
What is IoC
控制反轉(zhuǎn)（IoC）是面向?qū)ο缶幊讨械囊环N設(shè)計(jì)原則：對(duì)象在被創(chuàng)建的時(shí)候，由一個(gè)調(diào)控系統(tǒng)內(nèi)所有對(duì)象的外界實(shí)體溉奕，將其所依賴的對(duì)象的引用注入給它
IoC 只是一種設(shè)計(jì)原則褂傀，而上面提到的 DI（注入依賴） 則是實(shí)現(xiàn) IoC 的一種實(shí)現(xiàn)技術(shù)。最經(jīng)典的 DI 框架就是 Spring腐宋，它利用一份 XML 定義注入關(guān)系紊服。后來的框架又逐步轉(zhuǎn)向 @annotation 這種形式實(shí)現(xiàn) DI；Typescript 里比較出名的框架有 NestJs 和 Midway胸竞。不過這類框架封裝太深欺嗤，已看不到真實(shí)的 DI 過程。我后來看到一個(gè)叫awilix的 JS 庫卫枝，它也實(shí)現(xiàn)了一套簡(jiǎn)單的 DI 容器煎饼；我們可以從它的實(shí)例里看一下真實(shí)框架下的 DI 執(zhí)行過程：
import * as awilix from "awilix";
import { UserController } from "./UserController";
import { UserService } from "./UserService";
// 1. Create a container
let container: awilix.AwilixContainer = awilix.createContainer({
injectionMode: awilix.InjectionMode.CLASSIC, // matches constructor parameters by name.
});
// 2. register dependency to the container
container.register({
userController: awilix.asClass(UserController),
userService: awilix.asClass(UserService),
});
// 3. Resolve the dependencies
const userController: UserController = container.resolve<UserController>(
"userController"
);
console.log(await userController.getGetUsers());
在這個(gè) JS app 里，DI 容器的執(zhí)行過程就三步：
- 創(chuàng)建一個(gè)全局的容器
- 將所有使用到的依賴注冊(cè)到該容器中
- 解析依賴校赤，并自動(dòng)完成注入
實(shí)例代碼我放在了 github 上了吆玖；大家也可以在自己的代碼上用 awilix 重構(gòu)一下。實(shí)現(xiàn)其實(shí)很簡(jiǎn)答啦马篮，就是寫一份全局的 DI 容器注冊(cè)文件將所有依賴關(guān)聯(lián)起來沾乘；最后，在 api handler 里——以 express 為例——用到某 controller 時(shí)浑测，直接 container.resolve('controllerName') 出來就行了翅阵。
小結(jié)
前幾天看了鮑勃·馬丁叔叔的程序員誓言，其中有兩段挺有意思的：
- 我將在每個(gè)發(fā)行版本中生成一個(gè)快速迁央、可靠和可復(fù)用的證明掷匠，證明代碼中的每個(gè)元素都能正常運(yùn)行
- 我會(huì)進(jìn)行小版本的快速迭代，以免阻礙他人的進(jìn)度
早些年我對(duì)小版本快速迭代的開發(fā)方式不以為意岖圈；非得一次性完成新功能+順手重構(gòu)+無測(cè)試的代碼后讹语，才肯提交 MR；一個(gè) MR 少則十幾個(gè)蜂科，多則幾十個(gè)文件的 changes顽决，代碼混亂不堪。原因很簡(jiǎn)單：周邊人都是這么干的导匣。
雖然工作很簡(jiǎn)單擎值，也不會(huì)累著吧。但是年紀(jì)大了逐抑，雜事也多了鸠儿，往往顧此失彼。現(xiàn)在我調(diào)整了開發(fā)方式：
- 畫設(shè)計(jì)圖，把 feature 拆分成多個(gè)子模塊
- 定義相關(guān)抽象进每，提 MR
- 寫一個(gè)文件的模塊（如 class）+ 單元測(cè)試汹粤，也不集成到系統(tǒng)中，直接提 MR
- 所有子模塊實(shí)現(xiàn)后田晚，注冊(cè)到 IoC 容器里嘱兼，集成測(cè)試，提 MR贤徒，完工芹壕！
每次提交都在四五個(gè)文件以內(nèi)，也不會(huì)影響他人進(jìn)度接奈；絕大多數(shù)時(shí)間甚至不需要起本地開發(fā)環(huán)境踢涌，有些人喜歡吹乂不用 IDE，其實(shí)是可以理解的序宦。大家也可以試試我的開發(fā)方式睁壁，至少我自己因此多了寫 blog 的時(shí)間了 。
相關(guān)
文章同步發(fā)布于an-Onion 的 Github互捌。碼字不易潘明，歡迎點(diǎn)贊。
