HTML/CSS

设计系统的尽头是没人用

每个前端团队最终都会走上同一条路:建组件库,搞设计系统,画设计规范文档。

然后看着它慢慢死去。

不是夸张。我见过太多团队花大力气搭了一套设计系统,上线时热热闹闹,半年后只剩一个人在维护,一年后连那个人也转岗了。业务线该自己封装的还是自己封装,该重复的还是重复,设计系统变成了一座精美的鬼城。

这个现象太普遍了,普遍到已经不值得用"执行力不够"来解释。问题不在人,在设计系统这个事情本身的逻辑里。

 

建设者的幻觉

 

设计系统的出发点通常很理想:统一视觉规范,提高开发效率,减少重复劳动。听起来无懈可击。

但这个逻辑有一个隐含前提——业务足够稳定,需求足够规范,变化足够可控。

现实呢?

金融产品恨不得每周换一轮视觉,大促活动页面跟日常页面完全是两套设计语言,某个业务线因为合规要求必须用特殊样式,另一个业务线因为老板拍板要用新风格。你精心设计的 Button 组件有十二个 variant,但业务要的是第十三个。

设计系统的建设者往往是架构团队或基础设施团队。他们离业务远,有时间做抽象。但离业务远恰恰是问题所在——你抽象出来的东西,天然跟不上业务的节奏。

Serverless:复杂度没有消失,只是换了地址

2018年前后,Serverless在国内技术圈火了一阵。各大云厂商轮番布道,"按需付费"、"零运维"、"自动扩缩容"——每个口号都精准戳中了团队的痛点。我当时也投入了不少精力研究,毕竟谁不想不用管服务器?

几年过去了,当初那些All in Serverless的团队,相当一部分已经在往回走。不是Serverless不好,而是很多人慢慢意识到:当初以为消灭的复杂度,其实只是搬了个家。

 

那些承诺里没写的小字

 

Serverless的核心承诺有三条,每一条都有对应的现实版本。

"不用管服务器"——开发者只需写业务逻辑,基础设施平台托管。这对前端团队尤其有吸引力,写完函数丢上去就能跑,不用折腾部署和运维。但现实是,你很快会发现自己需要关注函数的内存配置、超时时间、并发限制、冷启动策略、VPC配置、IAM权限……这些不叫"服务器运维",但本质上还是在管基础设施,只是换了个仪表盘。

"按需付费"——代码不运行就不收钱,空转成本消失。但下一句没人告诉你的是:按需付费的反面是成本不可预测。一个函数死循环触发重试,一个爬虫突然疯爬你的API,一个配置错误导致无限调用——这些异常场景下的账单,会让你深切怀念固定成本的日子。

发布恐惧怪圈:你加的每道门禁都在让发布更危险

上周有个做支付系统的朋友跟我吐槽,他们团队每次发版要过六道门禁——代码审查、单元测试覆盖率、集成测试、安全扫描、性能基线、人工审批。听起来很严谨对吧?结果他们每次发布的变更量越来越大的同时,线上故障却没有减少。反而因为每次发布都是"大手术",一出问题就是大问题。

这不是个例。我观察过不少团队,尤其是金融、支付这类对稳定性要求极高的业务线,都有一个共同的倾向:发布越怕出错,就越加流程;流程越重,发布频率越低;频率越低,每次发布承载的变更越多;变更越多,出错概率越高——然后更怕出错,继续加流程。

这就是发布恐惧怪圈。而最反直觉的地方在于:你加的每一道门禁,都在让下一次发布更危险。

 

门禁越多,发布越重

 

这是最直接的后果,也是最容易被人忽视的。

假设一个团队每周发布一次,每次发布平均包含 15 个 commit 的变更。后来因为一次线上事故,决定加强管控:发布前必须经过安全扫描和性能基线验证,流程从一天变成了三天。发布频率自然从每周一次降到了每两周一次。但开发节奏没变,两周的变更量是 30 个 commit。

看到了吗?单次发布的爆炸半径翻倍了。

重构冲动:写下代码的那一刻才是你最清醒的时候

每个工程师都有过这种时刻——翻开一段半年前写的代码,眉头一皱,手指开始痒。"这什么写法?""这命名谁看得懂?""这段逻辑完全可以抽象成三个函数。"然后一个"重构"的念头冒出来,越来越强烈,像夏天傍晚的蚊子,赶不走。

这种冲动太普遍了,以至于我们很少质疑它。代码审查时建议重构,结对编程时讨论重构,技术债清单里排满了重构项,季度规划里少不了"代码优化"的工时。重构似乎天然正确,像一种工程美德。

但我的观察恰恰相反:大部分重构是错误的决定。不是重构这件事有问题,是驱动重构的动机和时机几乎总是错的。

 

丑代码不等于坏代码

 

先说一个多数人不愿意接受的事实:代码的审美和代码的质量,经常是两回事。

一段看起来笨拙的代码,可能在一个微妙的时间窗口里正确处理了并发竞争。一段到处是硬编码的代码,可能正是因为硬编码才避免了配置出错引发线上故障。一段三百行的函数,可能是经过六次需求变更后唯一还hold得住的逻辑形态——你把它拆成六个"优雅"的函数之后,任何一个需求的变更都会涉及三个函数的修改,追踪数据流变成了噩梦。

"丑"是主观判断,"坏"是客观后果。两者之间没有必然因果关系,但在重构决策里,它们经常被混为一谈。工程师看到不美的代码就判定它需要重构,这个推理本身就是逻辑谬误。

前端性能优化的尽头是架构问题

每次聊性能优化,话题总是很快滑向具体的技术手段:懒加载、代码分割、图片压缩、Tree Shaking、虚拟列表……这些当然有用,但我想说一个可能让不少人不太舒服的判断——当你在做这些"优化"的时候,大概率已经晚了。 真正决定性能天花板的,不是你用了多少优化手段,而是系统架构在最初就给你画了多高的天花板。

性能问题从来不是前端单方面的问题。但很多团队把它当成了前端的问题,于是前端工程师就像一个装修工人,在毛坯房里拼命贴墙纸——墙纸再好看,承重墙没打好,房子一样不牢。

 

优化手段的天花板

 

先承认一个事实:常规的性能优化手段确实能解决一部分问题。一个从没做过任何优化的项目,加上代码分割和懒加载,首屏时间砍一半不稀奇。图片做个WebP转换、加个CDN,LCP直接降几百毫秒。这些是低垂的果实,摘了就是摘了,没人否认。

但问题是,这些优化有上限。你的首屏要从3秒优化到1.5秒,代码分割和懒加载就够了。但如果你要从1.5秒到800毫秒,甚至到500毫秒以内,单靠前端手段就力不从心了。因为剩余的耗时大头不在前端——它在网络请求、在服务端处理、在数据组装、在协议开销。

当配置比代码还复杂:配置化平台的真实边界

配置化平台这两年在金融和电商领域特别火。业务方想要灵活调整页面,需求排期又排不开,于是"配置化"三个字成了万能解药——做活动页?配置化。改文案?配置化。调整布局?配置化。好像只要搞一个配置平台,所有迭代效率的问题就烟消云散了。

但我想说一个可能得罪人的判断:大部分团队的配置平台,最终都变成了另一个更难维护的代码库。 只不过这个代码库没有版本控制,没有代码审查,调试靠肉眼,回滚靠运气。

 

配置化的承诺

 

先承认一个事实:配置化的出发点是对的。

在金融业务里,一个理财产品的详情页可能每周都要调整——改一个利率展示规则、加一个风险提示文案、换一个活动入口。这些需求的特点是:变频繁、逻辑简单、但等不及排期。 如果每次都走完整的需求-开发-测试-发布流程,前端团队光是接这些零碎需求就别干别的了。

配置化要解决的核心问题很清楚:把高频、低风险的变更从开发流程中剥离出来,让业务方自助完成。

这个思路本身没问题。问题出在执行上。

 

第一个陷阱:配置化的范围蔓延

 

几乎所有配置平台都经历了同样的演化路径。

代码审查的真相:大多数CR流程都在浪费时间

前几天团队来了个新人,看到我们的CR流程后很兴奋:"你们的Code Review好规范啊,每个PR都要两个Approver才能合并。"我笑了笑没说话。

因为我知道,这套看起来"规范"的流程,实际上每天都在发生这样的事情:开发者提交一个几百行的PR,半天没人review;着急上线就去钉钉群里@几个人;被@的人打开看一眼,觉得代码没大问题就点了Approve;测试环境跑了一遍没报错,代码就合并了。

整个过程看起来很严谨,实际上谁也不知道这段代码到底干了什么。

 

大多数CR都是形式主义

 

我见过太多团队把Code Review当成一种"仪式感"——必须要有这个环节,但没人在乎它到底有没有效果。

最常见的场景是:PR提交后,reviewer们象征性地打开看一眼,扫过去没发现明显的bug或者格式问题,就点了Approve。至于这段代码的设计是否合理、是否有更好的实现方式、是否会给系统带来潜在风险,没人去深究。

为什么会这样?因为review代码比写代码累。

微前端的陷阱:为什么大部分团队不需要qiankun

微前端这几年很火,但我见过太多团队在盲目引入后陷入困境。最常见的情况是:团队只有3-5个前端开发,维护着2-3个业务模块,却花了两个月时间接入qiankun,结果代码复杂度翻倍,问题却没解决几个。

这不是qiankun的问题,而是大部分团队根本不需要微前端。

 

微前端解决的是组织问题,不是技术问题

 

很多人把微前端当成技术架构来看,这是第一个误区。

微前端的核心价值在于让不同团队能够独立开发、独立部署自己的模块,而不是解决技术上的模块化或性能问题。如果你的团队只有一个前端组,那么引入微前端就像一个人住别墅——空间是有了,但打扫卫生的时间也翻倍了。

我在金融业务中见过一个典型案例:公司有理财、基金、保险三条业务线,分属三个独立团队,各团队技术栈不同(React、Vue、Angular都有),发布节奏也不一致。这种情况下,微前端是合理的选择,因为组织边界清晰,技术隔离是刚需。

但大部分团队的情况是:前端是一个Team,后端可能分了几个服务,然后看到微服务很流行,就觉得前端也该"微"一下。这就是刻舟求剑了。

 

微前端带来的复杂度被严重低估

 

引入微前端后,你要面对的问题比想象中多得多:

API 设计的两个误区:RESTful 和 GraphQL 都不是银弹

前两天团队讨论新业务的技术方案,后端同学提议用 GraphQL,理由是"前端可以自己控制数据结构,不用频繁改接口"。我问了一句:"你们后端有多少人?"答:"3个人"。我说:"那别折腾了,RESTful 就够了"。

这不是第一次遇到这种情况。这些年做全栈,从后端写 API 到前端调 API 再到 BFF 层设计 API,见过太多技术选型上的执念。最常见的两个误区:一是觉得 RESTful 就是正统,必须符合所有规范;二是觉得 GraphQL 能解决前后端协作的所有问题。

事实上,这两个都不是银弹。

 

RESTful 的形式主义陷阱

 

大部分开发者第一次接触 API 设计,学的都是 RESTful 规范。GET 查询、POST 创建、PUT 更新、DELETE 删除,资源路径用名词不用动词,状态码要严格遵循 HTTP 标准。这些原则没错,但问题在于,很多人把它当成了教条。

一个前端老兵眼中的AI时代

在金融科技公司做了很多年前端,经历过几轮技术变革。从移动端崛起、SPA框架盛行,到微前端、Serverless,每次都有人说"前端要变天了"。现在轮到AI了,焦虑又开始蔓延。

但我的观察是:大部分前端开发者高估了AI的威胁,低估了自己的价值。

 

这次真的不一样吗?

 

先说个场景。我们在做理财产品详情页改版时,产品经理提了个需求:"能不能感知用户的疑虑,在适当的时候主动给出回答?"

听起来很AI,对吧?但落地时发现,金融产品的风险提示有严格的合规要求:哪些话能说、哪些不能说、如何表述、字号大小、颜色对比度,全部有监管规定。AI生成的回答可能很流畅,但不能直接上线,必须经过合规审核、法务确认、AB测试验证。

最后怎么做的?我们用AI做语义理解和意图识别,但回答内容是预设的合规话术库,前端负责整个交互流程、异常处理、埋点监控、合规展示。这个需求,AI解决了一部分问题,但核心的业务理解、风险控制、用户体验,还是要靠人。

AI时代和以往技术变革最大的不同:它不是替代某个技术栈,而是改变了生产方式。

页面