我一直都是在写技术方面的，从来没有想过会写一篇跟技术无关的文章，因为在我看来，这样的文章完全是虚假和空洞的。

技术第一？

三年前，我毕业加入了第一家公司。糟糕的技术水平经常让我在实际的开发工作中感到力不从心，于是想着尽快提高自己的技术水平。每天在公司呆到很晚，除了做需求就是自学。在这种情况下，我能坐在电脑前的时间几乎都花在了技术上，这就导致了我只关心技术而忽略其他东西的后果，而且越来越严重。

在需求的时候，我不在乎PM想要做什么，也不关心这个需求的目的是什么，更不在乎它是不是一个不合理的需求，我只考虑如何在技术上把PM的要求实现出来。不管这个需求有多复杂，多不合理，我都要用我的技术手段去实现，我甚至为此感到自豪，觉得这是一种体现我个人能力的方式。有时候，我的team 因为一些实现起来比较复杂，主动告诉我一些简单的实施方案，我心里反而有些鄙视，觉得team 太古板了，什么复杂的需求不存在的？再给我一天时间，我就能帮你实现。

我相信很多技术朋友都有过类似的想法，但三年过去了，回头想想，我现在更想学一些跟技术没那么紧密相关的，比如商业

技术还是商业？二者相辅相成

我曾经以为技术和业务是两条不相干的路，如果把更多的时间花在业务上，那么花在技术上的时间就会更少。与其同时专注于技术和业务，做出两个 50 分的成绩，作为一个技术人员，我不如专注于技术，争取做出一个 100 分的成绩。但事实上，这种想法有些天真。

首先，除非你天赋异禀，否则很难在一件事上做到 100 分，甚至 80 分。其次，技术和业务并不冲突，花一些时间在业务上并不会减少你在技术上的投入，相反，两者是相辅相成、相互促进的，1+1 大于 2。

因为能找到业务的痛点，所以想用技术去解决。有明确目的的学习和尝试，必然会带来更高的效率。因为技术足够强，所以能解决更大的业务问题，获得更大的成就感。

如果你自己没有主动做业务，而是被业务方驱使，这种行为只是搬砖而已。相反，如果你推动业务向前发展，让业务方因你而改变，那你就是在赋能业务。

我经常看到一些有三五年工作经验的前端开发者很迷茫，他们知道自己已经走到了尽头，但不知道下一步该怎么做。于是他们开始尝试改变，但他们走的路可能并不正确。比如看到一个东西很流行，就去学；看到它可能有前途，就去学；甚至有人去学 Java/

并不是说这些尝试新事物的行为不好，恰恰相反，这是非常好的。敢于尝试、勇于行动总是值得鼓励的，但一定要明确做这些事情的目的，考虑ROI。比如你看好未来的发展，计划以后投身到这个领域，那么可以先自己学习一下，为以后加入一个团队打下良好的基础，甚至可以在自己的团队内部做好晋升的准备。这显然是正确的想法。

但如果你只是觉得现在的工作到了瓶颈，觉得大家都在吹牛，自己也反正不知道该做什么，那就顺势学点东西吧，说不定以后就派上用场了，到时候你就能一鸣惊人了。其实这种想法有点跑偏了，学习新东西确实能给你带来新鲜感和成就感，但这并不能解决你现在工作瓶颈的问题，你只是选择逃避而已。绩效考核不会因为你学了点东西就给你，除非你的团队真的在用，你也参与其中，做出贡献。

同样，作为前端开发者，如果懂一点 Java/Go，是不是会更有竞争力？我的答案是，总比什么都好（懂一点当然最好，不懂也可以）

毕竟你是前端开发人员，如果面试时连前端开发人员的基本知识都答不出来，背源代码还有什么意义？如果你能流利地回答基础问题、算法、项目经验，还能和面试官谈笑风生，谁还会在乎你知不知道什么是高并发？

扩张障碍

技术的路可以很宽广，但对于大多数人、大多数场景来说，真正能用到的技术只有很小一部分，尤其是前端，技术含量比后端、算法要低，更看重技术的广度而不是深度。

一个入行三五年的C++程序员可能还会写出有语法错误的C++代码，但在前端这种情况很少发生。一个勤奋的毕业生，毕业半年后应该不会写出有语法错误的前端代码。Bug基本都是业务逻辑的Bug。一个有五年工作经验的C++程序员和一个只有一年工作经验的C++程序员，技术水平可能有本质的差距，但如果换成前端程序员，很可能两人的技术水平不会相差太大。

但显然，即便是前端程序员，我们一般都认为有五年工作经验的比有一年工作经验的要有能力，两者的技术水平可能相差不大，但差别在于其他方面。

技术广度？

可能不会。技术宽度越宽的人在技术选型时可以有更多选择和组合，但这种能力并不是必不可少的。一个公司在团队合作时，很少会因为技术栈的选择而感到困惑。你可能因为在行业里混了很久而学到了更多技术，比如、、等等，但这些更多的是让你具备切换技术栈的能力，而不是提升你整体的技术实力。如果你的公司不使用、、，那么你知道这些也没多大用处，也没人会在意。

如果你的公司真的只用到这几项技术怎么办？抱歉，这些都不是很难的事情。技术没有循序渐进这回事，你给一个刚毕业的学生一点时间，他就能学会。一般来说，一个部门或团队不可能用到很多技术栈。技术的广度达到一定程度之后，继续增加的意义只会越来越小。

是技术深度吗？

钾

但这很难。就像我之前说的，除非你真的很擅长技术，否则你很难有机会再深入，尤其是在前端领域。在 99.9%（小数点后可能还需要再加几个 9 才算现实）的场景中，你不需要考虑任何深度、性能或优化。我实在想不出有什么前端工作场景会需要在编译层面或操作系统层面实现技术突破。

制作（注意：是制作，而不是使用）一个小程序什么的这种程度的东西，对于前端技术的确是一个很大的考验，但是大多数人都与这些无关。

如果真的需要深入到底层，比如编译层面或者操作系统层面，这个就不能再称为前端开发了，而能深入到这个层面的技术人员也不太可能是前端开发人员。

工作经验？

是与否

如果你工作三年，三年只是一步一步地搬砖，那么你可能只是把一年的经验重复了两年。

真正好的工作经验应该是不断学习和进步的，而不仅限于技术进步。如何写出易于维护的代码，如何用技术能力保障业务稳定，如何引导新人快速融入团队，这些都是不可或缺的东西。这些能力的获得需要时间，也需要你主动的探索和实践。这些是无法快速实现的，也是你作为技术老手真正能拉开与应届毕业生差距的地方。

无论他们的技术水平、技术广度、工作经验如何，他们的价值最终在于服务业务的能力。因此，一切都围绕业务展开。既然无法避免，那么尽早学习游戏规则也是理所当然的。

什么是商业

在最初的三年里，我经常听到资深同事提到“业务”这个词。我想学习更多，但总是觉得太模糊了。编程语言的语法、关键字、设计模式、算法我都能看懂、会用，但业务到底是什么？怎么学？如何关注业务？

反正我很苦恼，一直有人跟我讲生意，我却不知道从何下手，试着模仿，但最后只学到了最基本的东西，于是渐渐放弃了。

我目前所在的第二家公司的团队，业务压力比以前大了很多，我几乎不可能再像以前一样悠闲地做自己的技术研究了。不过在这样的环境下，我对业务的理解反而加速了。我也理解了为什么那么多人跟我说业务很重要，但是没有人能教我什么是业务，因为真的很难解释清楚。也就是说，其实每天都有人跟你讲业务是什么，但是因为你自己听不懂，所以就觉得他们什么都没说。

大多数情况下，技术是用来服务业务的，这句话有两层含义。

第一，技术的唯一目的是支持业务

第二，业务不单单靠技术来支撑，还包括很多方面。

业务是一个商业公司的命脉，技术只是支撑业务的关键之一，所以业务确实很重要。

那么，业务是什么就很容易理解了，你的技术是服务于业务的，一切能够让业务蓬勃发展的正向能力（包括但不限于技术能力）都是业务能力。

前端如何赋能业务？

肯定会有人抱怨我说了半天什么都没说。是的，确实如此。对于还不明白什么是生意的人来说，别人再怎么讲，也很难理解。对于已经明白的人来说，生意就是生意，没什么好说的。也许你真的需要自己去理解。也许有一天你会突然明白。

很难清楚地解释“商业”这个词是什么，但工作中无处不在。

前端如何赋能业务这个话题挺大的，但是具体的例子也很多。

自动构建操作页面

运营手段对于C端产品来说非常重要，运营迭代的速度也是影响产品发展最直接、最实际的关键因素之一。比如天猫的618建站活动、美团的全场减价活动都是非常常见的运营手段。几乎任何一个直接面向C端用户的产品都离不开这些。

这些运营活动往往需要前端用户的各种玩法，可以说是比较依赖前端的业务了。那么作为一名前端开发工程师，如果你的目标仅仅是实现业务方提出的具体运营要求，那当然是合格的，毕竟你尽到了自己的职责，但可能还不够。

想出一个运营页面，就做一个，想出两个，就上线两次，难度不大，但避免不了要走整个开发流程。于是聪明的人就想，能不能把这种固定路径的搬砖行为自动化，于是运营页面自动化构建的概念就出来了。以后运营页面的开发上线，不需要研发参与，直接操作就可以，快、稳、好。过去一个运营活动，需要评审、调度、开发、验收、上线等多个流程，现在简化到只有验收、上线两个节点，大大提高了生产力。这就是业务的成功赋能。

所以，你可以做什么？

业界有很多知名的自动化运营页面构建项目，比如阿里云、阿里飞兵等，但这些可能并不完全适合你的公司，因为运营页面和具体业务强相关，特别是C端，业务场景不同，运营页面自然也不同，如果你的公司没有这样一套自动化运营页面构建的工具，业务又高度依赖线上运营，那么这就是你的机会

移动端已经成为主流，前端开发主要集中在APP、M、小程序上。小程序端又可以分为微信小程序、字节小程序、百度小程序、支付宝小程序、快应用等等。如果针对这些终端都专门开发一套代码，显然会形成大量的人力需求。如果把这些终端都做起来效果是1+1等于2的话，还算可以，但现实肯定是1+1小于2。如何以最小的成本覆盖这么多的渠道，是一个非常迫切的事情。

因此多端适配方案应运而生，大大提升了开发效率，不仅快速、良好地完成了一套代码在多个地点运行的任务，还间接为公司节省了不少研发费用，其价值毋庸置疑。

所以，你可以做什么？

像Taro这样的多端适配框架确实适配了很多东西，但都是开放的东西，比如微信小程序、字节小程序等，这些都是开放的开发平台，但是你公司开发的APP，比如抖音APP、支付宝APP，肯定有一些私有的协议，比如调出APP、打开页面、调出相机功能等，这些私有协议一般是不对外开放的。如果想让一段代码不仅能在小程序、M端跑，还能在APP端跑，那么APP的适配能力显然需要公司内部员工来完成。

元件库

即使在前端刀功时代，这种类型的前端框架也曾风靡一时。在前端组件化盛行的现在，各种前端组件库层出不穷，本质上都是为了提高开发效率，一些通用的UI和逻辑，开箱即用，作为开发者，只需要关注业务逻辑即可。

但并不代表 ant- 之类的组件库就可以横行了。对于 PC 后端项目来说还可以，但如果是移动 C 端产品，在组件库的选择上就需要谨慎很多了，尤其是那些知名度高或者场景比较鲜明的产品，对风格要求更高。而广泛使用的开源组件库未必能满足要求。比如支付宝和微信，显然都有自己独特的 UI 风格，一个开源组件库不可能专门去适配某一个产品的风格，否则就失去了通用性。而支付宝或者微信等特定 App 也不可能为了省事，放弃自己的风格直接使用开源组件库。因此，打造一个属于自己的专属组件库就成为了理所当然的事情。

其实用户量稍微大一点的C端产品，都有专属组件库的需求。所以如果你公司的业务场景主要在移动端，发现没有专属于你公司的组件库，那么不要犹豫，赶紧做。这么明显的事情，你不做，迟早会有人做的。

其他的还有很多，比如脚手架，国际化，工具函数库等等，都是有实际需要的东西。

前端如何参与业务

在大多数公司，PM 通常负责主导产品，前端开发人员毕竟是开发人员，试图在产品层面与产品经理竞争，就像业余爱好者挑战专业人士一样，既不适合，也不太可能成功。不过，这并不意味着开发人员完全不能参与业务。PM 当然比你更深入地掌握整个产品的整体情况，但在某些细节上他们可能并不比一线开发人员更清楚，而细节往往体现在具体的需求上。

需求通常是产品提出来的，但往往需要开发才能实现。产品需求的目的就是为了实现这个需求，重在产品层面，目的性强。开发层面的东西还是需要开发来评估，所以这个空隙自然就是开发参与业务的机会。

发出请求

提需求并不完全是 PM 的特权，开发人员也可以提需求，业务需求可能没那么容易提，但技术需求却是开发人员的专利。

作为前端开发者，你一定要关注自己做的前端页面的一系列指标，主要关注性能、交互、样式三个方面。页面加载是否快速、交互是否流畅、样式是否舒适统一都是需要时刻关注的点。有问题要主动解决，而不是等着PM来找你，这是技术问题，你要负责。

所以你可以大大方方的提出技术优化的要求，我不能保证流畅的页面会让用户更加忠诚，但是糟糕的页面一定会让用户离开（除非你是银行网站）。所以技术要求表面上是技术要求，其实也是出于商业的考虑。

需求可大可小，比如统一风格，或者大到可以构建一个前端技术项目。

比如一个产品想通过不断迭代运营活动来维持用户活跃度，那么他只希望开发人员能够按时完成运营页面上线，他并不关心开发人员怎么做，只要产品目标达成就可以了。

作为前端开发人员，你意识到操作页面可以做成可配置的，那么就需要和PM讨论一下，这种做法是否可行，后端如何配置，需要预设哪些模板，需要预设哪些页面能力，数据存储的形式等。

再进一步，你可以继续跟产品确认这些运营活动未来是否有可能在多端落地，如果是的话，那么还需要考虑多端兼容的问题。

看上去这本来是一个很简单的运维活动，没什么难度，工作量也不大，一个刚毕业的学生一天就能搞定，然后你以开发人员的身份介入其中，强行把这个需求拆分成几个大项目，看上去是在自找麻烦。

确实，有些人擅长无中生有，整天做一些看上去很宏大但实际上毫无用处的事情。但不要以偏概全。无中生有并不一定是贬义词。如果确实需要运营搭建后端、多端适配，那这件事情迟早是要做的。如果你能提前看到这一点，提前做好准备，就能保证业务的顺利过渡，这也体现了你的工作经历的价值。

减少需求

PM提出的要求不一定合理，一个负责任的技术员应该对要求有一定的判断力，对不合理的要求坚决说不。

这里的重点不是给PM的工作挑毛病、人为设置障碍，而是提供更好的洞察，共同承担业务的责任。

比如你和产品事先约定好了方案，在某个具体功能上，产品发现数据不符合预期，就希望你针对这个功能开发具体的逻辑，来改善数据。这或许确实是可以的，技术上也不难实现，但作为开发者，你也要对整体的技术方案负责。约定好的方案，针对某个具体功能增加额外的逻辑，会不会损害整个技术方案？会不会因为一点小损失，造成长期的负面影响？还有其他更好的方案吗？

看上去你是在推卸责任，但是如果你的出发点确实是为了项目，你的理由也足够有说服力，谁能说你是在推卸责任呢？

能够合理的预防不合理的需求，把有限的人力和时间花在更重要的需求上，才能更好更快地推进业务。

只是前端吗？

很多人说后端比前端更贴近业务，理论上好像是这样，但我的看法是，具体到个人，还是看自己的态度。如果后端只是日复一日的CRUD，既不主动去了解业务，也不去赋能业务，那贴近业务还有什么意义？同样，如果前端只愿意当个切图员，就算每个需求PM都特意跟你讲清楚也没用。

所以还是要看个人的主动性，除了技术之外，要主动看更多的东西。我不是要求你一行一行的看后端代码，当然有时间也可以看，但是没必要。业务代码不好看，反而看得头疼。业务是从一个需求到另一个需求迭代出来的，所以想看懂业务，还是从需求入手吧。

PM提了一个需求，你不仅要关心需要切哪些图、用什么风格、前端用什么组件等技术问题，还要了解PM为什么提一个需求，这个需求解决什么问题，涉及到哪些业务问题，比如上下游关系等。

当你和后端约定好接口字段的时候，你不应该只关注后端返回给你必填字段，还要考虑更多的东西，比如接口是否可复用，字段是否冗余，是否需要对接口进行拆分或者整合，前端如何保证当接口出现故障的时候，页面依然是用户可以接受的。有些事情可能是后端应该做的，但是你无法保证每个人都会尽职尽责，所以你可以多关注一些事情。

在需求评审的时候，PM 会更频繁地征求你的意见；在接口约定的时候，后端更习惯你来制定接口规则；当你关心的东西越来越广泛的时候，这个时候，你还觉得前端只是一个切图工具吗？

如果你成为最熟悉业务的人，那么团队其他成员遇到不懂的业务问题时，第一个想到的肯定是你，那么你在这个团队中就有了实质性的价值，不容易被取代。

我们应该注意什么？科技是生活的基础

我说了那么多关于业务的重要性，可能会让一些人产生误解，觉得如果这样，那我就不干了，干业务就好了，因为技术好像本来就不重要。

这种想法也是错误的，既然你是一个技术人员，技术就是你的本职工作，也是你事业的基础，如果你想拓展更多的领域，就必须先打好基础，如果你连技术都不懂，还想做业务、做管理，那可能最后什么都做不了，只能是一盘散沙。

那么我们该如何平衡两者的关系呢？

对于前端行业，我的建议是，在最初的两到三年里，应该把更多的精力（至少80%以上）投入到技术上，保证在两到三年内，前端的技术水平能够达到合格的状态。

什么是合格状态？量化地说，就是你有 80% 以上的把握，可以回答网络上正常场景下的任何前端面试题，可以满足工作中提出的任何前端要求，可以保证自己写的代码项目的稳定性和可扩展性，可以快速上手前端领域的新技术并理解其原理。对于大多数人来说，这应该不难。

然后，剩下的20%用来聚焦业务。注意是聚焦业务，参与不参与并不重要，因为工作经验不足两年的菜鸟，对业务没有太多的发言权，思维也还不成熟。这个阶段更多的是观察，观察业务是怎么运作的，观察其他更高层级的人是怎么参与业务的，借鉴他们的优点，然后形成自己的思维理念。

经过两到三年，你升职了，在团队中的地位也略有提升，说话更有分量，更受重视，这时候就可以开始尝试参与业务，把前两年学到、总结的技能和理念真正运用到业务中去。

不要孤立地工作

无论你想做什么，首先要用开放的心态去面对，而不是下定决心后就马上努力去做，在做之前多听听别人的意见，看看是否有更好的解决方案。

比如你想做一个前端错误监控系统，你可能在网上搜索到了很多前端错误监控的详细资料，然后信心满满的开始动手，然后一个人默默工作了几个月，早起晚睡，终于做出来一个像样的项目，这时你拿出来准备大干一场，却被人一脸惊讶的说：“你不知道这个东西吗？”

又或者你在网上搜索前端错误监控的资料时无意中发现了，于是决定先熟悉一下，搞清楚了所有的开发部署流程后，准备干点大事，结果却意外地被告知，隔壁部门前段时间已经开发出了一套适合我们公司的监控系统？

所以一定要多和外界沟通，一方面是为了从外界获取更多的信息，另一方面也是为了让别人知道你在做什么~（至于为什么要让别人知道你在做什么，大家可以自己去琢磨）~

让数据说话

作为前端开发人员，你可以对后端开发人员提高或降低要求，甚至发号施令（当然我建议你谦虚一点），但前提是你必须有足够的信心，而实际的数据可以给你这种信心。

你需要提出一个性能优化的技术需求，这个需求需要几天的时间，如果你只是说前端性能不好，需要几天的时间来优化，这显然无法说服担心项目进度拖延的PM。但是如果你能拿出实际的数据，比如网站加载需要多长时间，发起了多少个http请求，代码量有多大，FP/FMP/TTI是多少，距离业界标准有多远，对业务可能造成什么样的影响，优化之后能达到什么样的效果，在你把这些数据合理有理有据的布局之后，只要PM是个正常人，一定会认真考虑你的建议，就是坚持以理服人。

好的态度

和纯技术不同，商业的事情肯定是和人有关的，而和人有关的事情肯定会有一个磨合的过程。在推动商业发展的过程中，肯定会遇到很多有意无意的阻力，可能让你好心努力的时候会觉得很委屈，觉得自己的好意没有得到认可，还不如每天什么都不做。这不仅是对工作的不负责任，更重要的是对自己的不负责任~（毕竟你肯定不想35岁就失业）~

基本上，团队促进了一个人，每个人都无法独自工作。

请务必认为您的能力并不是您渴望完成您的事实，因此您认为您的同事属于同一公司，甚至是您的能力，您的能力并不多。原因了？

您只是在工作，如果有问题，就没有必要让自己不开心。

概括

我最初只是想写有关如何更深入研究业务的文章，但是后来我觉得这更像是职业发展指南，所以我会把它留下来。

以上只是我目前的一些个人意见。