作者：字节跳动终端技术×ByteTech

嘉宾介绍：娱乐圈有艺人"歌红人不红"，文学界也有作者"笔名胜原名"。提起吴亮，大家可能更熟悉他的网名——月影。月影是前端开发领域当之无愧的技术前辈，同时他又是扎根社区、心系社区的开发者。

2004 年刚毕业，月影以管培生的身份加入了一家传统的软件公司——金蝶软件。因为是半年轮岗实习制，他先后接触到售前、售后、开发等不同岗位。半年后回到总部，月影开始了自己的编程生涯。他回忆说："回到总部的信息管理部门以后，我有机会参与到公司后台的 MIS 系统开发。虽然现在听起来没什么特别之处，当时却是一个先进的概念。因为这个系统里有很多复杂的交互，没有'前端开发'去解决，我就抱着尝试的心态，第一次接触并开始学习 JavaScript 。"

那时，国内还没有前端开发这个行业。凭借对产品界面交互的兴趣，月影开始系统地学习 JavaScript，成为国内比较早的前端开发者。

我接触编程比较早，但是之前写的比较杂。在学校里、实习的时候用过 C、 C++、C # ，也写过 PHP ，但没有写过 JavaScript 。第一次接触 JS 后，发现自己对前端的 UI 挺感兴趣。所以从 05 年开始，正式成为了国内比较早的一批接触前端的程序员。当时在一些技术社区，我也会做分享和交流。

2008 年月影来了北京，正式开始带前端团队。

后来十几年的工作中，月影大部分的时间里都在做前端开发和技术团队的管理。除了日常团队管理外，也做一些前端相关的技术、研发项目和开源框架。

我觉得我自己其实算是一个 JavaScript 程序员，平时空闲的话还会写写代码。之前做的开源项目，公司里面也有一些其他的团队在用，所以也会偶尔帮忙改个代码。

技术中台前端团队：降低企业成本，为业务团队 赋能

月影目前在字节跳动技术中台前端团队，部门定位是中台，所以会有搜索、游戏、用户中心、国际支付、技术社区、用户增长等业务方向。在这样一个中台团队的背景下，支撑业务部门提效、降低企业成本是团队重点关注的方向。

虽然业务特点不同，但共同点是需要给业务赋能；我们更多的会考虑如何去赋能，考虑我们的工具对业务的支撑能力，这是更多会去考量的。

作为中台前端团队，与业务线中的团队分工难免会有些重叠。如何避免重复造轮、高效推进成果产出也是中台团队必须要思考的问题。

如果说一些团队和业务，它还处于孵化期，那我们中台会更多地深入到业务一点儿。但如果说这个业务团队处在一个成熟期的话，我们其实更多地是提供流程工具和一整套解决方案的支持。更多偏业务的东西，还是会闭环在业务里面去实现，所以这个其实是一个相互配合的状态。

我们中台这边也会提供一些相对通用和完善的产品，这些技术性产品可以帮助业务更好地达成业务目标，以更低的成本去试错。

除此之外，如何让中台团队发挥更大的价值、赋能更多业务团队降低成本，月影也有自己的想法。

我们的基础设施是贴着业务走的，像搜索、用户增长，从底层连接公司内部基础架构的团队，用已有的基建能力，去做贴合业务需求的基础设施。

但因为团队比较大，业务方向和场景比较多，我们需要考虑如何与业务团队的能力横向打通，把适用于业务团队的通用能力抽离出来，并且打磨得更好、支持更多的业务。

字节内部使用的搭建平台，有基于配置化的搭建、低代码的搭建、无代码的搭建。配置化的搭建比较适合于给研发团队使用；低代码搭建可能适合于产能的团队，无代码搭建的话，就会更适合运营同学。

虽然它们已经是一套完整的体系了，但我们期望在丰富的场景中，把它做得更完善一些。因为包含内部场景以及 to B 的外部客户需求，我们提供的底层代码搭建的能力是可以更抽象、更完善的，能够适应不同的业务场景，在各业务线上去提效。

我希望这些工具能够真实地帮助业务效率提升、改善质量。与此同时它本身足够完善，能代表整个行业发展最先进的技术。在未来的话，我们可能会把这些能力通用化，甚至考虑开源或 to B。

对前端开发者的思考：永远保持敏锐度和好奇心

字节文化里面有一条叫"多元兼容"的团队理念。每个组织一定是多元化的，没有统一的标准去衡量每一个候选人。如果每个人都能发挥他的长处，团队才会发展得更快更好。

带着这样的理念，月影会从业务规划能力、技术规划能力、管理成熟度思考团队的管理与建设。

所谓的业务规划，就是要关注业务的发展、讲清楚业务的未来发展方向和整体前景，以及它当前急迫需要解决的问题和面临的挑战。要理解背后的逻辑，从技术侧去思考如何改进业务。这样，在处理问题的时候，才会更有前瞻性。

第二是技术规划。当清楚业务规划后，相应也会知道业务在未来的挑战点，所以需要思考有哪些可以通过技术或者通过技术储备来解决的，同时就会把业务规划转化成团队对应的技术规划和技术挑战。

比如某业务在未来计划会发展到多个平台，那在初期的阶段，就需要把技术投入到研究跨平台、跨终端的这些方面。而不是当团队要做小程序版 App 时，发现团队没有小程序开发的经验，这肯定是不行的。

所以，我们需要基于业务去做一些技术规划，在技术规划的过程中看到技术挑战点。当前用的这些工具和框架，在这个跨端能力上有什么限制，有没有好的解决方案。因此，不一定说技术能力要多好，要多深，但一定要有这方面的敏锐度和前瞻性，能够提前去看到这个业务发展中，给团队带来的一些技术挑战，然后提前布局。

第三个是管理成熟度，思考团队多元化的发展方向以及未来的成长空间。作为团队管理者，你需要为团队里每一个同学规划他未来一年到两年的成长路径，并且了解团队成员整体的诉求是什么样的，怎样把他们个人的诉求和公司对他们的要求和发展结合起来，能够让他们更长远地陪伴这个团队，陪伴这个公司走得更远。像这样的问题，是需要偏管理层的成员去考虑的。

对于专家型的角色来说，他除了在技术上有一定的深度，也能在技术规划里面承担比较核心的角色，能够敏锐地看到业务发展的趋势，然后去做好技术储备。

我发现一些 IC 角色经常会犯的一个问题，就是埋头研究技术，不懂得合作。个人的力量是有限的，其实一个人是需要能够更多地影响整个团队，带动团队里的其他人的。他要能指导不同职级、不同方向的成员更好地成长，这样的价值就会比单纯埋头做事情的大很多。

你会发现说，这些高阶的成员不管是技术方面还是管理方面，抑或是软素质方面表现得都很好。比如说，会沟通、能指导，能够意识到做这些事情的重要性。

就新人普遍提到的「行业发展速度快、新技术越来越多，学不动」的问题，月影也在采访中给出了他的想法和方法论。

首先我们应该更乐观地看待这个问题，行业发展得快，说明成长空间或者技术发挥的空间更大，所以大家不用太盲目地去焦虑。

同时，我们也应该更加聪明地去看待这些问题，思考一下哪些东西是需要学的？有些知识属于基础知识，相对而言变化的没有那么快，比如很多算法，在很长一段时间内都是比较稳定的。这些对于前端或者其他领域来说都是很有帮助的，所以我们的基础需要打牢并且做得更扎实。

另外一块属于领域知识，当中又分成了通用的领域知识和专用的领域知识。通用的领域知识，最好提前去学习掌握。 现在，我们有很多项目都是用 TS 去写的，所以它属于通用的领域知识，需要成员去把 TypeScript 给学习好。

还有一块属于专用的领域知识或工具，比如说你要做工程化、工程打包，你去学 Webpack 或者是 Vite ，这就属于专业领域知识，不用提前投入很大的精力，因为他们其实就是工具。所以，当项目里用到 Webpack 打包的时候，再去学习就可以，即便日后把这些知识忘掉了也没关系。大家不用担心，行业今天用 Webpack 明天用 Vite。这些知识本来就不需要提前去学，等到用到的时候再去边学边用就好了。

前端的很多知识是属于这类知识的，所以不用太恐慌、太焦虑。他们的出现其实对这个行业也会有很多积极的作用，能促进前端整个行业的更好发展。所以，我其实还是挺乐见这些新工具的产生。

扎根社区，做一个懂社区的前端开发者

作为最早一批的前端从业者，月影完整经历了互联网技术社区的变化。从最早在 51JS 社区和前端前辈探讨技术、碰撞思想，到后来深度参与 CSDN、博客园、开源中国等社区生态共建，以及现在他亲自规划稀土掘金社区的未来发展，月影俨然是一位对社区有着深入见解的前端开发者。他希望技术社区可以成为一个有归属感、有温度的社交圈，其中的每一个技术人都能快乐地成长。

51JS 其实是一个传统的 BBS 网站，大家更多地把论坛当做日常沟通和讨论的平台。当时也产生了很多非常先进的前端思想，非常超前，可能五年、十年之后才以比较成熟的技术形式呈现出来。我们跟一些前端的前辈，比如像 Hax 、周爱民，都有过非常激烈的思想碰撞，甚至有过一些争吵。当时的技术论坛非常活跃，大家对 51JS 也有很强的归属感。后来，随着程序员规模的扩大，在 51JS 这样的传统社区，感觉人与人之间的距离没有那么近了，也没有当年的感觉，大家就逐渐不太去使用它，于是就慢慢没落了。

之后，也有更多不同类型、不同调性的技术社区涌现了出来。CSDN 的核心是内容，沉淀的时间长，因此沉淀的内容很多，里面有大量偏技术类的内容，所以很多人把 CSDN 当做内容的消费源。一个小白开发者，如果在工作中遇到了问题，在百度或 Google 上一搜，第一条就是 CSDN 的内容。这个内容不一定很深入，但照着步骤去做，可能就解决了工作中的问题。但这也是 CSDN 的瓶颈，内容多但相对初级，且依赖搜索引擎。更直接一点，它的流量是搜索引擎带来的，这波用户消费完内容就走了，并不会对社区产生忠诚感和归属感，也不会对社区的社交产生有价值的贡献。

开源中国是做开源方向的。我觉得开源其实是一个很重要的方向，从政策上看，国家也非常重视开源，第一次把开源写进五年规划里。因为现在是一个开放的行业，开源生态几乎等同于整个开发者生态。

2015 年，我开始关注稀土掘金，这个社区更多地聚焦在内容和社交的深度。能把这块儿做好的社区，目前看还是比较少的。如果你是核心用户，应该可以感受到掘金对用户价值的关注，一个是内容的质量，一个是社交的深度。我自己是技术社区的资深用户，会希望建立起一个大家有归属感的社交圈，满足日常职业成长和学习的诉求；也希望通过社交，能让做技术或者热爱技术的人快乐成长。

谈到稀土掘金未来的规划，月影反复提到"用户价值"这个词，他说不是所有的工程师在早期便足够优秀，我们希望跟他们一起成长！

虽然说刚刚提到的很多社区都在考虑做 to B，稀土掘金未来还是会比较坚持地去做 C 端用户，做好用户价值，而不会偏向于做用户规模。我认为一个社区应该能够对这个行业有所帮助，最好的方式就是能帮助从业者更好成长。当从业者成长后，反过来又能帮助社区成长为更好的社区。所以，在未来一年里，我们会去做会员权益体系，让稀土掘金成为一个好的开发者平台。不是所有的工程师在早期就足够优秀，有足够大的平台来实现自我成长，还有许多人可能学校不是那么好或者当前阶段技术实力还没有那么强，他们可能去了一些小平台，但他们其实也有成长的诉求。稀土掘金能成为他们职业发展的平台，能够像一些好的团队、一些好的公司那样，真正给他们的职业成长带来帮助。这就像带一个技术团队，在团队里找到那些高潜能的成员，更好地去辅导和帮助他们成长。对于社区来说也是一样的，找到社区里面高潜能且愿意学习、有职业成长诉求的用户，量身定制适合他们的成长路径。

对于技术沙龙，月影觉得更多的是向有经验的人请教来解决职业发展的困惑，一年参加一到两次技术大会对扩大视野也会有很大的帮助。

如果项目中遇到的一些特别具体的问题，可能还是看书学习、问问同事，或者去网上找答案比较好。在沙龙里面，更多还是解决职业发展的困惑。比如说，究竟是往技术深度发展好，还是往广度发展好？比如说，在未来的半年到一年里，想提高自己的实力，但是不知道自己该朝哪个方向努力？该学什么东西？如何平衡好项目和学习的关系？

就技术大会来说，一种是综合型的，大会中的每一个专场，可以认为是一个比较垂直的沙龙，那些内容能够去解决一些你的困惑和问题。另外一些大会偏向于商业推广，里面会有很多广告，像那样的可以适当减少关注。因为现在各种大会比较多，很难知道哪个好，哪个不好，所以大家可以仔细辨别一下，如果发现这个会太水了，记一个黑名单，下次就不要去参加了。

其实，我还是很鼓励大家去参加这种高质量的大会，不用太多，一年两、三场就可以，对自己还是会有一些帮助的。我们最近也在筹备"稀土开发者大会"，今年是第一届，比较偏向于干货分享，比较偏向传统的综合类技术峰会，我们会邀请行业里面比较厉害的讲师来分享技术干货。未来的话，我们还是想办的有特色、有差异的大会。稀土掘金社区除了专注于技术交流的干货内容以外，也会增加更多的社交内容，比如一些线下的游戏、嘉年华等这样的综合类大会。

技术影响力的思考

来字节之前，月影除了管理技术团队，同时也在做技术团队影响力的工作。月影说："即使像奇虎 360 这样的互联网公司，也需要在技术影响力上投入精力。所以，如何吸引招致更多优秀的候选人，是技术品牌需要长期投入去做的事情。我们会发现这是一件有长期收益和长期价值的事情，所以慢慢总结了一些经验。"

对于他本身而言，月影认为"技术影响力建设"是一件很有挑战的工作。随着技术招聘标准的提升，招聘需求的增加，整个技术团队的影响力建设显得尤为重要。

因为字节的业务发展很快，招聘候选人受业务本身的影响更大。有些候选人会优先考虑发展较好的业务团队，但是技术中台也有独特的优势——支持的业务产品比较多，技术沉淀和发展空间也会更多。所以业务团队要一方面看到自身发展的核心优势，另一方面把这些梳理出来，成为竞争力对外推广。

另外，我希望也能从培训角度切入，做一些前置的人才培养工作，从而缓解招人压力，补充人员缺口。这个论点其实已经验证过了，所以我也希望把这些好的经验给搬过来。拿前端来说，对于一些想要从事前端工作的学习者，可以通过 ByteTech 推出的"青训营项目"学习一部分课程，进入招聘环节。

不论青训营项目，还是新媒体运营工作，我们的目的并不是封闭地去做技术中台的前端影响力，而是更开放、更全局地考虑整体字节前端的问题，打好字节前端这样的品牌，才能有更多优秀的人加入。依我看来，目前各个业务团队都在积极争取市面上现有的人才，大家不如一起把这个蛋糕做得更大，然后吸引更多的人，培养更多的人。

字节跳动应用开发套件MARS是字节跳动终端技术团队过去九年在抖音、今日头条、西瓜视频、飞书、懂车帝等 App 的研发实践成果，面向移动研发、前端开发、QA、 运维、产品经理、项目经理以及运营角色，提供一站式整体研发解决方案，助力企业研发模式升级，降低企业研发综合成本。