关于全栈:做好这四步服务端轻松成为全栈化人才

软件开发里本没有服务端，分的细了就有了服务端。做为一个软件开发者，每个人都能够是全栈。看到“服务端全栈”这个词，不晓得屏幕前的你当初脑子里想到的是什么问题。

• 老板：咱们团队的服务端能够去写前端么？会不会搞出很多故障？能不能缩短开发工夫？能不能给我节省成本？
• 前端：你都能写前端了，那还要我干嘛？
• 服务端：我有必要学前端么？写前端对我职业生涯有啥益处？学到啥水平能够写前端需要，公布前端的利用？

我第一次晓得这个词的时候，脑子里是一片空白的状态：老板把我叫到茶水间，理解了一下前端教训、排期状况，选了我去做“服务端全栈化”。具体就是有个我的项目前端缺人手，我的项目中曾经有个前端大佬，让我去打打辅助。

过后的我只在 flask 我的项目写过简略的 html，三大前端框架都不会，满心欢喜的筹备去我的项目室抱大腿学前端。等我到了我的项目室发现，带我的前端大佬是日理万机的前端大团队 TL，我也不太好意思让大佬陪着我写代码，我就变成了我的项目里惟一一个前端开发，大家都叫我团队的希（瓶）望（颈）。

从那天开始，我白天强装镇定在我的项目室写前端，深夜疯狂补课、学习前端常识，解决白天遇到的问题。过程中好在前端 TL 很给力，帮忙找了很多资源解决我开发中遇到的问题，就这样磕磕绊绊继续了一个多月，我的项目终于上线了。这也成了我的全栈化初体验。

在尔后的一年中，我在没有耽搁服务端成长的状况下，从一个须要前端帮助的全栈开发，成长为了独当一面、能够牵头整个模块级的前后端系分设计、辅导其余服务端同学进行前端开发、把控前端我的项目品质、上线前端我的项目的全栈化同学。

作为团队的全栈化标杆同学，和咱们团队惟一的前端同学一起，在老板的鼎力支持下，走出了一套可复制可迁徙的服务端团队全栈化路线，团队里年老的服务端开发同学都具肯定的全栈能力，团队的前端资源不再成为瓶颈。

在我和咱们团队其他同学的全栈化实际中，我留神到每个阶段都有一些共性的痛点和问题，也有一些本人的解决思路和教训，心愿分享进去让前人能够更轻松退出全栈化小家庭，走的更快更稳。

第一步：从入门到不放弃——前端根底学习

在入门阶段，咱们须要解决以下几个问题：

• 前端常识去哪学，怎么学？学到啥水平能够入手？看完我认为我会了，一入手写憋不出两行代码。
• 语言问题、开源框架的问题能够问 chatGPT，外部框架、工具的问题没有脉络。
• 简略的画页面和逻辑终于能够写了，一遇到环境问题或者疑难杂症就只能求助或绕过。

Tip1 系统性疾速学习，理解技术幅员，开发过程中扣细节

不晓得大家在大学的考试周，有没有过“一夜一门课，两周一学期”的体验。我作为一个长期抱佛脚选手，对这一点深有体会。这种学习习惯自身并不值得提倡，然而其中的一些学习技巧能够提炼进去迁徙使用。

工作中的学习，很少可能有让人齐全筹备好再上的机会，往往也是相似考试周的这种系统性疾速学习 + 突击性具体学习的组合。系统性的疾速学习能够在整个常识体系中，画出一张地图；突击性的学习可能让地图上具体的一小块更清晰。有了地图和一直的突击，就能够更快把常识连成面，造成本人的常识体系。

以钉钉的前端常识体系为例，咱们团队的前端同学曾经给大家梳理了一份前端知识点大图，这个大图解决了从 0 到 1 学什么的问题，它就像前文里说的地图，有了这个地图，就有了前端常识陆地里的导航，要做的就是摸索和欠缺这个地图。

对于看视频还是看书学习，不同人的习惯各不相同，我倡议抉择适宜本人的就好，相干的材料也十分好找，不论是阿里外部的奇点学堂，还是内部的 B 站、油管、以及各种常识付费 App，都有很多优良的学习材料。

比学习知识点更重要的是实际。在全栈化初期，我的前端能力之所以能疾速成长，离不开前文提到的那段我的项目里白天写 bug，早晨边学边修 bug 的经验。例如学完 React 的 hook，立即用 hook 重写一下本人之前的 Class 组件；学完高阶函数，立即用高阶函数去重构一段适配器逻辑。我并不激励炫技式的应用一些组件或个性，然而如果一个新知识点能够让咱们的代码从中受害，我肯定会去尝试。

Tip2 不要放过任何一个疑难杂症或者顺当的中央

在入门阶段，我经常出现本人写了一段烂代码而不自知的状况，不过很快我有了感知这类烂代码的技巧：当一段逻辑，本人都感觉写的不棘手或顺当的时候，往往意味着有更好的解决方案。这时应该记下来，尽快查找、求教，寻取更好的实现形式，并对知识点查漏补缺。

上面这段代码我本人第一次用 React 实现一个带有筛选器的、反对分页加载更多的表格。直观看，就是有很多个 state，并且 state 之间不是正交的。

const TableBizComponent: React.FC<ITableBizComponentProps> = (props) => {const {dataId, corpId, yearMonth} = props; // 年月筛选和数据 id 从 props 传入
const [pageNo, setPageNo] = useState(1); // 页号初始化
const [selectedFilterId, setSelectedFilterId] = useState(null); // 筛选器选中 id
const [filterData, setFilterData] = useState(null); // 筛选器数据
const [columns, setColumns] = useState([]); // table 表头
const [data, setData] = useState([]); // table 全副数据行
const [hasMore, setHasMore] = useState(true); // 是否更多 初始化
const [needUpdate, setNeedUpdate] = useState(false); // 是否须要调用 loadMore
const [isLoading, setIsLoading] = useState(null); // 页面级加载中
const [isPageLoading, setIsPageLoading] = useState(false); // 分页加载中
// 初始化数据
useEffect(() => {// ...}, []);
// 页面切换
useEffect(() => {// ...})
}

没有 React 根底，我形象的解释一下上述代码的问题：当初有 10 个开关，管制一个页面的渲染，这些开关并不是独立的，可能开了 A 开关，C 开关也跟着开了；敞开了 B 开关，D，E 开关也动了。这就导致一个简略的用户交互，我须要慌手慌脚的操控这些开关，让他们奥妙的配合，达到正确渲染页面的目标。

尽管过后这段代码没有 bug，然而调试和日后保护都是一场劫难。所以我就去找了不少讲 state 的文章，理解到了“繁多数据源”、“最小状态”等这些概念，也找到了更多成熟的逻辑封装库，最终改了一版代码变成这样。

const TableBizComponent: React.FC<ITableBizComponentProps> = (props) => {const {dataId, corpId, yearMonth} = props; // 年月筛选和数据 id 从 props 传入
const [selectedFilterId, setSelectedFilterId] = useState(null); // 筛选器选中 id
const {data, loading, loadMore, noMore} = useInfiniteScroll( // 分页查
(currentData: IData): Promise<IData> => {return new Promise((resolve, reject) => {const pageNo = Math.ceil((currentData?.list?.length ||0) / PAGE_SIZE);
// ...
})});
// ...
}

批改后的代码去掉了不独立的 state，引入了自定义 hook 对分页查问的通用逻辑进行封装，而这种通用封装逻辑，曾经有一些通过工业界验证的开源库能够应用，最终代码变清晰了，后续的保护难度也大大降低。

除了下面这个例子，在我的项目中我还被挪动端缩放适配的问题困扰过，只管绕了很多弯路最终发现只是一行配置没有加上，但排查问题的过程帮忙我把前端的尺寸计划，webpack，浏览器的视口、根元素、物理 / 独立像素比等这些基础知识都补齐了一遍。

在全栈化成长的初期，独立解决 3 - 5 个这类疑难杂症式的绊脚石，对本人的能力和信念的晋升都会有很大的帮忙。

Tip3 外部开发环境、工具相干的问题多问多总结，保护本人的 QA

在全栈化开发过程中，遇到语言、开源框架相干的问题时，往往能够用好搜索引擎和 chatgpt 寻找解决方案。而不同公司、BU、团队往往会有些外部开发环境、开发工具以及独有的外部依赖，这类依赖或多或少会存在文档没有及时更新或失落，找不到保护人等问题。

这些依赖呈现问题时，如果你在前端团队里，往往都是通过老带新，口口相传，或者一些外部流传的文档解决的。然而作为一个要做全栈化的服务端同学，身边没有一群踩过坑的老司机，遇上这类问题就抓瞎了。

这个阶段的问题，有时可能能够看到外部源码，还能够本人尝试解决；有时靠本人会花大量工夫走大量弯路最终也很难找到问题起因。这种时候作为全栈化同学，还是须要有一个部门里的前端大佬报下大腿，毕竟站在伟人的肩膀上能力看的更高嘛。

以我本人为例，过后我厚着脸皮加到前端团队的知识库里，每次遇到这类问题时，我都会去知识库中看看有没有前人的积淀能够解决，同时也在本人的知识库里分类做好积淀和索引。如果知识库的内容还是不能解决问题，就立即去寻求前端同学的帮忙。当我在做第一个前端我的项目的时候，是真的什么都不会什么都不懂，我切实没辙就把前端 TL 的组织架构拉了进去，对着组织架构轮流找上面几个花名眼生的前端同学轮流问问题。

尽管有些工具短少继续更新的文档，然而大部分问题都是能够通过多问多找的形式，最终找到保护人或者理解这个工具历史的人，给到解决方案或者解决思路。

作为一个服务端的同学，一些服务端的问题本人解决不了时，可能还会因为有些包袱不好意思求教他人；但作为一个服务端同学写前端时，在策略上更要拿出“我不会我有理”的态势；在战术上虚心求教，比方发问时最好简洁形容问题、带上本人曾经查找了哪些相干材料的背景信息；大佬帮忙解决完问题后，尽量想想本人能够怎么给大佬提供价值，常见的伎俩能够是将问题和解决方案总结整顿好，提供给大佬保护到 QA。

Tip4 全栈化学习里的二八定律

集中学习、集中实际对于把握一项技能来说往往是最高效的。

看到这里的开发同学或者 TL，我真挚的倡议如果想在组里推动全栈化的话，肯定要在初期争取让全栈化同学去实现残缺的有肯定规模和难度的前端需要。

在我本人的全栈化成长过程中，我在前 20% 的成长周期里摸索了 80% 的前端罕用技术，疾速造成了战斗力，可能在前端需要汇总成为独当一面的多面手。在之后的成长周期中，才是一直遇到一些疑难杂症，并在挑战这些疑难杂症的过程中持续成长，向可能把控前后端整体需要的指标看齐。

第二步：术与道——前端思维学习

对于一个服务端同学，个别走完了第一个阶段，拿到一个前端需要都可能实现。然而代码间隔优良的前端工程代码还有着微小的提高空间，往往存在短少形象，实现比拟蠢笨的问题。套用马丁福勒的话说，代码没有前端的滋味，甚至有点坏滋味。

我认为造成这个阶段的问题的起因，不是服务端同学的代码能力不行，而是服务端同学读过的前端代码太少，输出不够、眼界不够宽阔，短少对于一些编程套路、编程范式的理解，导致性能都能够实现，然而不够强壮、不够简洁、对于需要变动不够敌对。

我选了几个咱们团队的服务端同学在全栈化过程中写下的前端代码片段，在重构前后的比照作为例子。这几个例子有肯定的代表性，在重构前，它们没有语法错误，也根本能满足功能性的要求，然而重构后代码更加简洁、强壮，并且更合乎前端的编程思路，可能无效的升高后续批改和保护的老本。

误区 1 把服务端的编程习惯带入前端开发中

重构前：

const resultA = await rpc(request1);
const resultB = await rpc(request2);
if (ressultA !== null && resultB !== null) {// process}

对于服务端同学来说，这段代码几乎不能再相熟了，除了 await 这个关键字可能不意识以外，和服务端代码没有什么区别。

这段代码不能说它有问题，然而编程格调和前端强调的事件驱动、异步回调的格调不太统一。服务端同学，尤其是习惯了面向对象的服务端，写前端时常常会把本人同步编程的编程格调和面向对象的编程范式生吞活剥到前端代码中。这样的代码在前端看来就像方言，在语法和语言本身的性能上没有大的问题，但不是普通话，有一些了解老本和协同老本。

重构后的代码如下：

Promise.all([rpc(request1), rpc(request2)]
).then((results) => {// process}).catch((e) => {// process exception});

Promise 模型并不是什么新货色，可能在常见服务端语言（Java、C++、Python 等）中不太常见，然而在前端中，这个异步模型有着宽泛的应用。应用 Promise 的益处包含但不限于，

1. 异步控制：Promise 提供了一种灵便的形式来治理和管制异步操作。通过链式调用 then() 和 catch() 办法，能够更好地解决异步操作的胜利和失败状况，以及链式执行多个异步操作。

2. 并行执行：能够应用 Promise.all() 办法来并行执行多个异步操作，并在它们都实现后获取后果。

3. 更好的错误处理：Promise 能够应用 catch() 办法来捕捉和解决异步操作的谬误状况。

4. 前端敌对：在大部分前端都习惯应用 Promise 的环境下，应用 Promise 模型编写的代码，能升高了解老本。

值得一提的是，这里的异步和服务端常见的线程池异步解决有肯定的区别。js 在执行过程中其实是单线程的，它的异步由主线程和工作队列形成，在主线程闲暇的时候，会遍历队列中的异步工作执行。

误区 2 对弱类型语言不够敬畏

重构前：

fn1 = (alist) => {if (alist !== null) {this.props.myfunc(alist.length);
}
};

这段代码咋一看也没有问题，然而认真一想，myfunc、length 这些办法和属性都来的莫名其妙。

如果这段 js 代码服务端同学看完没啥体感的话，拿 python 举例大家可能更加亲切。python 的很多开源仓库晚期代码都常常被吐槽“从裤裆里掏出一个变量”，很难看进去这个变量是啥含意，什么时候加进去的，什么状况有值。弱类型语言如果没有类型零碎束缚，在小脚本中看不出差别，然而在大型工程或者须要长期保护的我的项目中，经常出现写时一时爽，保护火葬场的劫难。

前端中为了解决 JavaScript 弱类型语言的弱点，微软公布了 TypeScript，ts 作为 js 的超集，自带了一套十分弱小的类型零碎，然而为了兼容 js 的一些场景，留了 any 这样的超级类型，通过 any 能够绕过 ts 的类型查看。

在服务端开发中，咱们能够依赖编译去防止变量、办法申明前应用的谬误。而在前端学习中，一些同学可能又是从 js 开始学起，对于前端中的类型零碎应用不够纯熟，对于弱类型语言不够敬畏，导致了前端开发中呈现了大量 any 绕过编译期查看，不判断间接应用属性等问题，给线上留下微小隐患。

重构后代码如下：

fn1 = (alist: string[]) => {this.props.myfunc && this.props.myfunc(alist?.length || 0);
};

这段代码的改变很简略：通过类型申明在编译期发现隐患；办法和属性应用前减少了查看，防止因为不合乎预期的应用导致页面白屏；代码退出了更多兜底，上线后更加强壮、平安。

前端代码在业务逻辑上或者很多时候没有服务端那么简单，大部分场景就是做一些数据适配和渲染的工作，让全栈化同学在起初上手的时候感觉 so easy。然而前端代码藏有大量的细节容易被忽视，一个老道的前端和一个老手的代码的差别可能也就多了几个简略的“?”和判断，然而往往魔鬼藏在细节里，少了任何一个判断和申明，对应的都是线上的一个定时炸弹。

误区 3 代码复用全靠粘贴，逻辑和渲染耦合重大

反复代码是一种代码的坏滋味。带来的问题包含但不限于了解老本和批改老本的减少。

在服务端开发中，咱们往往能够通过提炼函数、函数上移等伎俩对代码进行优化。在前端中，如果多个页面都有有限滚动、分页查问、防抖、滚动监听等这类逻辑，应该如何复用呢。如果两个前端模块，在款式和构造上有 80% 的类似，然而又不齐全一样，要怎么解决呢？

这时很多前端老手就会祭出 CV 大法，复制粘贴稍作批改，需要就实现了。然而同时，这也是在给代码中注入新的坏滋味。

当我遇到这个问题时，我的第一个想法是，复制粘贴稍作批改太不优雅了，肯定有我不晓得的知识点能够解决这个问题。通过我的搜寻和学习，我发现前端的代码复用次要有两种，逻辑复用和渲染构造复用。

要想代码可能复用，就必须找到切面，把内聚的局部剥离，留下失当的接口进行交互。

第一步要做的就是逻辑和渲染拆散。具体到代码上，一个业务模块也能够拆分成 MVC（model、view、control）三个局部，其中蕴含了申请数据、转换数据、组装数据、编写不同渲染构造的管制逻辑、生成渲染构造几个步骤。咱们须要把生成渲染构造和后面的步骤拆散，负责渲染的组件只负责画页面，页面中的数据都是占位符，通过内部组件传入，这就造成了咱们本人定义的 UI 组件。咱们在前端开发中会用到一些 UI 库，例如 antDesign、bizChart 等，这些库的造成就是逻辑和渲染拆散思维的体现。

第二步，UI 组件的复用。有了 UI 组件后，咱们能够再看看工程中是否有其余语义和性能类似的渲染构造，能够求同存异，雷同的局部积淀到 UI 组件中，不同的中央通过减少扩大点等形式匹配。

第三步，逻辑的复用。下面提到的有限滚动、分页查问、防抖、滚动监听等逻辑有肯定的特点，它们实际上是通用逻辑，在很多页面都会用到。同时页面渲染、交互和这些逻辑之间存在肯定的关联关系，例如这些逻辑外面会保护状态、会调用页面的办法、页面须要调用这段逻辑当中实现的办法等。这时能够借助函数式编程的思维，把解决流程中不同的逻辑打包成办法，作为入参传进来，同时把内部都依赖到的办法，作为办法的出参返回进来。对于函数式组件，能够通过自定义 hook 来达到上述目标；对于类组件，能够通过高阶函数达到。

对于逻辑复用的局部，空讲可能没有什么体感，倡议读者有空能够去读一读 ahook[1] 这个仓库的代码和 demo，最好能在本人的前端我的项目中，把外面的自定义 hook 用起来，对于了解逻辑复用会有很大的帮忙。在上一节的 Tip2 中，我为了优化本人的表格应用到的 useInfiniteScroll 便是出自于此。

教训与解决方案

前端思维的积攒，必定不是久而久之的事件。于我而言，继续积攒的动机来源于对高质量代码的谋求。在全栈化中不能只满足于实现需求，而须要千方百计进步本身代码的品质，对高质量的代码做到先模拟、再发明。

为了理解更多的工程范式，找到更多能够模拟的高质量代码，在度过了“存活都是问题”的阶段后，全栈化同学更要多读一些前端代码，找成熟且绝对洁净的前端工程进行参考。

作为一个服务端同学，在初入前端时，对前端的语法和生态会产生一些“culture shock”，我在这里简略总结了一些 TS+React 生态和 Java+Spring 生态的异同，包含在编程模型、设计模式、语法等方面的相同点和不同点，帮忙大家迁徙和了解。

第三步：守好安稳底线

全栈化的最终一步还是须要安稳上线，让服务端同学写前端代码能不能按时上线？敢不敢上线？都是微小的考验。在全栈化过程中咱们发现，因为全栈化同学的经验不足，在研发阶段可能呈现排期过于乐观，上线阶段容易呈现“不晓得我不晓得”的危险等问题。

对于这类问题，咱们团队惟一一个前端同学在推动全栈化的过程中，也和全栈化的服务端同学一起踩了不少坑，总结了一些教训和教训。

排期过于乐观

首先是排期治理和对老板的预期治理，全栈化初期阶段，因为同学对前端技术栈不够相熟，边学边做是常态，须要在工夫上留足 buffer，并且 PM 也须要做好相应的风险管理，遇到卡点须要及时找前端同学染指。我倡议在一个同学开始做全栈化开发的前三个需要，排期依照失常前端排期 /0.6 的冗余进行安顿，之后逐步收敛到和前端失常排期统一。

“不晓得我不晓得”的危险

为了防止上线阶段呈现”不晓得我不晓得“这种问题，咱们建设了把关机制和工作难度进阶机制，对于一个从头开始做全栈化的服务端同学，会经验这样几个阶段：

• 业余前端做系分，全栈化同学做模块实现，业余前端做 CR 和上线；业余前端在系分编写、开发、CR、回归、公布节点把关。
• 业余前端辅导系分，全栈化同学实现需要实现，回归到上线的闭环；业余前端在系分编写、CR、回归节点把关。
• 全栈化同学独立实现需要系分、实现、回归、公布；业余前端在系分评审、CR 把关。
• 全栈化同学实现前后端需要整体闭环，业余前端在系分评审、CR 把关。

每个阶段做到没有大的纰漏，可能独立实现后，能够挑战下一个阶段的工作。通过几轮需要的学习，就能循序渐进的晓得从需要系分到公布整个过程中须要留神的问题。此外，咱们团队建设了一套全栈化认证等级，确保每个阶段的同学都在做有肯定挑战性然而危险可控的全栈化工作，做好这个等级的工作后，有明确的升级门路，去实现下一个等级更加有挑战性的工作。

这套机制具体能够参考咱们团队前端同学的文章钉钉全栈化实际总结 - 前端篇（前端初学者落地指南）。

第四步：全栈不止是前端开发

回忆我在进行全栈化之初，要解决的是团队内前端资源缓和的问题。然而从全栈化中取得的不只是前端开发的能力。一个把握了前端开发能力的服务端同学，在业务开发中就是买通了任督二脉，关上了全新的世界。

一杆到底解决问题的能力

咱们小组以后做的业务是钉钉智能差旅，须要把市面上各类出行服务商和商旅服务商的机票、酒店、火车票、用车的服务能力接入到钉钉当中。对接的过程波及到服务端的接口交互和前端的页面交互。

以往这类对接须要拉上两方的前端、后端、产品、PM 等一系列角色到一个群里，进行对接和联调，过程中如果波及到其余一方能力提供方的问题，也须要把相干方拉到群里沟通。整个协同链条比拟长，两头常常会呈现“无能为力的传话筒”。在具备解决前端问题的能力之前，遇到前端问题时，我就是那个可怜的传话筒。

例如在和美团的对接过程中，遇到了在美团的钉钉小程序的订单下单页面拉起支付宝收银台闪退的问题。这时候须要懂钉钉的领取 jsapi 的前端，懂领取接口的服务端，会定位容器层问题的同学一起进来排查。整个排查过程存在着大量的协同老本。

这时候，具备全栈化能力的服务端同学，一个人就能合乎下面所说的这些要求，能够整体收口整个对接工作。我通过和美团侧前端同学的沟通，结构出最小可复现问题的 demo，并和容器同学一起定位了闪退起因，最终解决了问题，缩小了大量沟通、协同的老本。

这种一杆到底解决问题后的酣畅淋漓，是我把握全栈化能力后播种的意外之喜。

前后端全局视角

差旅业务积淀了组织大量的出行数据，剖析这些数据对帮忙管理人员决策有着肯定的帮忙。在智能差旅的报表需要中，我牵头了整个报表模块的前后端系分。

对客报表的需要自身不算简单，它的特点是图表数量多，每个图表的业务流程比拟相近，因而咱们心愿一套前后端计划满足所有不同类型的图表的取数、数据处理、数据渲染。具体而言，咱们的计划是用一套 schema 定义图表，服务端提供一个对立的接口，依据 schema 进行数据获取和组装；前端依据 schema 渲染特定的图表类型并填充数据。

这套计划挺好，美中不足的问题有二：前端和服务端别离须要去了解一遍整套 schema，并且图表中的字段多，前后端的每一个小调整都须要来回对焦，减少了协同老本；每种类型的图表都是一个前端组件，前端的工作量比服务端大，在前端资源缓和的状况下，前后端排期不匹配的问题加剧。

咱们对此的解决方案是：

• 我作为一个全栈化同学负责整体前后端的系分，并在开发中次要承当前后端 schema 解析相干的局部，对其余参加开发的同学尽可能屏蔽 schema 细节；
• 一部分全栈化同学分到具体的图表组件的前端开发工作，并行的实现不同图表业务组件的开发；
• 团队里惟一的前端同学负责把控前端性能问题和稳定性相干的难点问题；

基于上述计划，咱们通过团队的全栈化，解决了前后端排期不匹配和协同老本高的问题。在牵头前后端的整体系分过程中，无论是可行性还是工作量，我都可能较为精确的设计和评估，这都是得益于之前积攒的全栈化的能力。

全栈化的不止是前后端

作为一个业务开发同学，相较于后端研发这个职位定义，我更喜爱亚马逊 SDE 的职位表述，Software Develop Engineer，业界戏称 Someone Do Everything。

当初因为前端人力的紧缺，咱们团队迈上了服务端全栈化的路线，并在摸索后发现，把服务端开发人力和前端的开发人力放在一起做资源布局，让服务端实现日常前端开发中 80% 以上的工作齐全没有问题。不仅资源瓶颈问题失去的了解决，团队里开发同学也拓宽了能力边界。

理论在业务推动过程中，咱们可能会遇到各种资源的瓶颈，可能是数据分析的排期不匹配，可能是算法反对的排期不匹配等等。对于开发同学而言，无妨联合本人的趣味点想一想是否向前一步，成为团队的多面手，帮忙团队解决资源瓶颈，施展本人不可代替的价值。

作者|鞍点

点击立刻收费试用云产品 开启云上实际之旅！

原文链接

本文为阿里云原创内容，未经容许不得转载。