一个测试驱动的开源图床系统

1,230 阅读5分钟

先放地址再说话 :) github.com/Jiang-Xuan/…

Motivation

于2019年初对于 TDD, BDD 产生了极浓厚的兴趣, 但是测试驱动开发的模式造成了开发进度的严重脱缓, 导致无法及时的交付. 以及业务中各方对于测试驱动开发也没有多少兴趣, 所以选择从个人项目中尝试测试驱动开发, 在找了很多方向, 发现很少有成熟的开源图床系统, 遂对这个方向产生了兴趣, 这为其一.

从作者进入前端领域以来, 一直坚守 React 技术栈, 但其实在使用中对于 React 技术栈并没有太深入的研究, 因为业务需要的是及时交付, 而不是技术的深入, 所以在未来很可能该系统会深入的探索 React 的各种开发模式, 探索 React 的 Hook, Suspense, 服务端渲染, e2e 测试.

ant.design 是非常优秀的 React UI 库 github.com/ant-design/…, 在当前业务线一直在使用, 同样没有深入的探索和参与贡献. 在该项目中也会使用该库作为 UI 库.

成熟的系统会提供 API 给第三方来集成, API 的格式也在发展, 但是在平时的开发都无法严格遵循 RESTFul 风格, 但是会用这个风格来开发接口是非常重要的, 可以让你必须去熟悉 HTTP status code, 所以你不需要在面试之前去背这些 code 的语义了👍. 因此该系统会严格遵循 RESTFul 的接口风格, 未来也会浅尝一下 GraphQL 🍻.

CI/CD 持续集成, 持续部署 是在敏捷开发中非常重要的一节, 保证你在提交代码的时候可以不破坏已有的功能. 在本地的开发环境很少自己手动去测试多种环境下的表现. 使用 Node.js 10 在本地开发, 但是有可能会部署至 Node.js 8 环境下, 这时候让持续集成帮助你在 Node.js 8 下运行测试. 同样, Mac 作为开发机器, IE 的测试很麻烦, 让持续集成去做吧. 持续部署可以减少手动操作的麻烦, 让机器去做. 采用了 Github 的 Action 来做持续集成和持续部署, 即使不算完善, 但也是足够使用了, 并且提供 Windows 和 Mac 环境, 很棒 !!! 重要的是 free 嘘~~

试用 BFF 层, 该项目只使用了 bff 层托管 index.html, 这足够了, 接口还是交给后端去做.

还有一些其他能力, 项目的架构能力, 响应式设计 & Coding.

项目架构

项目分为 前端, 后端, 数据库和网关四个部分, 网关用的 nginx, 数据库是 MongoDB. 体现在该仓库之中的有两个部分 前端和后端.

前端

浏览器层

底层 UI 库为 React, 上层 UI 库为 antd. 路由使用 react-router. 代码打包器使用 webpack, css 预处理器 less. 代码预处理器 babel, 测试框架 jest, 浏览器兼容测 karma+chai+mocha, 浏览器 e2e 测试 jest-puppeteer.

静态资源发布策略?

在 github Action 中将资源打包然后发布至 ALI OSS 中.

BFF 层

web 框架 express, 测试框架 jest

如何更新 index.html 至最新版本的?

index.html 会跟随静态资源的发布发布至 ALI OSS 中, 然后在部署完成之后从 oss 之中下载下来, 下载 index.html 会在 CD 中执行.

后端

web 框架 express, 测试框架 jest, 接口测试工具 supertest.

beta 环境和 production 环境

tuchuang.space 的环境分为 beta 环境, 供给测试用户进行使用, 该环境和 production 几乎一致, 不过是用来测试最新版本的 tuchuang.space. production 环境为最稳定的环境, 提供给所有的用户.

功能

  1. 上传文件至 cdn, 获取文件的访问地址. 支持 png, webp. gif, jpg, svg 格式的图片

  2. 获取移除文件的 key, 然后通过 DELETE 方法移除该图片, 这里使用 arc 工具作为示例, 移除文件的接口文档可见 官网

Roadmap

尚未确定, 容易变化, 可以去项目的 Backlog milestone 或 issue 查看

结语

测试驱动是非常棒的, 但是作者个人认为测试驱动的学习曲线比较陡峭, 以及前端领域目前还都没有一个完美的浏览器测试方案, 所以在使用测试驱动的时候开发项目是比较纠结的, 什么时候应该使用测试驱动而什么时候不适用测试驱动是一个比较难以判断的问题, 作者也一直在学习, 对于测试驱动, 作者个人认为对于程序员来言是必备技能.

由于该项目并不是产品驱动, 而是技术驱动, 所以可以有更多的时间来深入技术的探索, 只有当程序员对技术特别熟悉才能投入使用, 并且深入探索这个技术到底是解决了什么问题, 如果有想要对技术深入探索的可以一起👋.

也许该项目的复杂度达不到有些公司业务的复杂度, 但是可以在该项目之上慢慢的探索, 最终也许能反馈给业务线之上, 很强的技术深度可以让你在业务线上有更多的话语权.

更多的东西可以去阅读源码获得🧐.