我总是写几篇关于技术的东西，但是我从来没有想过我会写一篇与技术无关的文章，因为在我以前的看法里，这种文章完全是假的，技术至上？三年前，我毕业进入了第一家公司。我的技术实力使我在实际的开发工作中经常捉襟见肘，所以我认为我必须尽快提高我的技术水平。每天在公司呆到很晚，除了做需求，就是自学。在这种情况下，我几乎把所有的时间都花在了坐在电脑前研究技术上，这就造成了一个后果，就是我只关心技术方面，其他的我都不关心。而当需求越来越严重的时候，我才不管pm想干什么，需求的目的是什么，能不能成为不正当的需求。我只考虑如何在技术上实现pm的需求。哪怕是一个复杂的，不正当的需求，我也一定会用我的技术手段去实现，我甚至以此为荣。我觉得这是展示我个人能力的一种方式。有时候，我的团队领导因为考虑到少量的实现，会比较复杂。相反，给我提供几个简单的实施方案，我心里还是觉得有点鄙视的。我觉得组长太滑头了，什么复杂需求不存在？再给我一天时间，我就能为你实现它们。我相信很多小技术伙伴都有过和我类似的想法，但是三年过去了。回过头来，再想想。现在想学几个跟技术关系不太大的东西，比如业务技术或者商业？以前我觉得技术和商业是两条不相关的路。如果我把更多的时间花在业务上，花在技术上的时间必然会减少。作为一个技术人员，我还不如只专注于技术，争取100分的成绩。但其实这种想法有点幼稚。首先，除非你天赋异禀，否则很难做到一件事情的完美。其次，技术和商业并不冲突。花一点时间思考业务不会减少你在技术上的投资。相反，这两者是相辅相成、相互促进的。是1+1大于2的组合。因为你能找到业务的痛点，你就想用技术去应对。目的明确的学习和尝试，必然会有更高的效率。有了足够强大的技术，就可以处理更大的业务问题，获得更多的成就感。如果你没有主动做生意，而是被业务方赶走，这种行为就是搬砖。相反，如果你推业务，让业务方因为你而改变，那么被你业务赋能过的前台，往往看到少量三五年的工作经验就迷茫了，明明知道路已经走过，却不知道下一步该怎么走。所以我开始尝试改变，但是路径可能不太对。比如看到Flutter比较火，就去学Flutter，看到WebGL可能有前途，就去学WebGL，甚至还有人去学java/python。并不是说这些尝试新事物的尝试不好。反之，则好。任何时候敢于尝试，敢于行动，都是值得鼓励的事情。但是你要明确做这些事情的目的，要考虑ROI。比如你看好未来的颤振发展，打算将来投身于颤振领域，那么你先自学，为将来进入一个颤振团队打好基础，甚至为在自己的团队中推广颤振做准备，显然是正确的想法。但如果你只是觉得自己目前的工作到了瓶颈，我想大家都在吹颤振，反正也不知道该怎么做，那就跟风学学吧，说不定以后能派上用场。当你成为一鸣惊人的时候，这种思维其实有点偏了。Flutter确实能给你带来新鲜感和学习新事物的成就感，但它并不能解决你目前工作中的瓶颈问题，你只是选择回避。领导对你的绩效评分，不会在你学过Flutter的面子上留情，除非你的团队真的在用Flutter，你也有功劳。作为一个接待员，懂一点java/go会不会更有竞争力？我的回答是聊胜于无(最好懂一点，不过无所谓)。毕竟你是前台。如果在前台面试的时候连前台的基础知识都答不上来，那背Spring源码有什么用？而如果你能回答所有的基础问题，算法和项目经验，能和面试官有说有笑，谁在乎你能不能知道什么是高并发？拓展屏障技术的道路可以很广阔，但对于绝大多数场景下的绝大多数人来说，真正能用上的技术只是一小部分，尤其是前台。相对于后台和算法，技术含量低，更喜欢技术广度而不是深度的C++程序员可能会写出语法错误的C++代码，但这种事情在前台是很难发生的。稍微勤快一点的大一新生，毕业半年后应该不会写出有语法错误的前端代码。所有的bug基本都是业务逻辑bug。一个有五年工作经验的C++程序员和一个只有一年工作经验的C++程序员，他们的技术水平可能有本质的区别，但是如果换成前端程序员，很可能他们的技术水平相差不大。但是很明显，即使是前端程序员，一般情况下，我们还是会认为五年的工作经验会比一年的工作经验强，他们之间的技术水平可能不会有太大的差别。区别是其他方面的技术广度？也许不是。技能范围广的人在做技术选择时可以有更多的选择和搭配，但这种能力并不是必不可少的。当一个公司作为一个团队工作时，技术堆栈的选择很少会引起混乱。你可能学过更多的技术，比如React Native，Flutter，WebGL等。，因为你工作了很久。但这些更多的是给你切换到技术栈的能力，而不是增加你的整体技术能力。如果你的公司不使用React Native、Flutter、WebGL，对你来说也没多大用处，也没人会在意你的公司是否真的使用了这些技术？不好的想法。这些都不是什么难事。没有什么按部就班的技术。如果给一个应届毕业生一段时间，他是可以学习的。通常，一个部门或一个研究团队不可能使用多种技术栈。技术广度达到一定程度后，继续增加的意义只会越来越小。工作经验？是的，它不是。如果你工作了三年，三年只按部就班的搬砖，那么你可能只有一年的经验，被你重复了两年。真正好的工作体验应该是不断的学习和进步，而不仅仅局限于技术上的进步。如何写出易于维护的代码，如何利用技术力量保证业务稳定，如何带领新人快速融入团队，这些都是不可或缺的东西。获得这些能力需要时间。但它更需要你的主动探究和实践，而这些都是不能很快做到的事情，也是你作为一个老技术鸟，真正能和应届毕业生拉开差距的地方。无论是技术水平，技术广度，还是工作经验，都是有价值的。归根结底，因为他们都有服务业务的能力，所以一切都是围绕业务来进行的。既然无法避免，自然是越早了解游戏规则越好。前三年的生意是什么？经常有资历较高的同事跟我提起业务这个词，我听得也不少。有时候，我想去理解，却总觉得太虚无缥缈。我实际上可以看到并应用编程语言的语法、关键词、设计模式和算法，但什么是商业？我如何学习？我该如何关注我的生意？总之我很苦恼，但是我的事总是被人说，但是我又没有办法去做。我只好硬着头皮模仿。最后只学到了一点点，就逐渐放弃了目前在二公司任职的团队。和以前相比，业务压力大了很多，几乎不能像以前那样悠闲地做自己的技术研究了。但是在这种环境下，我对商业的理解加速了，也明白了为什么之前那么多人跟我说商业的重要性。但是没有人能教我什么是商业，因为真的很难解释清楚，或者换句话说，每天都有人告诉你什么是商业，但是因为你自己听不懂，所以你觉得他们什么都没说。大多数情况下，技术是为商业提供服务的。这句话包含两层意思。首先，技术的唯一目的是支持业务。第二，商业不仅仅是技术支撑的。还包括很多其他方面。商业是商业公司的命脉，技术只是支撑商业的关键之一，所以商业真的很重要。那么，很容易理解什么是商业。你的技术是为业务服务的，所有你能让你的业务蒸蒸日上的积极能力(包括但不限于技术实力)都是业务能力。如何为前台业务赋能？有人会吐槽。很久没说什么了，没错。确实如此。对于从来不知道什么是商业的人来说，无论别人说多少都很难理解。对于已经知道的，公事公办，根本没什么好说的。也许你真的需要自己去理解，也许有一天你自己也会突然明白。很难说清楚业务这个词到底是什么，但如何为前台业务赋能的话题在工作中是相当大的。但具体举例来说，对于C端产品来说很重要的一点是，很多业务页面自动设置业务手段，业务迭代的速度也是影响产品开发最直接但实用的关键因素之一，比如天猫618盖楼活动、美团满减活动等这些都是常见的商业手段，几乎任何面向C端客户的产品都不可能不这么做，而这些商业活动往往涉及到各种前端客户的博弈。可以说是比较依赖前台的业务。作为一名前台开发工程师，如果你的目标只是实现业务方提出的具体业务需求，当然是合格的。毕竟你完成了自己的职责，但可能还不够做一个业务页面。如果你来到一个商业页面，你会在线两次。但是，并不难，就是你无法避免的要经历整个开发过程。于是聪明人就想，能不能把这种固定路径搬砖的行为自动化，于是业务页面自动构建的概念就出来了。今后，R&D没有必要参与商业页面的开发和推出。让业务直接办理，又快又稳又好。以前一个业务活动需要审核、调度、开发、验收、上线等多个流程，现在简化到只需要验收和上线两个节点，大大提高了生产力。这是为了企业的成功。那么你能做什么呢？业内有很多知名的业务页面自动构建项目，比如阿里云蝴蝶、阿里飞冰等。，但是这些不一定完全适合你的公司。因为业务页面和具体业务有很强的关联性，Terby是C端，业务场景不同，业务页面自然不可能一样。如果你的公司没有这样一套自动构建页面的工具，业务高度依赖线上运营，那么这就是你的机会。适配器的手机终端已经成为主流。前端开发主要围绕app、M、小程序三个终端，而小程序又可以细分为微信小程序、字节小程序、百度小程序、支付宝小程序、快应用等。如果专门为这些终端分别开发一套代码，显然会对人力有更大的需求。如果所有这些终端的效果都是1+1等于2，还是可以说的。但是现实情况是1+1小于2，如何以最低的成本覆盖这么多的渠道是一件非常迫切的事情。于是，一个多端适配的解决方案出现了，大大提高了开发效率，不仅又快又好地完成了一套代码在很多地方的运行，还间接为公司节省了大量的研发费用，其价值毋庸置疑。那么你能做什么呢？类似Taro的多终端适配框架，确实适配很多东西，但是适配所有开放的东西，比如微信小程序、字节小程序、ReactNative等。这些都是开放的开发平台，但是你公司自己开发的app，比如Tik Tok app，支付宝app，必须有少量的专有协议，比如唤醒app，打开页面，激活相机功能等。一般来说，这些私人协议是不对公众开放的。如果想让一段代码不仅在小程序和M端运行，还能在app端运行，那么对这部分app的适配能力显然需要公司内部员工来完成组件库。甚至在前端切割引火的时代，Bootstrap之类的前端框架已经大行其道。时至今日，前端组件化已经大行其道，各种前端组件库层出不穷。本质上是为了提高开发效率，少量通用UI和逻辑都可以。作为开发人员，只需要专注于业务逻辑，但并不意味着iview、ant-design等组件库就可以胡作非为。pc的后端项目还好，但是如果是手机上的C端产品，你在组件库的选择上就需要谨慎很多，尤其是那些人气高或者场景生动的。对风格的要求比较高，广泛使用的开源组件库不一定能满足要求。比如支付宝和微信显然都有自己独特的UI风格，开源组件库也不可能专门去适配某个产品的风格，否则就失去了通用性，而支付宝或微信等特定app也不可能为了省事而放弃自己的风格直接使用开源组件库。因此，创建自己的组件库就成了一件非常有意义的事情。其实客户稍微多一点的C端产品都有专属组件库的需求，所以如果你公司的业务场景主要在手机端，而你发现没有专门针对你公司的组件库，那么不要犹豫，马上去做。这么明显的事情你不做，剩下的迟早会有人做，比如脚手架、国际化、工具函数库等。是少量有实际需求的东西。如何参与前台的业务？在大多数公司中，pm通常是主导产品。毕竟前台是开发商。无异于以一个业余爱好者的身份挑战职业。既不适合，也没赢，但不代表开发完全不能参与业务。pm一定比你更能把握整个产品的宏观图景。但是少量细节的部分肯定比一线的实际开发人员更清楚，细节往往是从具体的需求表达出来的。需求一般是由产品提出的，但需求往往需要开发才能实现，而产品需求的目的就是实现这种需求，着眼于产品层面，目的性很强。开发层面的东西还是要开发和评估的。那么这个差距自然是发展和参与商业的机会。提出需求并不完全是pm的特权。作为发展，要求需求也是可以的。业务需求可能没那么好提，但是技术需求是你作为开发者的专利。作为前台，你必须关注你的首页的一系列指标，主要关注三个方面:表现、互动、风格。页面加载是否快速，交互是否流畅，风格是否舒适统一，都是需要不断关注的点。如果出了问题，你应该主动去处理，而不是等着pm来找你。这是技术问题，你应该对此负责。所以你可以开诚布公的要求技术优化。不能保证一个流畅的页面会让客户更加忠诚，但是一个糟糕的页面一定会让客户流失(除非你是银行网站)。所以，表面上看，技术需求是技术需求，实际上，出于业务考虑，可大可小。小的可以统一风格，大的可以设置一个前端技术项目。比如产品希望通过业务活动的不断迭代来维持客户活跃度，那么他想要的只是开发者能够按时完成业务页面的上线。至于如何做到这一点，他并不关心，他只需要达到产品目的。作为前端开发，你意识到业务页面是可以配置的，所以需要和pm讨论，比如这个是否可行，后端配置是什么，需要预置哪些模板，需要预置哪些页面能力，数据存储的形式等等。此外，您可以继续使用产品来确认这些业务活动是否可以在未来以多种方式展开。如果是，那么你就需要考虑多端兼容的问题了。看起来，原本一个简单的业务活动，没有难度，没有工作量。应届毕业生一天就完成了，然后你作为开发者加入进来，于是你把这个需求分解成几个大项目，好像没事干给自己找事做。的确，有些人善于凭空捏造，整天做看起来很高大上但实际上毫无用处的事情，但不要一棍子打死一群人。无中生有绝对不是贬义词。如果确实有搭建后端和多端适配的需求，那么早晚都要做，而你能提前看到这一点，提前做好准备，就能保证业务的平稳过渡，这就说明了你工作经验的价值。pm提出的需求不一定是正当的，一个负责任的技术人员应该对需求有积极的判断。对不正当的要求坚决说“不”。我这里的意思不是要你鸡蛋里挑骨头给pm的工作制造人为障碍。相反，是为了给出更好的见解，共同承担业务的责任。比如，你事先和产品约定了一套治疗方案。在一个特定的函数中，产品发现数据没有达到预期，所以我想让你专门针对这个函数开发一个特定的逻辑来改善数据。这件事可能真的会做。而且技术上也不难实现，但是作为开发者，你也要对整体的技术方案负责。约定好的方案，为某个特定功能增加额外的逻辑，会损害整体的技术方案吗？因小失大会有长期的负面影响吗？有没有更好的处理方法？看起来有点推诿，但如果你的出发点真的是为了项目的考虑，而且理由足够有说服力，谁能说你在推诿呢？能够制止不正当的需求，把有限的人力和时间花在更重要的需求上，才能更好更快的推广业务，难道只有前台？很多人说后台比前台更接近业务，理论上似乎是这样，但我的看法是，这取决于你自己的态度。如果后台只是日复一日的CRUD，不主动去了解或者赋能业务，那么再亲近业务又有什么用呢？同样的，如果前台只愿意做剪影，那么即使每一个需求pm都特别明确的告诉你也没用，所以还是要看个人的主观能动性。除了技术，还需要主动去看更多的东西。我不是让你一行一行地看背景代码。当然有时间可以看看，但没必要。业务代码没什么意思，但是看着就疼。业务是从一个需求到另一个需求的迭代。然后，如果你想了解业务，pm从需求中提出了一个要求。你不仅要关心前台需要剪哪些图，用哪些样式，用哪些组件等技术问题，还要搞清楚pm为什么会提出一个需求，这个需求处理了哪些问题，涉及到的上下游关系等业务层面的事情，要在接口字段上和后台达成一致。不能只盯着后台把需要的字段返回给你，还要考虑少量，比如接口是否可以复用，字段是否冗余，接口是否需要拆分或者整合，前台如何保证页面在接口出错的情况下仍然可以被客户接受？也许有些事情应该由后台来做，但你不能保证每个人都会尽职尽责，所以你可以多关心几件事。当需求被评审时，项目经理会问你更多的问题。接口约定好了，后台更习惯你制定接口规则。这个时候，你还会认为前台只是剪图吗？如果你成了最熟悉业务的人，团队其他成员遇到不懂的业务问题，第一个想到的肯定是你，那么你在这个团队里就有实质性的价值，你就是那种不容易被取代的人。需要注意什么？不要闭门造车。不管你想做什么，首先要虚心面对，而不是打定一个主意就马上努力。做之前先听听别人的意见，看看自己能不能有更好的解决方案。比如你想做一个前台差错监控系统，你可能从网上查了大量关于前台差错监控的资料，然后觉得有信心可以入手。然后你一个人干了几个月，终于想出了一个像样的项目。这时候你拿出来一鸣惊人，结果你领导一脸惊讶的告诉你，你不知道有哨兵吗？或者说，你在网上查询前台错误的监控数据时，无意中发现了哨兵，于是决定先熟悉一下，搞清楚所有的开发部署流程后，再拿出来准备做一个大的。结果你领导一脸惊讶的告诉你，你不知道隔壁部门前段时间给我们公司开发了基于哨兵的监控系统吗？所以你一定要多和外界沟通，一方面从外界获取更多的信息，另一方面也要让其余的人知道你在做什么(至于为什么要让其余的人知道你在做什么，你可以用数据说话做前台，可以要求或者删减需求，甚至可以口述到后台(当然我建议你谦虚)，但前提是你要有足够的自信。而实际的数据可以给你这种自信。您将需要几天时间来提出性能优化的技术要求。如果只是说前台性能不好，需要几天时间优化，这显然无法说服担心项目进度被耽误的pm。但是如果你能拿出实际的数据，比如现在网站加载需要多长时间，发起了多少http请求，代码有多大，FP/FMP/TTI有多少，低于行业标准有多远，可能对业务产生什么样的影响，然后优化后能达到什么样的效果？合理整理数据后，pm只需要做一个正常人，肯定会认真考虑你的建议，就是坚持用良好的心态去说服人，和技术的纯粹性是不一样的。生意上的事情一定是和人有关的，和人有关的事情肯定会有一个磨合的过程。在推动一个业务发展的过程中，你肯定会遇到很多有意无意的阻力，可能会让你觉得很委屈，觉得自己的良苦用心没有得到认可。还不如天天划水。这不仅是对工作的不负责，更重要的是对自己的不负责(毕竟你不想35岁就失业。)业务基本是团队推动，个人单打独斗的可能性几乎没有。团队中每个人都有自己的长处，当大家的长处汇集在一起，团队的战斗力才能发挥出来。这可能比你攻克一个技术项目更重要。不要总觉得自己的同事sx，既然同属于一个公司甚至部门，就说明你们的能力相差不大。如果你认为你周围的人都是sx，那么你很可能也是一样。所以当你在努力完成一个商业目标却遇到阻力的时候，不要急着去骂同事sx，要冷静的说实话，讲道理。如果做不到，就走一个流程。大家都在工作，谁没事针对你？你只是在工作。不能因为工作让自己不开心。如果你有任何问题，你可以处理它们。做你认为你应该做的事情。你要相信领导能坐到那个位置，成为领导。很大概率他不是傻子(如果是，我建议你为了未来赶紧换个公司)。真正努力的人，会更容易得到机会和赏识，在前台混了几年。总结了一套前端学习的强化视频和学习路线。如果有对前端开发感兴趣的伙伴，无论是想转行的，还是在校大学生，或者是想在工作中提升能力的web前端党，欢迎大家加入我的前端开发交流群:603985993。希望大家真诚交流！，与企业需求同步。 朋友在里面学习交流。大牛每天定时讲解前台技术！也可以关注我的微信微信官方账号:【前台学员】每天更新最新技术文章和干货。 本来总结只是想写如何深入业务，后来感觉更像职业发展指南，就这样吧。以上只是我目前的个人看法。毕竟经验有限，有些观点可能不会太成熟。欢迎更多讨论。最后，我听了很多道理但还是过得很辛苦。同样的，我也看过很多心灵鸡汤，但还是不知道如何摆脱瓶颈。这个时候我建议你换个环境，不要努力。有了外力的帮助，会更容易。当你处在一个充满活力的环境中，即使跟着团队惯性走，也能一直往上走。无独有偶，字节跳动就是这样一家充满活力的公司(手动狗头)。