在讲这个故事之前,先说我的观点:做技术选型,一定要结合团队现状来做出选择。这里的团队现状主要包括:你自己的技术能力、团队其他成员的技术能力、时间、管理方案、沟通结果、维护成本、技术方案本身的优缺点。总能把技术用在适合他的地方,才是一个成熟的架构师应该追求的能力。而不只是追求技术本身。
故事
昨天接到一位朋友的付费求助。他是某个团队的前端 Leader,手底下管了 7 个前端小伙伴,但是最近一段时间,由于管理不善,被老板多次当面批评,他感觉自己已经面临被裁员的风险,所以很慌,找我咨询应该怎么办。我详细了解了他的情况,然后发现,一切的原罪,居然是因为他一意孤行,在团队中强推 TypeScript。
最开始的时候,由于自己没有使用 TS 的经验,但是架不住在跟别人交流的时候,有人狂吹 TS,因此他觉得,自己还没用过 TS 是一种落后,于是,萌生了在项目中推行 TS 的想法。但是在开会公布这个决定的过程中,遭到了几个小伙伴的反对。他们觉得虽然 TS 有很多好处,但由于担心自己不会使用,因此心里没底。好在他在团队中还是比较强势,因此最终推行 TS 这个决定还是执行了下去。
在执行过程中,就遇到了大量更具体的问题:
1、错误评估了老项目升级的工作量
2、小伙伴有问题需要他解决时,他也没办法解决掉,从而导致了信任危机
3、关于 TS 的严格程度一直没有一个稳定的认知,制定的规范无法切实可行的落地,从而导致了内部矛盾加剧
4、需求多次 delay,最终爆雷
公司层面认为整个前端团队的工作态度出了问题,因此着手处理这个问题,最后下面几个小伙伴都认为是他强推 TS 导致的,从而被判定为他的综合能力有问题,他自己也无话可说。很显然,经历了这个事情,他在团队中的个人形象,无论是对上,还是对下,都受到了严重的破灭,可以说是一个非常惨痛的教训。那么,如果我们缺乏丰富的 TS 经验,在推行 TS 的过程中,应该怎么做呢?
一、搞清楚 TS 的本质
TS 的本质就是,他仅仅只是一个静态类型检测工具。他并不参与代码的运行。这里代表的含义就是,就算是我写的 TS 代码出现了严重的报错,我们的程序依然可以正常的被编译成 JS 然后成功运行。这是和其他强类型语言很不一样的地方。也就意味着,我的代码报错还是不报错,实际上就有了很多退让的空间。因为就算代码报错,也不影响运行。于是,TS 代码怎么写,规范应该怎么制定,就有了太多的可讨论的空间。
例如,我有一个函数,用于计算传入数字与 20 相加
function add20(count) {
return count + 20 // 堆代码 duidaima.com
}
对于开源项目/大团队内部公共项目而言,由于你无法控制使用者的传入习惯,有的人、团队可能就算是 TS 代码报错,也能容忍。因此,你的 TS 代码就不能直接这样写!
这样的开发者其实还不少
function add20(count: number) {
return count + 20
}
因为就算是我传入奇怪的入参,TS 也报错了,但是很多人无所谓。于是这样的项目,要确保类型的强大,又要确保类型安全,就必须老老实实的做体操,去兼容奇怪的传入,例如,兼容一些别的类型
function add21(count: number | string) {
if (typeof count === 'string') {
return 20 + parseInt(count)
}
return 20 + count
}
但是如果你没把控好这个本质和初衷,你也觉得你的 TS 也应该这么写,那就走远了,你的开发工作量和对 TS 的掌控难度就要高非常多。如果在可控范围以内,我们能够通过团队规范和约定限制传入类型呢?这样写,就是最佳方案与最简单的用法。
function add20(count: number) {
return count + 20
}
因此,当你的 TS 能力还不够纯熟时,你完全可以在团队使用第二种思维方式,通过限制传入类型来简化 TS 的应用难度。
二、约定其他的规范进一步简化 TS 的难度
有了这个大前提,我们已经在很大程度上避免了类型体操的操作。于此同时,我们需要判断你的 TS 项目是否会对外开发,只要不对外开放,我们还可以约定更多的规范来简化 TS 的使用难度。
例如
1、不使用 JS 标准中不支持的语法,例如枚举、public、private、重载等
2、尽量直接完整的写类型,少使用 extends、交叉类型、联合类型等各种组合的方式生成类型
3、尽量利用类型推导来约定类型
4、暂时放弃或者简化对参数为函数的类型约定。这是因为当参数为函数时,类型兼容性的判断可能会涉及到逆变与协变,理解起来比较困难,也可以用 any 代替
5、允许使用 @ts-ignore,并且学会通过这种方式,中断/改变三方开源库的类型推导
6、在合适的地方,强制使用 as 简化类型
...
✓
虽然我更多的是建议是在还不熟练的时候定义这些规范,但是用久了之后你会发现如果你的项目场景没有变化,这些规范也可以一直用下去
三、推广方式一定要范围可控
由于 TS 的特殊性,我们可以先小范围开始推行 TS,而不是直接在整个大项目中使用。这里的小范围包括人和需求。
一、在团队中选择个别优秀的成员开始实践,也可以你自己先实践,不要着急全团队推广。在你自己还不熟练的时候,全团队推广非常容易让你的个人形象受到严重的打击。
二、先在单独某个需求中试点。必须要确保不影响整个团队的开发进度。
三、在这个试用阶段沉淀好使用经验之后,再全团队推广。
总结
任何技术方案都并不是非他不可,包括我最近在公众号力推的 React 19 与 tailwindcss。虽然我个人能够感受到他们带来的好处,但是也只是从分享他们的使用体验的角度出发,来给大家分享这种方案的真实感受。但是我从来没有去下一个结论说,都要 2025 年了,你还没有用 react 19 你就 out 了。如果我在分享我的使用体验的过程中,你也感觉到了这个好处,然后自己去试用和体验,形成自己的使用经验,这才是我最根本的目的。
备注:当前阶段学习 React 19 的目的,更多的好处是体现在面试和晋升中吹牛逼,如果在实战中顺利运用,则对开发者的技术能力有更成熟、更完整的要求
任何技术方案的选择和改变,不管别人怎么吹,但是落地到具体实践中,都有可能涉及到沉重的代价。 因此,结合团队场景准确评估技术方案是一名资深开发者需要具备的能力。这也是为什么许多同学在面试中,经常会被问到为什么要选择某某技术方案的原因