相识

作为一名程序猿👨‍🦲，最熟悉的两个按键那就是 CV 了，这种 CV 不止是从网上或者找 AI 寻找答案后复制粘贴到我们的项目代码中，还有一层意思也是：在一个项目中重复的代码为了节省时间直接 复制粘贴 修改一些字段然后进行接口对接🙋‍♂️，然后就愉快😆的提交代码了。但这样确实一时爽，后面要改功能，增加新功能之类的都会让你如履薄冰🥶。

之后为了防止我的石山越长越高，就会将重复的功能抽离出来，在基本的功能之外就会对其想一想🤔还有没有可能拓展的功能？尽量就把他抽离出来，后续 leader 呼唤要修改功能的时候，就不用“到处跑”了。

上面提到的是作为在开发阶段，我对我自己的代码进行了一些 “抽离” 来使我后面的开发更简便，但还有一种 “魔法”，这个修改就不是在开发时的 “抽离” 了，转变而成的它 居然😲在编译的时候就进行一些的 “魔法攻击”，它有一个响亮的名字—— Loader。

相遇

本期的主人公—— Elpis-core。作为一名编译时的魔法攻击者，他会在应用启动之前，读取所有相关约定好的规则来进行自动加载组件和各种配置信息👍，除此之外还有其他优点，如：

1. 约定大于配置：通过固定文件目录结构和命名规范 -> 自动加载模块，从而减少手动的 import
2. 模块化管理：每个功能模块独立管理，诸如路由模块、中间件、服务层、控制器、配置文档等，便于功能维护与拓展
3. 灵活性：支持自定义扩展(功能、配置、模块等)

相知

看到这里，是不是也跟我一样（小白吃惊😮），居然还能这么搞 懒人工具。

"懒"是一些需求的根源

——爱偷懒的程序员

接下来，我准备与你来分享这个 魔法 背后的秘密（一点点吧，主要我也是刚开始学习🤣）

目录结构

整个项目的入口🚪就是根目录下的 index.js。

Loader

在 ElipisCore 中就是一个加载器系统(Loader)，主要作用就是在应用启动时自动加载和初始化各种配置信息。

在 Loader下的每个子模块都是在约定下去指定目录寻找指定文件进行加载

├── app/                    # 业务代码目录
│   ├── controller/        # 控制器层：处理请求响应
│   ├── service/          # 服务层：业务逻辑
│   ├── middleware/       # 中间件：请求处理管道
│   ├── router-schema/    # API 参数校验规则
│   └── extend/          # 功能扩展
└── elpis-core/           # 框架核心
    └── loader/          # 自动加载器

比如拿一个我们作为萌新😳最容易理解的 controller loader。

 /*
 * 例子:
 * app/controller
 *  |
 *  | -- custom-module
 *    | 
 *    | -- custom-controller.js
 * 
 *  => app.controller.customModule.customController
*/

至此，我们的装备🗡已经做好归类，想要什么类型就能快速定位，但面对强大的怪物，还得再做一套完整的计划。

app

从 Loader出来之后我们就已经是又有🛡又有🗡，但不会用呀💭

这时候就要介绍我们的好邻居们（中间件、路由、控制器、服务层等），他们每个家族的🏠住址就在 app中，而且他们每个家族里面也都有好多性（类）格（型）的兄弟姐妹，比如中间价家族就还有分异常处理部落、api校验部落和api签名认证部落等，为什么说他们是我的好邻居呢？因为在外头有人要挑事他们总会挡在我前面，其中就中间件家族最仗义了，总是冲在最前面。

相伴

由上面介绍应该可以知道我们面对不同等级的困难也有了一定的应对措施，但回到现实(🐂🐎)，这对开发又有什么好处呢？

问题又回到了一开始的我们的相遇，优点已经大概罗列的，但

规矩是死的，人是活的。

虽然有了良好的开发规范和约定，但还是得靠我们自己遵守，其次就是👆不要逼得太紧，🐕急了都会跳墙呢，更何况人呢？所以约定在紧急关头上🤔，我觉得还是不太管用的。

但至少我们知道能这样做！可以来提高我们的开发效率和降低维护成本，这已经就相当不错啦~