这个项目终于到了尾声了。整个创作的过程大概历时三个月。记得第一章的时候还是挥汗如雨，不得不躲在空调屋子里面。但现在已经是初秋，晚上有丝丝的凉意。
这个是然叔第一次通过小册的形式和大家分享开发体会，以前更多的是文章和视频形式。这也是我第一次使用敏捷迭代的方法系统的讲解一个项目。在创作之初我希望用不断迭代的方法让大家更有开发的临场感觉。我们每个章节都设置了用户故事，都有复盘。我们从单个的组件的可行性分析开始，到最后上线，以及完成生态。整个过程都力图让大家感受到实战的氛围。
实战与教学模型
我相信所有的学员都特别喜欢实战课。因为实战课可以让我们越级体验自己无法接触到的开发环境。这个感觉有点像玩王者荣耀，借一个王者号去体验一下巅峰赛。这一点然叔和大家是一样的，比如最近关注 AI ，我就会找一些实战视频去看。等有了基本印象在去系统的学习。
但是所谓实战视频，其实是作者为学员从实战中抽象的教学模型。因为真正的实战项目会考虑兼容性，会有历史的包袱，会有大量知识点相似而需要重复的代码。所以如果想提高学习效率，最好的方法是选择好的教学模型去学习。
smarty-admin 就是一个然叔会长期维护的教学模型，里面计划会包括：
UI 组件库 （各种版本、React、Vue、Rollup、Vite）；
文档化工具；
静态代码生成器；
Admin 管理后台 ；
低代码搭建系统。
大家可以保持长期的关注。
工程化的实质
经历了一次组件库的搭建实战，不知道大家的感觉如何。这里分享一下然叔的理解。
其实然叔第一次接触工程化概念是在 05 年。那个时候还刚开始接触 Java 语言，做 Java 程序还比较简单，简单的程序可能还用 javac 来编译，或者需要将内嵌了 Java 代码的 jsp 放到 Tomcat 中进行执行。
更复杂一点的项目，有时会用到一些开发工具，比如 JBuilder。这样的原始编写方式显然给调试和代码组织都造成了严重的困难。那个时候我还在上大学，我一般的方法是尝试使用 shell 编写脚本来清除缓存，自动更新代码，重启服务器等。直到看到有人会使用 ant 和 maven 来进管理工程代码。才慢慢取代了我那些不成型的东西。
在前端其实也经历了同样的过程，一开始前端程序很简单，大体上只是内嵌于页面上的一段功能能代码。这样的复杂度还没必要使用工程。随着 Jquery 的出现，前后端分离的时代的到来，前端已经有能力成为 UI 技术的主导力量。后端只需要提供数据接口，其他的交给前端就好。
这样的程序不刷新页面，体验秒杀后端渲染时代的技术。但是随之前端的程序的复杂度就会呈指数形式上升。
这个时候就开始出现了前端技术的萌芽了。你需要创建独立的前端工程，需要模块化、和组件化提高代码的可读性，需要提供自动化过程来进行代码的 Bundle、压缩、丑化，还需要规范化检查工具控制代码质量。这也就是我们常讲的工程化四化。
自动化；
规范化；
模块化；
组件化。
前端代码大概经历很多代变化，大概可以分为
工作流时代： Grunt 、Gulp 生态；
Bundle 时代： Webpack 生态；
Bundless 时代： Vite 生态。
工作流时代主要的核心是自动化和优化工作流。相当于给前端任务添加了一套高级的脚本。Bundle 时代是以模块打包机为基础的，通过不同的 Plugin 与 Loader 实现不同功能。这种方式有一个致命问题就是性能。因为一个模块变化必须重新打包，虽然可以用缓存和并行处理提高性能。
随着浏览器对 ES 模块的支持，新的 Bundless 时代到来。Vite 横空出世，Vite 可以利用浏览器对 ES 模块的支持，让前端可以通不打包的方式调试。这样就可以极大提高研发效率。其实更激进的方式是生产环境也使用 ESM，包括第三方库也是通过 ESM 组织。当然这种方式还不太成熟。
新的 Vite 生态中的开发者，都经历了前面两个时代，具有非常丰富的开发经验。所以生态业发展的很快。这次我们的组件库就是在 Vite 生态下的工程化。你会发现文档化、原子CSS、单元测试都是 Vite 生态的产品。
可升级点
受限于小册篇幅，其实还有很多玄妙的黑魔法，没有在小册中展现。其实，工程化本身就是一个不断迭代和完善的过程。没有止境。这里面就给大家提几个大家可以试试。可以给然叔提 PR。
- Safelist 自动生成
在原子 CSS 章节中，你会发现 UnoCSS 中在变量中使用了某个样式，就必须要手动生成 safelist 。 这个其实非常烦人，最佳的办法，按需生成。也就是说，组件中使用到哪些样式就会自动生成。我给大家一个实现思路，首先组件使用 TS 语言开发，组件属性本身也应该是强类型的。这样任何样式都应该是一个枚举类型。所以最贱的方法应该是根据枚举类型生成 safelist。 这样相当于一举两得。
- 版本发布
这个点也很有意思，目前版本发布是通过 Github Action 实现的。但是发布过程还是比较复杂，需要包括修改版本号、 Git Tag ， 提交 PR、合并分支等多个步骤。这个地方也是可以考虑一下优化方法。
内容修订计划
然叔属于第一次写小册，其实对大家的用户画像没有太多了解。当时对小册的理解更多是来自于一些实战类的书籍。所以也没想到一定要 One Step One Step 的方式进行讲解。只是希望将代码中最核心的逻辑讲解给大家。所以很多缺少工程化基础的同学就有一点阅读障碍，很多同学比较容易跟丢。所以我准备将小册进行一定升级，让它成为一本更加详尽的实践指南。修订的内容包括：
完善流程： 尽量描述完整；
固定版本： 每个 packages 固定版本，解决版本困扰；
划分代码分支： 重点章节提供分支代码，便于参考；
解答问题： 这个大家可以将疑问提到 github.com。
寄语：工程化是团队的开路先锋，就是来踩坑的
最近，也看到很多评论。很多人会抱怨学小册踩坑太多，我觉得这个工程化实践可能是所有实践中踩坑最多的。因为本身，一个团队的架构组就是给全组人进行踩坑，他们会尝试不同的路线，尝试不稳定的版本，做 Pre 的性能测试，编写 Pilot Source。应该说他们就是项目的荒野求生之路。
做这种工作的人需要有坚强的意志和奉献的态度。无数次，我都是在深夜别人回家后解决问题，也会在项目开始的前期利用周六日来提前介入项目。我觉得如果你能够做这样的工作，是别人对你的巨大肯定。你可以通过这个机会来很好地提高你的团队领导力。
最后希望，阅读小册的每一位同学都可以成为团队的开路先锋。
优秀学员作品
我写了一个 ISSUE 大家随时把自己的优秀作品发出来
https://github.com/smarty-team/smarty-admin/issues/17
我会定时更新到我的小册最后
掘金文章
组件库