做前端的一点小感想

大学研究了四年前端，但遗憾的是在几乎没有人带我的情况下，弯路走了不少，也踩了无数的坑。幸好也稍微攒了点经验，这里简单做个总结。如果其中有些文字你难以理解，先尝试忘记这些“教条”，亲自去实践一段时间后再来回味，说不定你会有比我更深刻的理解。

非常感谢我的实习导师，为我的职业生涯指点迷津。本文中的一些观点是导师之前工作中讲到的，我结合了一下工程实践中的经验，总结出来了这篇文章。

前端是一个入门很容易，进阶相对陡峭的领域。学习的内容非常广且零碎，对某个内容过分钻研容易导致顾此失彼，我采用的是渐进式学习法，即先把大体概念了解到，然后会用，等到其他关联知识也稍作了解后再尝试慢慢深入原理性的内容。

何为前端

前端开发是创建WEB页面或APP等前端界面呈现给用户的过程，通过HTML，CSS及JavaScript以及衍生出来的各种技术、框架、解决方案，来实现互联网产品的用户界面交互。

前端开发从网页制作演变而来，名称上有很明显的时代特征。在互联网的演化进程中，网页制作是Web1.0时代的产物，早期网站主要内容都是静态，以图片和文字为主，用户使用网站的行为也以浏览为主。随着互联网技术的发展和HTML5、CSS3的应用，现代网页更加美观，交互效果显著，功能更加强大。

前端技术的发展是互联网自身发展变化的一个缩影。前端技术指通过浏览器到用户端计算机的统称，存贮于服务器端的统称为后端技术。前端开发主要职能就是把网站的界面更好地呈现给用户。

摘自百度百科《前端开发》

总的来说，前端开发是一个更偏向用户的工作，我们绝大部分的产出都拥有很直观的视觉呈现。到目前为止，它仍然只需要 HTML，CSS，JavaScript 就可以实现各种丰富的功能和效果，但这并不代表我们永远只围绕着三个基础内容展开学习。如果你有兴趣在互联网上搜索一下前端工程的发展史，你便可以发现前端的新技术、新框架等层出不穷，这些工具大多是为我们更好的完成开发任务而产生的。工程化与规模化的趋势是当今的主流，当然，我相信在其他编程语言的领域里也是同样的道理。

前端的日常工作是使用前端领域的技能和工具，将 UI 设计稿转变成可以使用的软件产品，且通过合理的数据结构组织方式与服务端进行必要的数据交互。从工作职责上划分，所有用户终端产品的视觉部分和交互部分，都应该由前端来负责。

何为大前端

前端与大前端之间相差了一个“大”字，这一字之差究竟体现在了哪里？

关于大前端，目前业界仍然没有非常明确的文字定义，但我们可以通过大前端的职责来明确出大前端的含义。

大前端相对于前端，承担的职责更多，涉及的领域更广，掌握的知识体系也更完善。这里的“大”字，可以理解为“能做更多、更广泛的事情”。大前端的概念与前端自全栈有些相似，但其实有很大的区别。

大前端涉及的领域除了单纯的前端开发之外，还涉及到 App 中的前端开发和 Node 服务端开发。在当下前后端分离的大趋势之下，产品对前端的需求越来越高，用户对前端的期待也越来越高，前端已经不再是昔日的“切图仔”，而是变成了一个需要能够承担起多种业务场景下的用户界面和交互的领域。

（不知道什么是前后端分离？不知道什么是“切图仔”？该部分属于前端工程发展史领域的内容，请自行查阅互联网资料了解。）

由于前端脱离了后端之后，数据等资源无法得到保障，所以前端工程师采用 Node.js 自行开发简易的后台服务，且仍然可以使用 JavaScript 语言。尽管 Node.js 在综合表现方面并不如专业的 Java、Go后端，但自行搭建一些小型的服务系统或者工具集是绰绰有余的，Node.js 在推行前端工程化方面有着不小的贡献。

大前端的业务拓展主要体现在跨平台开发上。大前端让前端打破了浏览器的限制，将业务延伸到了 App，客户端程序，小程序等领域，同样在现在或未来也可包括可穿戴设备、嵌入式设备、智能系统等，我们生活中的“终端”越来越多，大前端所能涉及的领域也同样越来越多。

大前端同时也关注着前端工程化，以及整个项目的生命周期。前端的独立性日益增强，自身也理应拥有独立部署项目和服务的能力。工程化不仅是软件设计和代码实现上的工程化，而是涵盖了设计、开发、测试、部署、迭代等一系列软件工程的范围。大前端工程师的关注点更加宏观，不仅关注于产品和代码本身，同时也要关注业务、项目在整个生命周期上的全过程。

然而应当注意，这并不代表大前端工程师应当负责所有产品、项目管理、测试、运维等领域的专业职责。应当记住，关心这些领域的最终目的是不再关心这些领域，即掌握这些信息的用途是帮助我们设计并落实一个更好的工作实践，在大前端领域抛除这些领域对前端的影响，妥善解除前端领域与其他领域的耦合，使我们更加专注于大前端的内容。

总而言之，凡是和用户直接触达的端，且采用了前端技术开发的，都涵盖在大前端的范畴内。

三驾马车

现代前端开发工作通常围绕“三驾马车”来体现前端的价值：提效，降本，用户体验。

• 提效：
  • 提升效率，包括提升用户操作的效率与开发者工作的效率。
• 降本：
  • 降低成本，包括降低用户使用产品的成本和降低开发者维护项目付出的成本。
• 用户体验：
  • 关注用户体验，做用户感觉舒适的产品，优化永无止境，永远以更优质的用户体验为目标。

在工作中，时刻牢记我们的工作价值围绕着这三驾马车，你会发现你做的很多事情都是非常有意义的。

页面不是前端的终点

学习前端是一个看得见摸得着的过程，你所写的内容绝大部分都可以为你提供明显的视觉反馈，你会感觉到这样的学习是“有效果”的，但绝不要浅尝辄止，仅仅把前端的思维停留在写页面本身。

前端的本职工作是做页面，但前端的领域绝对不止做页面，我们还有更多深入的领域需要探索，这样才能为自己的职业生涯争取更多的话语权。很多前端从事工作多年，发现在公司里前端开发非常没有地位，UI给什么稿子就要完美还原、产品提什么需求就要认真实现、后端给什么接口都要灵活处理，有时候用户反馈产品问题，领导第一个来问责的大概率就是前端，自己就像是个左右受难为的受气包，每天的工作只能是受人指使。这当然无法排除有外界原因，但我认为最根本的原因是前端没有在工作中为自己争取到应有的话语权。

如果前端工程师认为自己的定位就是“做页面的”或者“搭网站的”，这就把自己的思维框定在一个最根本的圈子里。这确实属于做好本职工作，但这样做的结果大概率就会如上面所说，自己真的很难把自己提升到一个更高的地位。前端想要争取到应有的话语权，应当怎么做？打铁还需自身硬，我们应当跳出“做页面”这个舒适圈，在工作之外多去思考为什么：业务上为什么要这么做、技术上为什么要这么做、当前项目的痛点都在哪里、我是否能够为解决这些问题做些什么？

我们的工作环境和工作流程大多情况下并不是完美的。有一位计算机界的大佬曾经说过这么一句话：

世界上只有两种软件，一种是满是bug的软件，另一种是没人用的软件。

企业里面的大型商业项目通常已经迭代维护许久，且可能经过无数人的 commit，不妨在工作之余浏览浏览自己负责部分之外的业务，结合这个领域的应用场景，多去想想有些功能的实现是不是一定合适？可能是一个组件、也可能是一个接口，代码能跑不一定表示逻辑正确，没有 bug 也不一定代表是最佳实践，你能够找到现在业务代码中的缺陷吗？你能指出现在的业务代码设计中有哪些不合理之处吗？如果由你负责这部分业务代码的编写，你能否拥有一个更好的方案代替现在的代码，并且能以可量化的结果展示你贡献的价值？

可量化，表示在应用了你的修改之后，代码和产品究竟在哪些指标上出现了变化。如打包体积下降了、加载速度提升了、网络请求减少了、还是非必要依赖变少了，诸如此类的指标可以通过各种前端监控或代码分析得到，如果你曾参与过实际项目的实践，你一定能听懂我在说什么。

跳出代码之外，想一下这个项目的业务流程你是否有了一个整体的把握？当产品经理向你交流需求的时候，你的第一反应是“这个需求能不能做”还是“这个需求有没有必要做”？产品经理并不能知道产品的实现细节，但是作为程序员的你是知道的，当产品要求你在页面上新增一个功能按钮，你能否想到这个按钮的功能之前是不是实现过？如果拥有替代流程，产品是否接受这样的使用方式？如果产品不接受的话，你能否站在前端的角度帮助产品思考这个新增的按钮对用户的影响和反馈？

这番连环问只是众多业务中的细到不能再细的细节了，如果你的回答均为“是”，我相信你对你的项目已经有了一个非常深刻的把握，你的话语权当然也就可以从这些思考和沟通中获取到了。拥有足够的话语权，代表着你已经可以在工作中主导一部分项目的设计、实现，当UI再给你设计稿的时候，你有足够的底气告诉他哪里会导致用户使用有疑问或难以实现；产品向你提需求时，你有足够的把握与他讨论这些需求到底有没有必要去实现以及怎样实现；后端和你联调接口时，你也有充分的理由告诉他接口应当是怎样的结构。所谓的话语权也就慢慢体现在这种细节里。

功夫在业务之外

业务是本，功夫应在业务之外。如何解读这句话？完成项目中的功能是我们的本职任务，但长期浸泡在编写这样形形色色的业务中容易迷失自我，变成一个增删改查专家。前端该不该做业务？当然应该，但是在自己拥有一定技术实力后，不宜将自己所有的精力都放在如何打磨业务逻辑上，而应该将自己的思路转变为如何突破已有的舒适圈，尝试更多不同的实践。

前端技术的发展离不开社区的贡献，前端社区便是由你我这些最普通的程序员共同维护起来的。大家都有自己的工作，那这些源源不断的新工具和新技术都是从哪里来的呢？功夫当然是在业务之外。我们在享受着这些高度集成工具便利的同时，也不妨静下心来想一想，这些工具到底怎样为我们提供了便利？你能否帮助这个工具的开发者解决目前已有的技术难题？而如果是你在工作中涉及到了一个前人未曾涉及的领域，你是否能想到自己开发一个专用的插件，方便在这种场合下解决一个特定的问题？或许世界上的另一个人在未来的不久后就遇到了与你同样的问题，我相信当他通过互联网检索到你提供的解决方案时，他会非常感激素未谋面的你在技术领域所做的贡献。

我们发明制造工具绝不是凭空想象，任何工具的产生都有其来源，我相信大部分的来源是源自业务实现过程当中。不要忘记我们做业务的本职工作，但我更希望前端能在实现业务的过程中多去思考究竟怎样才是最佳实践，在应当借助外部资源或自己开发相关工具时才能有根有据。程序员其实是一个终身学习的行业，可能很多人听到这个词就会疑惑，工作这么忙，到底怎么才能做到终身学习？或许可以暂时忽略掉单纯的学生思维，学习并不一定非得是拿着书籍资料，在图书馆泡杯咖啡静静看一下午，在实现业务的过程中，一样可以从业务中提炼各种知识，提升自己。

牢记，在内卷的大潮流中，沉淀业务实现中的精华，不断将学到的知识武装自己，这才是最珍贵的收获。