好快,这个专栏的常规更新部分到这里就正式结束了。恭喜你打败了学习的惰性,一路坚持到这里。现在,我们是时候停下来稍微总结一番,以便更好地开启后续的学习。
创建好了这篇文章的空白文档后,我的脑袋和新建的文档一样空白,思绪一下子飞跃到了四年前,我决定先和你分享下我是如何与低代码结缘的。听听我的故事,希望它能给你树立一些信心。
如果非要给我的低代码之旅设定一个明确的起点,那应该是 4 年前的 3 月,在我收到那封低代码相关的封闭研讨邮件的时候。但在这之前,我就建设低代码工具这个问题,与其他兄弟单位有过接触。受限于资源,双方决定采用分工合作的方式,我们负责 Web 组件,对方负责低代码引擎。
那时我们在成都组织了多次探讨,我现在许多关于低代码的设计理念,都是在这些探讨过程逐渐形成的。但可惜双方理念相差较大,最终没能走到一起。对方无法接受我先通用再具体的方案,执意要“务实”地对具体场景提供支持,因为这样“风险小、见效快”。
后来再收到这封闭关研讨的邮件时,我就明白老板这是下决心要自己搞了。
随着研讨越发地深入,我越觉得这个事情难度巨大,甚至,我还一度因畏难情绪和其他因素萌生了退意,但看着这个我当时花了近两年给老板画出来的饼,已经在我嘴边了,只要一张嘴就可以咬上一口,最终我还是选择了坚持。我至今仍在庆幸当时的选择。
从最开始设计 Awade 的编译器时,担心纯可视化搞不定,选择让编译器能够生成出人类可读、可改的代码;到后来慢慢走上正轨,解决了开发过程中大大小小无数的难题;再到现在,脚下的低代码之路已经逐渐变得平坦且宽阔。从最开始受到的各种质疑,到现在,进度紧急时,经理们会特地点名必须使用 Awade 以确保其交付进度是可控的。
一时间,感慨万千。
最后的事实证明,先通用、再具体才是正路。通用性创造的是未来的可能性,虽然早期道路坎坷艰辛,但我们还是坚持下来了,路是越来越平坦的。反之,如果你过于着眼于眼下,看似务实,实际上更容易因架构设计的韧性不足,导致路越走越窄,举步维艰。我一直非常注重竞品调研,我搜遍公司内外各种竞品,做了很多调研,后来成都那个团队的产品也没有再出现在我的竞品清单中。
在这个专栏的交流群中,我看到很多同学都是一线低代码平台的设计者和实现者。可能很多和那时候的我一样,或是正绞尽脑汁给领导画饼,或是正迷茫在架构策略的抉择中,又或者是正受困于某个技术难题,不知如何向前。
我非常希望这个专栏能帮助你解决眼下的困境,也非常希望你能坚持一下,再坚持一下,走到最后。如果你在此过程中有啥困惑或难题,欢迎来找我。
时间拉回今年春节前,极客时间团队的小伙伴开始和我接触,邀请我来写低代码这专栏。我当时的第一想法是非常兴奋,不谦虚地说,我是国内最早开始“吃”低代码这只“螃蟹”的一批人,坚持到现在,已经超过 4 年了。在此过程中我积累了大量的实战经验,极客时间是整理和展示我这些经验的一个很好的平台。
兴奋之余,我又感觉非常为难:具体的内容应该如何编排呢?毕竟,低代码技术是一个综合性非常高的话题,低代码涉及的方面非常多,可以讲的内容也非常多。我们可以从实际应用的角度来讲,也可以从系统架构实现的方向来讲。同时不同的方向上还可以有不同的侧重,不同的方向和侧重,面对的人群还不一样,适用的内容也不一样。
所以,我花了非常多的时间纠结到底怎么挑选内容。最终,我选定了低代码平台的架构和实现这个大的讲解方向,同时偏重于系统架构的设计,忽略掉过细的实现细节。
那么,在低代码的架构和实现这个大方向下,要选择哪些功能和模块进行讲解呢?
经过一番精挑细选后,我决定围绕着低代码编辑器这个功能来打造这门课。低代码编辑器是低代码平台最关键的功能。它的能力和实现的质量,直接决定了低代码平台的能力和质量。虽然低代码平台综合性很高,可以做的功能点众多,在各家企业里落地时,大家都各有侧重,有的先解决服务端侧,有的先解决前端侧的问题。但无论你侧重建设哪个端的功能,低代码编辑器都是绕不过去的一个功能点。
这个专栏的常规更新部分的主体内容,就是按照这样的考虑来设计和编写的。
但是,我们当然不可能一上来就单刀直入,直接剖析低代码编辑器,还是要遵循学习知识的一般认知流程。所以我将内容分成了三大部分,先从认知基础与架构策略切入,着重介绍了低代码的演进策略和低代码编译器与编辑器之间的关系。
我希望你在开工之前先想好路怎么走,这比啥都重要。你要先想清楚你负责的子系统与上下游子系统的关系,若保持强耦合,对方值得托付吗?还是留个活扣,给自己以后多一个选择?特别是,你不要急着编码,一旦开始写代码,就容易陷入细节,不能自拔了。写代码永远是最容易的一件事,前提是你真的想清楚了。
接下来的第二、第三部分是我们常规更新的重点内容:低代码编辑器的架构和实现,以及低代码平台的拓展。这些内容都比较硬核,因为我们很难用短短几千字讲清楚一个架构知识点,而且抛开业务谈架构都是在耍流氓,你可以看到,每一讲中我都非常注重业务场景的讲解,也针对不同的业务场景给出了一些建议。你可以结合自己的实际情况辩证地看。
我注意到,前两天交流群里有同学提到,每一讲的文字量都很大。其实,我之前写文字稿时就注意到了这个问题,我往往需要用目标篇幅的 1.5 倍左右才能完成一讲的内容,常常才写完第一个小标题时就发现已经用掉了大半的目标篇幅了,不得不回头再精简内容,但总是觉得,少了这块不行,少了那块也不行。
即使我“精打细算”地使用好每一讲的篇幅,但你应该也可以发现,有些内容依然是蜻蜓点水般一带而过了,没能讲透,特别是第三部分的两讲更是如此。这些没涉及、没展开、没讲透的内容,就要留着在这个专栏的动态更新部分才能展开了。
动态更新是极客时间的一种创新,特别适合学习低代码这样综合性高、内容繁复多样的知识。和常规更新阶段事先敲定内容的学习形式不同,动态更新阶段中,你可以一边学习,一边和我互动,我会针对你的学习状况和需求,动态设计和组织剩下的内容,达到定制化的学习效果。
那么动态更新部分,将会有哪些内容呢?
首先,这一阶段最主要的是把在常规更新部分里的那些“等有机会…”“下次再说…”的部分补齐。你可以将这个课程看成是一棵树。常规更新部分是大树的树干和部分枝丫,而动态更新部分是沿着树干生长出的各个重要枝丫;
其次,这一阶段我们要尝试跳出以低代码编辑器为中心的思路,尝试围绕其他角度,来完成低代码平台的架构和实现。因为低代码编辑器并不是低代码平台的全部,它只是一个核心部件,低代码平台还有其他许多有价值的功能需要建设;
最后,我们还会对业界进行持续跟踪和观察,包括但不限于开源社区、调查机构、甚至还有一些竞争对手的资料,但这个角度的内容篇幅不会很大。
动态更新内容的大方向,将和常规更新的内容保持基本一致,我将继续保持在低代码平台的架构和实现这个方向上进行讲解,不会做方向性的大幅度调整。
不过,此时此刻,动态更新的内容还没完全定型,你我可以一起来设计剩余的内容。欢迎你把想要学习的内容写在评论区、交流群,或者这个【调查问卷】中,我们一起来设计剩余的内容。
正如在开篇词中向你承诺的那样,动态更新部分将有 20 讲左右的内容,大致以每个季度至少一讲的频率,每年更新 5 讲,持续 4 年。衷心邀请你和我一起完成这场“长跑”,在接下来的学习中,不仅紧追低代码的前沿“脉动”,更重要的是在逐渐深入的学习和实践中,完善低代码的知识体系,提升自己的架构能力。
这里先预告一下,接下来动态更新阶段的第一篇文章将在今年 7 月更新,一定要记得回来学习呀,我也会在交流群里通知你的!
最后,我还想跟你说个题外话。有可能你曾经去词典里搜索过“awade”这个单词,想必是一无所获。因为这是一个我自创的单词,它来自“Anyone can be A Web Application Developer Exper”这句话的首字母,翻译过来就是人人都是 Web 应用开发专家。
这就是 Awade 的使命,也是当时在研讨和设计 Awade 过程中,大家共同的愿望。作为一个低代码平台的设计和实现者,我们希望在它的帮助和赋能下,人人都可以成为一个 Web 应用的开发专家,而不是仅仅只有那些掌握了 Web 研发技术的职业开发人员才能成为专家。
现在,我把 Awade 的架构和实现方法整理出来了,希望你通过对这个专栏的学习,也能设计出一个低门槛、高效率的低代码开发平台 ,赋能它的使用者,让大家都成为 Web 应用的开发专家,为业务实现真正的降本增效。
探索低代码之路,我们才刚刚开始,就让我们一起继续研究,探索出更好的低代码实现之路吧!
© 2019 - 2023 Liangliang Lee. Powered by gin and hexo-theme-book.