作者：羊杂 / 编辑：尼諾 / 审校：风水
从学生身份转化为职场人身份已经四个月有余了，时间过得实在是快，从第一次发布自己做的页面时的激动不已，到现在并行灰度发布多个页面的平常心。这段时间里，无论是知识还是心态，都有了不小的变化，各方面也积累和沉淀了一些心得体会，这次我想先从组件这个层面来讲一下。
在我看来，前端同学一般把更多精力放在页面的渲染展示和性能调优，区别于后端同学对逻辑和算法的深入思考（不过事实上也不会把过多的逻辑放在前端处理，这也让前端同学的算法能力很难有用武之地）。客观上造就了前端同学在逻辑和算法方面关注甚少，这点我在校招时候，我和面试后端岗位的同学刷的 Leetcode 题目数量对比起来就很明显了。
前端开发的基本要求就是还原页面，只要做好这一点，就可以成为一个合格的切图仔。事实上这个要求并不难，即便没有计算机基础，去机构培训一段时间就可以胜任切图仔的工作。我也曾经围观过这种代码，可以说页面看起来光鲜亮丽，但内在实在不堪，代码逻辑混乱，没有ES6，没有设计模式，让我想起来这张图。
前端开发进阶的下一个阶段是编写可维护的代码。需要有清晰的逻辑思维和良好的编码习惯，在变量命名、编码风格、注释规范等方面遵行统一的规则，还有做好包括Mock数据和单元测试等编码环节。代码质量也是分三种层次，第一种是自己的代码自己可以看懂，第二种是自己的代码讲给别人，别人可以听懂，第三种是自己写的代码别人经手就可以理解，而这种情况正是一个团队高效协同必备的。
前端开发再深入进阶的话，我觉得更重要的点就是如何能在已有的内容中提炼出精华，落实到代码中就是能否抽象封装出优秀的组件供复用？让自己的工作产出不仅仅只是为了完成需求，而是可以积累和沉淀，使自己和团队共同分享共同进步。
回想刚来 Lazada 的时候，当时的我不熟悉技术栈，写代码时的想法就是：又不是不能用。以至于后来再回头看自己写的东西，感慨这玩意能跑起来属实不易。业务逻辑和渲染逻辑混杂在一起，甚至连要修改的东西都要全局搜索许久才能找到。不了解已有的技术沉淀，很多现成的代码需要自己花很长的时间去手撸一遍，完了后又各种bug 频出，效果不尽人意。总结就一句：代码忒难维护了。以至于后来再迭代新功能是，自己把自己两个月前的代码给重构了。后来逐渐去更多地了解了组内的技术沉淀，深深感慨有些弯路真是白走了。弯路虽然白走了，但也不全白走。自己亲身把坑踩一遍也是成长的过程，有失有得，踩坑的这段经历让我印象深刻，更让我对前端开发有更清晰的认识，同时也让我更加意识到复用和组件化的意义。
一个组件具有可扩展性，复用性，以及标准等特性。组件的存在就为了复用。所以一个通用组件是与具体的业务需求应该是解耦的。但也不完全解耦，不同的内聚程度决定了组件的适用范围。
前端经历过这么多年的沉淀，通用组件的发展已经很完善了，Fusion，Element，AntDesign 都是各个专业团队打磨了多年的成果，事实证明它们也都是非常成功的组件库。
在 ASC 侧，作为一个 ToB 的项目，ASC 的页面就带有很强的业务属性，通用的组件满足不了我们不断提升的开发效率要求。因此这一年多来，Seller 团队基于 Fusion 也沉淀了自己的一套带有部分业务属性的组件库 asc-components，提供的组件覆盖了 ASC 开发的各个场景的需求。其次，每个域也都在业务开发的过程中沉淀适用于各自域场景的组件，这些业务域中的组件如果使用场景逐渐通用，就会放在asc-components中让更多开发者去使用。
在我看来，组件发展的其中一个极端表现：就是 Dada。在 Dada 里，一切皆为组件，一个页面全是通过各种组件搭建起来的。深入了解 Dada 的发展史，演变成这种结果也是有历史依据的，中台的同学在改造完前 Lazada 的项目后，觉得这一套技术也可以赋能其他业务，因此设计出了 Dada。你说它强，它确实很强，对于 B 端的通用表单等场景，熟悉 Dada 的同学可以用很短的时间完成需求交付，这也是 Dada 之所以产生的本意。Dada 在 Lazada 发展了很长一段时间，留下了很深的印记。而 Lazada 的业务成长飞快，有更复杂的业务逻辑需求，有更复杂的流程处理需求等等。Dada 的劣势也暴露出来了，我曾在某个 Dada 页面看到多个数行字符串的 reaction（JS逻辑内容），而这只是一个不复杂的表单页面。有些逻辑更加复杂的页面，我的师兄觉得我难以维护，花了数天去进行重构。还有一些 PD 提出对页面细节样式做调整时，Dada 实在是“做不了”。这种情况下，团队发起了源码化的行动，新建页面皆用源码开发，旧页面伺机重构。
这是全盘否定了 Dada 么？并不是。
有这么一个需求，是一个商家孵化项目的展示页面，要在这个项目的不同阶段，页面表现出不同的主题颜色或者是有不同的提示信息和不同的操作按钮。该项目又与其他的一些项目存在依赖关系，其他项目的状态也会部分影响到本页面，前前后后算下来一共有 30 多种场景。
那么这么多场景的展示如何实现？根据后端返回的状态字段去写场景？
相信一连串的逻辑判断地狱会让人自杀的，何况这么多的逻辑判断是很容易出错的，估计没几个人愿意去维护这样的代码。
不妨抛开这些业务场景，将页面当作一个组件的集合。比如顶部会有一个Message组件，每种场景都会有不同的类型和展示内容以及操作。再比如页面背景什么时候需要展示红色或者蓝色，只是一个二选一的问题，不需要前端判断，只需要后端接口用一个布尔值控制就好。也就是说，把业务逻辑后置，约定好页面渲染的字段，前段只关注渲染内容。就算业务逻辑有所改动，前端也无需改动。事实上，这就是 Dada 在做的事情。页面上的内容完全是由后端返回，字段是否显示、禁用，所有的属性统统是由后端说了算。这样做了后，字段有什么逻辑变化统统可以在后端更新，前端零成本。
当然，这是只我在使用Dada过程中的一个爽点。再有就是可视化搭建功能，实现了低代码开发，对于开发语言掌握不高的人也可以搭建一个页面，我觉得这个可作为Dada推广发力的一个亮点。但是对于日渐复杂庞大的ASC业务，Dada逐渐的挑不起这个重担，还是要回归到最“原始”，灵活的源码开发。不过可以去借鉴Dada的思想，在某些情况下提高代码可维护性和开发效率。
对于现在的我来说，在日常的业务开发过程中，会更多地注重逻辑层和展示层的分离，视场景而主动地去抽象、封装和复用。我所理解的复用是为了提效，减少开发工作量，为编写可维护代码奠定了良好的基础。