⚡叶勇文案百科,文案咨询师,微信:68728109 文案百科 叶勇文案百科:前端开发的难点到底在什么地方

叶勇文案百科:前端开发的难点到底在什么地方

前端开发的难点到底在什么地方

一般意义上的前端项目:

-从0到1,治理晒哦为健全点的都能捣鼓出来;

-从1到60,后后端或者设计岗位勉强能兼任;

-从60到80,需要比较专业的前端;

-从80到100,这么好的前端可遇不可求。

从0到1就是从无到有的过程,很多人用WordPress,建站之星就差不多就能搞个demo了,可以拿去骗投资人的钱。

从1到60,就是勉强可用,基本上让后端工程师或者UI设计师找一套bootstrap的模板东拼西凑的也能勉强应付到第一版本上线。

从60到80,就是真正要做一款能完备、性能优良、架构合理的中小规模产品,没有专业的设计、前端、后端、产品、运营是走不到这步的,差不多到A轮了。

从80到100,那就是追求各方面的极致,与竞争对手一较高下,各个方面没有顶尖的人才都会影响整体的战斗力,木桶效应。

市面上看得见的web产品,属于0-1的一般就是一些快速成型的页面吧,都是现成东西搭建的,无所谓前端技术,最多是加个统计脚本;属于1-60的可以围观各种地方政府网站,一些垃圾流量站;60-80的属于标准的中小创业项目,80-100属于BAT和准上市公司产品。

你可以随便打开一些web端应用,然后体会一下这个产品处于什么阶段,再体会一下团队前端的level。

前端门槛低,所以很多初级场景中的可替代性确实很强,但在专业团队专业领域是很难被替代的,因为从一个基础学科扎实的科班毕业生到成长为专业前端工程师需要时间的积累。

回到问题本身,前端的壁垒是什么,或者前端工程师的核心竞争力是什么?我的回答是:

『能cover项目从0到80+整个发展过程所需的工程经验』。

解释一下:

1. 核心竞争力的主体是工程经验。
其实这个结论可以推广到其他研发岗位,就是每个研发岗位的知识体系都是由基础学科知识+领域工程经验构成,彼此不可替代的就是工程经验部分。一个后端工程师一时间不能替代同等级前端工程师到不是基础或者智商的问题,主要是工程经验不足,你让一个前端一个后端分别实现对方领域中一个有明确输入输出的功能函数,二者通过简单学习新语言新语法,加上开发手册查询,一般都能比较正常的实现业务逻辑,但你让他们hold住对方领域的完整项目就很困难了,技术选型,系统设计,模块拆分,平台特性,宿主环境,性能优化,构建部署,系统测试等等都是领域工程经验问题。

2. 工程经验的等级是能cover项目从0发展到80+。
这个很好解释,因为从0-60的非专业前端也能做到,60+的才是专业前端。

所以不用担心核心竞争力问题,60+的前端现在都很抢手啊。工程经验只有60-的话确实压力比较大。

业务逻辑很复杂而且多变

『前端的逻辑复杂度基本不如后端』这个只是但从数据处理的角度来看的,前端对于数据处理的确是模板 + 变量一套一展示就好了,这个是挺简单的。

前端逻辑复杂度主要在于数据 + UI + 交互的实现,就比如一个简单的多 tab 页的功能,可以用 CSS 实现、用 JS 实现,JS 可以通过切换 remove DOM 或者添加 classname 隐藏,虽然效果上都可以实现,remove DOM 无法原有结构的状态,添加 classname 的 CSS 方式很难实现初始化状态。除此之外还可能需要对浏览器进行兼容性处理 + 响应式。然后突然来个业务需求说要加个 iframe 嵌入别人的页面,或者改什么效果,如果之前开发的不合理,基本上要重做了。

相比后端,只输出数据模型给前端,如果业务不需要什么字段了,甚至让前端不读取好了,改都不用改。我们几次大的业务平台重构,前端基本要重新开发一遍(效果、交互完全不同),后端模型和数据库则可以递进式的复用、扩展、升级。这也是导致前端需要堆人大力出奇迹的问题。

垂直领域解决方案很难

切页面是没什么难度的,但是在淘宝一到双十一、双十二大促根据经常多变的运营需求切几百个页面就很难了。这已经不是堆人堆外包可以解决的了,所以我们有 TMS 等各种运营系统,前端切模块,运营自己设置图片、文案、组装成运营页面,想改自己在后台改不用麻烦前端。这一套系统是个比较庞大的工程,从模块规范、模块开发工具链、模块发布和版本管理、在线管理、在线可视化搭建、数据填写和数据源导入、页面生成和 CDN 同步等等,都需要前端架构师设计然后开发。设计这个系统是很难的。

再比如富文本内容发布业务需求,光是一个富文本编辑器就很复杂,要实现各种功能和兼容性,更复杂的是要适应业务发展。当时刚开始交接淘宝内容业务的时候,需要重新开发编辑器等,跟后端大神们进行讨论推测未来业务可能会有大量表单而且需要完全的数据驱动,所以我们前端设计开发了 现在有个项目表单很多,用什么技术框架合适? – 知乎 技术产品然后后端有对应的 SDK 进行解析和数据存储、表单生成服务,前端只需要开发组件,然后后端按照业务需求进行配置即可产出内容发布表单。

此外,富文本我们选用了 JSON base 的存储,对比 HTML base 的编辑器,因为淘宝内容详情页充满了各种商品、优惠券、店铺等信息,而且这些信息是需要被理解、识别而且在详情页输出前实时补全最新价格、优惠券可用状态、店铺名等信息的。用传统输出 HTML 的编辑器输出,让后端解析的话复杂度太高了,每一种素材你都需要设计、约束特定的 HTML 标记让后端进行解析。所以我们基于 跳转中… 封装了一套 JSON base 的富文本编辑器,设计了完全数据驱动的插件机制,可以通过配置任意控制要提供的功能等。

虽然知乎的编辑器也是基于 draft-js 开发的,但遇到的业务挑战完全不同。它不需要功能动态变化,因为所有人都一样。然后不知道是后端的数据处理逻辑的问题,它在提交和回填的时候是通过 HTML 作为媒介进行传播,将 draft-js 的 JSON 数据协议转成 HTML 提交给后端存储。所以不同业务场景、特点,需要完全不同的前端解决方案,在开发这些垂直解决方案的时候,业务分析、技术选型、架构设计、开发落地是非常难的。

『前端的逻辑复杂度基本不如后端』这个只是但从数据处理的角度来看的,前端对于数据处理的确是模板 + 变量一套一展示就好了,这个是挺简单的。
前端逻辑复杂度主要在于数据 + UI + 交互的实现,就比如一个简单的多 tab 页的功能,可以用 CSS 实现、用 JS 实现,JS 可以通过切换 remove DOM 或者添加 classname 隐藏,虽然效果上都可以实现,remove DOM 无法原有结构的状态,添加 classname 的 CSS 方式很难实现初始化状态。除此之外还可能需要对浏览器进行兼容性处理 + 响应式。然后突然来个业务需求说要加个 iframe 嵌入别人的页面,或者改什么效果,如果之前开发的不合理,基本上要重做了。
相比后端,只输出数据模型给前端,如果业务不需要什么字段了,甚至让前端不读取好了,改都不用改。我们几次大的业务平台重构,前端基本要重新开发一遍(效果、交互完全不同),后端模型和数据库则可以递进式的复用、扩展、升级。这也是导致前端需要堆人大力出奇迹的问题

难点在浏览器的兼容上和技术理念的更替。前端技术的迭代一点也不比后端慢,从原生css+js开发,以前你会css和js就可以写前端,到现在react,vue的全家桶框架开发。前端的开发理念和技术主流已经发生了质的变化。es5,es6、es7规范的迭代也是前端的必备。加上webpack,nodejs等各种技术。前端现在早已不是以前会css和js就能满足的了。已经开始有自己的技术生态,未来也将蓬勃

如何跟后端进行交互商榷把整个系统搭建起来。

叶勇文案咨询策划! (微信:68728109)http://www.iyeyong.cn/7361/

作者: 叶勇

我是叶勇,80后连续创业者。

叶勇文案咨询师

发表评论

邮箱地址不会被公开。 必填项已用*标注

联系我们

联系我们

在线咨询: QQ交谈

邮箱: 68728109@qq.com

工作时间:周一至周五,9:00-17:30,节假日休息

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

关注微博
返回顶部