业务应用前端实战经验总结

做业务项目和做产品工具有很大的不同，大多数前端工程师都有几个项目经验，不过有些人做了很多项目，却十分雷同，没有什么进步，今天，我斗胆把自己的一些感悟分享给需要的人，有用的话就吸收，觉得没用就当我是放屁算了。

技术能力vs.业务能力，可以双修吗？

很多做管理的，会对手下的技术工程师说：你们不要光专注于技术，还要去了解业务，要比业务更专业，要去引领业务…，而工程师心里也许早就一万个’XXX’了，我要是能比业务更加专业，那还要业务人员干嘛？

技术能力和业务能力到底要不要双修，可不可以都很牛逼，众说纷纭，没有人不欢迎那些技术碾压，业务精通的人，可是大家都知道这种人不仅需要付出巨大的努力，还需要有好的机遇，技术和业务双修很可能得了两个50分，搞的鸡不是鸡，鸭不是鸭。

一个人的精力是有限的，技术一直在不断的进步，稍不努力，就被别人超越了，所以做技术的人压力一直很大，需要不断的进步，很多人转了架构师、产品经理、项目经理后，发现自己的技术能力很快“消退”了，没有底气了。

在VUE,ANGULER,REACT之前，前端工程师的话语权很弱，因为前端技术入门易，很多做后端的看不起，做管理的觉得你不值钱，后来NODE兴起，前端逐渐工程化，复杂化，后端大佬说学不动了，才让出这么一块天地，如今，各种框架百家争鸣，而后端java生态也一样卷不动了，网络上标题当诉说着“前端已死”，“java已死”，“数据中台已死”…，反正大家都不好过。

中国的就业市场现状也说明技术似乎真有那么一个天花板，无论是技术能力本身，还是年龄限制，纯做技术是行不通的。做的项目多，技术能力会日臻成熟，可是不积累业务，就会缺少一些亮点，有些前端不管做什么项目，就照着UI稿做界面，你问他这里为什么要这么展现，换另一种交互是否可以？或者用户做这个功能做什么，要解决什么问题，能否用其他方式实现需求，是否在其他系统中有类似的可以满足的功能？…这些东西看似是项目经理、产品经理的事，无需前端工程师操心。

可我觉得，这些事也是需要知道的，尤其当你的专业能力提升到一定程度后，你不仅要知道做的什么事，为什么要做，能否有更好的方式，现有资源能否满足，如何避免浪费。

技术的广度和深度需要很长时间提升，尤其工作5年内以技术为主没有问题，甚至先博后约，一开始前端、后端、数据库、项目管理等一起学，后面精修一门技术，再之后就不能忽视业务知识了。

但是，做技术的，很难比业务更加业务，你可以利用自己的专业知识为业务提供独特视角，提供更加完美的解决方案，但身不在位，你怎么能比业务更牛？业务日常办公里你都在场吗？业务开会时你都在吗？业务见客户是都会带着你吗？当然不会，所以要想技术和业务双修，又可以都很优秀，很难。

避免过度封装

对于做应用开发的工程师，建议不要做过多的封装，组件是为了利用的，有很多人封装大量一次性使用的组件，增加调用深度，比如有人把每个div都封装成个组件，在他的代码里你看不到div标签，阅读起来感觉无限深渊，一个页面里几百个组件。

对应用项目来说，一般代码写出来就要准备好去修改，过多的封装要耗费大量的精力，很多应用项目的弃用率也很高，不需要花费过多的精力，把代码写简洁，结构清晰就可以了。

配置和数据分离

见到有的人，配置的信息里混和了动态的数据内容。有时需要保存一些配置信息，这些配置信息应该和动态获取的数据是隔离开的，不应混在一起，即使在业务渲染时，配置要和数据整合后显示，也只应在渲染前一步来实现。

哪些东西前端实现，哪些东西后端实现？
OIP-C.jpg

相信没少人会因为这个相互争吵。

有些东西即可以前端实现，也可以后端实现，有人说，哪里实现容易就应该哪端实现，比如有个逻辑前端实现要比后端容易很多，就应该前端实现。

我不这样认为，我觉得应该在哪端实现，就应该在那实现，而不是看是否容易来决定。

比如，格式化显示，我认为应该在前端实现，一个数据“完成率”，要显示成百分比，那么，数据库应该存数字类型0.135,而不是存成13.5%,或13.5，因为格式是用户常会变的内容，今天用户想显示成13.5%，明天也许想改成13.50%，如果放在数据库，或java端转换，就不够灵活。

再比如分页，前端可以实现分页，后端也可以实现分页，一般情况下，后端分页用的比较多，一次只取一页数据，无论对数据库，还是对服务器内存，或对网络都是比较友好的，个别情况下，也会去做前端分页，一次把几十万的数据给到前端，一页页的显示，前端分页的好处是加载一次数据，后面分页切换很快速，对于数据变化不频繁的场景，每次数几十条和每次取几十万耗时接近的情况，才会考虑前端分页。这需要根据具体的业务需求和实际情况来判断。

还有很多，比如有个列表，根据后端返回的某个disabled字段控制显示状态，当为1时前端置灰禁用，当为0时可用，某一天，有些特殊情况需要修改，disabled本来返回1的地方要返回为0，这时前端也可以实现，只用判断这种情况，把disabled改成0就行了，java工程师说，你前端改的快，你来改吧。这种情况我是反对的，这个本来就应该后端来改，不能推辞。如果前端改了，将来某天换成别人来维护了，业务换人了，不知道此事了，可能会为，这里为什么不是禁用状态了？结果一查，后端说，我返回的是disabled=1呀，是前端显示的问题，这不就背锅了么？这就叫，显示与接口数据不一致。

业务逻辑要抽离

前端经常把接口的调用单独抽出一个文件存储，实际上，业务逻辑的处理也应抽离成单独的文件，有条件的情况下，交互相关的抽离在一起，数据逻辑处理抽离成单独文件、渲染处理抽离成单独的文件，这样页面开发就很容易理解。

一般情况下，业务逻辑大多在后端，但现在也会有一些放到前端，前端作为用户接触的人机界面，常常是bug的输入口，而且在项目开发周期里，前端的bug是优先解决的，如果没有好的结构，随着代码的堆积，将会变得非常凌乱，不好维护。

很多大厂把前端开发推给外包，外包一般不管整体结构，不断堆代码，业务代码并非无法学到知识，提升技术，如果用心去做，不仅能提升解决实际问题的技术能力，还能积累到一些业务知识。

总结

总之，技术是为了服务业务，虽然技术不一定能全部用在项目里，但如果用心，把项目代码弄的井井有条，一样可以彰显能力，做有用的东西，而非追求一些花里胡哨的，反而更有意义。