2024年末：浅谈阿里前端的多样化，灵魂一问-如何彻底防止APK反编译-CSDN博客

本文链接：https://blog.csdn.net/wfegre/article/details/137159137

如果拿冰山举例，我们尽量让用户们（运营、开发者）只看到露出海面的那一段，把概念和实操尽一切可能地简化，而被屏蔽在冰山下面的东西，包括了一系列的交付

高度被抽象的界面+数据描述标准，我们称之为模块；
兼顾性能和灵活性的客户端+服务端渲染架构；
离线的、简洁的零代码可视化平台；
提供线上服务的页面渲染引擎 + 数据网关;

有了这些交付物（以及基于它构建的大型生态），前端、设计师、后端（多数时候甚至不需要）围绕着高度可被复用的产品模块即可进行页面组装，将业务发布上线。这个方案简单又高效。以至于在很长时间，这套构架最终产生成了数以百万计的各种页面，其中包括不限于双十一，我们在阿里系各种App看到的很多页面都是基于这样的方案出来的。

然而这并不是终点。

其实道理也很简单：当效率上达到一定临界点后（通常是边际效应开始递减），对应的技术方案都越界碰触到另一个领域。

搭建技术也一样 - 一个业务的运行通常不是搭建一个页面就完成了 - 它涉及到整个业务的执行周期。好比一个线下商场要做一场年货活动，上架商品这个任务只是工作中的一部份，其他包括不限于选商家、选货品、制造氛围、顾客动线都是必须得完成的工作。

而线上业务的运行亦如此，除了“搭建页面” 这个看似简单的动作外，还有各种上下游环节，包括不限于 - 数据哪来（选品）、以什么规则展示（算法千人千面）、抵达什么用户（人群规则）、界面是怎样的（新式交互）、在哪儿展示（跨端渲染）、浏览体验是否又快又好（性能&质量）、业务效果如何（数据看板）等等，每个环节都或多或少地关联着前端相关技术。

基于此，我们根据业务的实际需要拓展了系统的功能边界。慢慢地，原本的面向效率、被高度抽象化的工具系统成为了一个解决具象业务的产品。

在这个转变过程中，原本核心工作是完成前台页面的前端程序员，逐渐成为了一个面向业务的技术工程师，而其工作职责从原来的高效交付扩大到了方方面面，技术视野、技术能力都得到了很大的提升。这时，我们也很难单纯用技术栈来界定这位程序员是前端抑或是后端工程师。

相信在未来，这样的前端工程师会越来越多，也会成为前端发展的一个方向。

技术栈从来不是技术人的桎梏！

Serverless，孕育新的生产关系

还是得谈谈这个话题，如果说越发完善的研发工程体系在提升交付整备质量、周全的性能故障监控系统在改进交付效果，那么 Serverless 就是在尝试着在最合适的环节来优化生产关系。

想必很多初入 CRUD 阶段的前端同学都尝试写过一个形如 Todo、blog-like等应用，基于广受各类教程推荐的 Express/Koa+MongoDB+ReactJS/VueJS 套件方案实现。

然而写完应用后的踌躇满志在遇到技术面试/业务应用时则一片茫然：怎么和预想的不一样？ - 性能调试、高可用、容量规划、多应用调用、数据库优化、跨栈中间件等等都是未曾太多考虑的问题，但若稍加深入思考，无需很久就进入新一阶段的灵魂拷问：为什么我要使用Node而不是其他工业化程度更高的语言技术栈？

而云原生下的Serverless 让多数前端们开始解除束缚：