技术开源项目从零到一的心路历程

弦止音凉 · · 803 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

这是一次非常漫长过程,整个项目大约经历了2年的开发与维护,期间重大的重构了十几次架构。

首先一句话介绍一下整个项目:**基于 Node.js 的服务端 web 开发框架**

在这里我分享一下我的经验,希望能够帮助<<<**想做开源的同学**>>>

项目地址:传送门

背景

在公司中,我们一致都是使用 koa 来作为 node 的底层,对 koa + 各种中间件封装成了一个简易的框架,但是期间遇到了很多不好解决的问题,比如:ctx 的属性如何维护,如何保证框架的扩展性(完全通过中间件扩展框架既臃肿又不容易维护)等等,

所以我自己创建了这个项目,开始了这次开源项目之旅(受 springboot 与 laravel 的启发)。。。

框架设计

基于 TypeScript 开发

为了增加用户开发的体验(代码提示)和框架的代码质量(类型检测),我决定引入 Typescript 作为开发语言,其实第一版开发的时候我还是使用的 babel + es6 的方式开发的,但是经过多次的尝试,最后还是决定使用 Typescript 重构代码,最后结果也是非常完美(在这里我也推荐大家尝试 Typescript)

AOP 编程

受 springboot 的启发,在引入装饰器(注解)之后,这种 AOP 的方式给我带来了非常大的体验提升,例如我再也不需要在路由文件将路由指向控制器方法,然后找到控制器文件进行控制器代码的编写,我只需要 `@http.get(path)` 装饰到控制器方法框架就可以自动识别这个路由了

依赖注入

很多语言的框架都采用了容器+依赖注入的方式,以容器作为框架底层,其他模块以服务的形式在容器注册,借助容器的依赖管理功能来对所有模块解耦,我觉得这种方式用起来非常的舒服(个人意见),所以决定将这种方式引入

路由

之前用 koa-router 的时候,读过它的源码,性能不怎么好,后来看了 gin (Golang)框架的路由实现,觉得非常的适合(前缀树路由结构),性能爆炸,并将其引入了项目中,效果非常理想,详细可以看基准测试数据[传送门]

非常强大的扩展能力

框架不仅通过容器对模块进行了解耦,还可以利用容器的依赖管理能力,增强扩展的功能。在我的设计中, 不仅框架可以注册扩展,扩展也可以注册扩展,扩展之间还可以互相依赖,**“扩展扩展的扩展”!!!**

还有非常多的小设计。。。

生态建设

除了框架本身外,生态建设也非常重要,目前例如 Apache Dubbo 的 node 实现, Websocket 网关等扩展生态,也已经发布,未来会有更多官方的生态建设

心态的转变

从一开始为了提升自己而创建的项目,在经过几次重构迭代之后,心态发生了转变,希望自己的开源项目能帮助有需求的人,希望自己能为社区作出贡献,这种心态反而能够更快速的帮助自己提升

开源的好处

- 帮助有需求的人,同时也帮助自己

- 结交志同道合的朋友

- 获取社区反馈,提升项目质量

Github 工作流程

使用 [Github Flow],所有的代码更改都是通过 Pull Request 进行的

- Fork 仓库并从 master 创建自己的分支

- 如果]添加了应该测试的代码,添加测试。

- 如果更改了 api,更新文档

- 确保测试全部通过

- 确保代码可以通过风格检测

- 提交 Pull Request!

Commit 提交规范

我选择使用 [angular Commits] 风格提交 commit, 这样 history 看起来更加清晰,还可以自动生成 changelog

<type>(<scope>): <subject>

<BLANK LINE>

<body>

<BLANK LINE>

<footer>

type

提交 commit 的类型,包括以下几种:

- feat: 新功能

- fix: 修复问题

- docs: 修改文档

- style: 修改代码格式,不影响代码逻辑

- refactor: 重构代码,理论上不影响现有功能

- perf: 提升性能

- test: 增加修改测试用例

- chore: 修改工具相关(包括但不限于文档、代码生成等)

- deps: 升级依赖

scope

修改文件的范围(包括但不限于 doc, model, controller, db, provider......) 等内置模块

subject

一句话清楚的描述这次提交做了什么

body

补充 subject,适当增加原因、目的等相关因素,可选

footer

当有非兼容修改(Breaking Change)时必须在这里描述清楚

关联相关 issue,如 Closes #1, Closes #2, #3

总结

以上几点都是个人的选择,但是我还是比较推荐的,有了统一个风格和规范,才能让项目质量越来越好,也方便其他小伙伴加入

其实开源并不难,只要你认真去做了(奉献精神还是比较重要的),并且认真的处理反馈意见,我相信你的开源项目一定可以走的很远,大家一起为开源社区贡献一份力量吧,无论最后结果是怎么样的,对我自己来说,这是一段对自己提升最大的经历!

如果你是 Node.js 开发者/对 Node.js 感兴趣,欢迎加入我的开源项目哦~[传送门]


有疑问加站长微信联系(非本文作者)

本文来自:简书

感谢作者:弦止音凉

查看原文:技术开源项目从零到一的心路历程

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

803 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传