到此为止，小册的全部设计篇的章节已经全部完结，后续我们将进入实战的环节。
在正式阅读实战的内容之前，本章我们一起来聊下小册的学习路线与目标。
如何阅读小册
如果是你高级前端或者自学能力较强的话，那么对于你来说技术栈将不是限制学习的重要卡点，可以通过设计篇里面的内容跟以及部分实战的关键代码来定制自己的低代码产品。
如果你是初中级的前端，那么在设计篇读完之后，首要就是将实战的代码跟着敲一下，虽然我们的代码未必是最好的，但也是经过不少项目实践后才写出来，有一定的参考意义，此外需要配合对应的官方文档，小册的内容虽然会比较全，但是由于实战的内容过多，难免有介绍不周全的地方。
设计篇
在这本小册中我们花费大量的章节来介绍整个项目的技术架构设计以及项目的价值、意义。
因为我们并不想只写一本技术类型的小册，这本小册更大的价值我个人感觉应该是过程，一个产品诞生的整个过程，包括产品的功能、体验等各种细节，对于商业、用户、研发的价值，以及这个过程中会遇到的各种意外。
小册最开始也说到了，当一个技术能被写成一套成体系的书的时候，这个技术其实已经处于被淘汰、落伍的边缘了，技术一定是不断地升级，但是架构设计肯定是不断从底层叠加上去的，很少件会有断崖式的升级，所以我认为需求与架构设计带来的思考远比使用某种技术更重要。
当然技术的升级并没有想象中的那么多快，从商业价值的角度上来说，稳定与安全更为重要，新技术普及的过程中通常会比预期的要久，BTW 现在用 JDK6 的公司也并不少，但软件架构设计思路是可以升级，这个与使用的框架、代码并无直接关系。
整个设计篇存在的意义在于：
- 明确需求：可以帮助开发团队更好地理解和明确软件系统的需求，从而为系统的设计和开发提供指导；
- 规范化需求：通过需求设计，可以将产品需求进行规范化和整理，使得需求更加清晰、明确、可行和可验证;
- 提高项目质量：通过架构设计，可以将系统拆解为各个模块组成，并定义它们之间的关系和交互方式，从而提高项目的可维护性、可扩展性、可靠性、安全性等质量属性；
对于刚接触这块的同学来说，即使每章节没能很好的理解也希望可以坚持看完，然后去思考为什么要这么做，不这么做的话会怎样，一定不要略过设计篇，它的价值会不仅仅会只限于低代码这个项目。
实战篇
在设计篇之后就是实战篇，整个实战的环节主要分为两个模块：
- 服务端 - NestJS，由 CookieBoty 主要负责
- 客户端 - ReactJS，由 wangly19 主要负责
其他的一些脚手架、插件开发以及服务端中使用到的一些中间件都会穿插在实战过程中一一讲解。
服务端学习
如果买过上一本 NestJS 小册同学，大部分新手都在接入的章节有一个非常大的坑需要自己踩过去，其实这一块的内容与技术一点关系都没有，纯粹就是需要找到对应的文档，整个流程走下来需要用到的文档跟步骤都已经列出来了，但如果阅读不仔细的话，就会陷入很多坑，比如发送信息的邮箱是当前组织的用户邮箱而不是注册的账号中的邮箱以及飞书机器人发送消息需要开启哪些权限等。
此外也有同学问，没有飞书怎么办？很正常，没有飞书你就要换成其他三方授权，企业微信、钉钉、自己写用户体系都可以，但是你要对接的就是需要接入的三方文档。
如果你学完了这本小册，完了你就学会了对接飞书，但你找到的公司都是使用钉钉，所以这本书就算白学了还是你一定要找到一家用飞书的公司不可？
客户端开发大部分的基础架构都可以做成通用化的，但是服务端的开发一定会吃掉很多业务逻辑，所以学习服务端第一步就是要学会阅读文档。
在服务端学习的过程中最重要就是看架构思想，下文挑出来的这位老哥的评论以及他的思考角度就非常好。
在我的架构设计中，用户系统作为底层会提高给其它服务基础的能力，而用户系统中已经使用飞书的用户与鉴权能力，并且飞书大部分的能力对于我的项目来说都需要走用户鉴权模块，所以我选择直接将飞书能力与用户系统进行深度绑定，这样对于我来说这样开发与维护的成本最低，但也可以将飞书整个能力都封装成 SDK 供给其他模块使用（飞书目前也开源了对应的 SDK）。
所以实战的代码未必是最佳架构，但一定会有如此设计的考量，如果有更好的方案可以与这位老哥一样留言互相讨论。
但在低代码小册的服务端学习中，一定不要现定于开发语言，单纯就看架构设计、需求拆解、业务实现这些，你甚至都可以不用 NestJS 作为开发语言，选择一款你熟悉的就可，Go、Java 哪怕是 PHP 都行。
除此之外在服务端开发的过程中会有很多中间件引入，例如 Redis、Jenkins、Mysql 等，这块是脱离于服务端开发框架之外且必不可少的工具，所以最大的困难并不是使用 NestJS 去开发这个项目(因为在经过一个比较大项目的 CURD 磨练之后，大部分的同学都可以正常学会 NestJS 开发)，而是相对应的中间件的使用过程中增加的额外学习成本，以及你对业务的理解与拆解。
客户端学习
与服务端学习不同的是，客户端的架构设计方案在框架不同的情况下就会有很大的差别的，例如使用 Vue 与 React 在语法、组件化实现、状态管理和生态系统都相差甚远。
那么如果在客户端的学习中达到想要的效果呢？
其实还是学习对应的架构设计，除去语法、拖拽库、状态管理之外，低代码中 Schema 的搭建与消费、物料开发与加载这些基础架构设计都是类似的，所以其实只是看着差距非常大，但是抛开业务堆砌的代码之外，大部分的能力都是通用的。
当然在技术选型上，之所以选了 React 也是看中了开发更加灵活以及生态体系更加庞大，最重要的是升级曲线较为平滑，很少会出现割裂性的升级，前文也提到对于商业化的产品，在不考虑使用与学习成本来的情况下，React 稳定升级带来优势更加巨大。
在客户端学习过程中，一些零碎的知识点会比较多，比如微前端、Monorepo 以及一些比较少见的框架 Turbo、craft.js 等。
在小册中，如果使用到了对应的插件只会针对于项目中使用到的功能来介绍，如果大家对于某一块的内容更感兴趣或者想定制、实现更多的功能，可以参考官方文档，同时当出现与预期写法不符合的时候，大概率就是版本更新，在阅读官方文档这块与服务端无异。
小册的诞生
由于我跟老王都分别有一本关于低代码的小册，但是主题上来说侧重点各有不同，老王偏前端的模块而我更偏向于全局以及服务端的内容，在我们沟通完发现如果合作一起的话，整个小册的生态跟完成度会更高，但这也是为什么小册的文章风格会有略微不同以及客户端与服务端的内容会相对性的不同步的原因。
但总体来说，我们最后会将其整合成为一个完整的产品，包括这本小册的内容也是随着产品的更新不断迭代，所以如果内容介绍不清晰、疑惑或者其他更好的想法可以留言讨论，有你们的帮助会让这本小册完成的更好。
如果你有什么疑问或者更好的建议，欢迎在评论区提出。 👏
12 🏆 学习里程碑：设计篇完结
