资讯专栏INFORMATION COLUMN

如何降低前端开发的复杂度

xorpay / 2999人阅读

摘要:我们作为前端开发,都应该具有这样的能力。那么如何才能降低业务开发的复杂度呢细分组件都说模块化开发,其实在,这些思想规范之前就已经有模块化开发的规范了,虽然标准从然后隔了年才有了,在那年基本都是函数式开发,一切皆函数。

优秀的程序员总是能优雅的组织自己的代码,清晰的编写思路,合理的组织结构划分,从小的功能组件,到大的模块结构,都能通过合理的巧妙的搭配,不仅能化复杂为简单,更能提升代码运行效率,提高代码的可维护性。我们作为前端开发,都应该具有这样的能力。

那么如何才能降低业务开发的复杂度呢?

细分组件

都说模块化开发,其实在AMD,CMD这些思想规范之前就已经有模块化开发的规范了,虽然JavaScript标准从es1-es4 然后隔了n年才有了es5,在那N年基本都是‘函数式开发’,一切皆函数。之前还没有模块化加载的思想,毕竟也不需要,富客户端还是flash的天下,基本都是简单的网页嵌套一些后端的代码逻辑,然后通过后端渲染引擎渲染或者解释器解释产出html页面,什么ASP,PHP,JSP等等。

然而之前的模块化称不上是模块,为什么呢?因为没有模块加载器,主要是通过JS加载顺序来控制加载的,依赖的JS文件放在前面。模块主要是按照文件来划分,每个文件是个独立的功能模块,在自定义的命名空间下挂在需要暴露出来的函数,其他函数可以调用。当然也有一些打包工具,可以根据事先定义好的文件列表,把多个文件打包成一个bundle。

而现在,且不说你是喜欢自己编写或者用现有的模块加载器,或者直接用像Angular,React,Vue等现成的脚手架做开发,当然自带的就有了模块加载,配合Webpack、Rollup等打包工具,可以完美构建你想要的项目加购。

所以呢,建议还是要按照功能和业务结构划分你的组件,这样呢一方面可以将功能解耦,一方面方便实现各自的业务逻辑,满足keep it simple的原则,模块自制。组件细分的得当,就不会出现一大堆函数代码,来回修改各种状态,一堆变量,一个函数写几十行那样。

建议:ES6 module + 函数式编程 + webpack/rollup ,绝对可以满足你的需要,关于业务如何拆分,拆分的维度,后面介绍。

独立状态维护

状态是什么?状态是数据。

程序是什么?程序是数据+代码。

所以可见数据的重要性,如何维护好一份数据至关重要。那么前面我们说了细分组件,数据呢? 数据是跟着组件的,那么数据自然也是需要做划分了。这里面说的是独立状态维护。假设一个组件的代码是这样的。

/**  约定规范 **/
// 状态
const state={
}
//行为
const actions={
    init:()=>{
    //组织声明周期
   }
}
//视图

const view=()=>(
    
)

这样很清晰的将程序代码划分成了状态、逻辑和视图。逻辑操作状态,视图更新展示状态。

为什么说要独立状态维护呢?也是为了降低耦合、提升组件复用。组件的状态应该只是包含组件需要的数据,而不应该包含其他多余的数据,按照软件设计单一职责的原则,组件的职责应该也是单一的,就是负责这个组件的增删改的功能。

需要说明的是组件的开发应该也是需要遵守数据驱动化的开发模式,避免直接操作DOM,即使是从DOM上拿数据,有同学喜欢这么干哈,把数据通过data-x属性挂在节点上,然后通过节点获取数据,这样操作是不好的,首先这种操作有副作用,而且容易引发bug,而且也可能有安全风险。

细心的同学可能要问,那么组件通信怎么办呢?组件之间的交互可以通过注册函数hook的形式进行。当前你也可以做一个事件注册和分发的功能,不过一般一个SPA页面不需要做的这么复杂,如果真的是很复杂的页面,还是建议做成做个页面。没必要做成一个大大的SPA。

函数式编程

关于fp函数式编程github地址:https://github.com/chalecao/fp
这里并不是来讨论函数式编程和OOP编程的好坏,你可以二者都用,也可以用其中一种,并没有限制,看个人喜好。
我个人呢之前经常都是class 还有extends混入高级的this。后来渐渐转向了fp函数式编程,完完全全可以避免使用new,避免使用this,而且结合上面 独立状态维护 中的结构划分,结合ES6的模块划分,可以很优雅的实现我所有需要实现的业务逻辑功能。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/107717.html

相关文章

  • 如何降低前端开发杂度

    摘要:我们作为前端开发,都应该具有这样的能力。那么如何才能降低业务开发的复杂度呢细分组件都说模块化开发,其实在,这些思想规范之前就已经有模块化开发的规范了,虽然标准从然后隔了年才有了,在那年基本都是函数式开发,一切皆函数。 优秀的程序员总是能优雅的组织自己的代码,清晰的编写思路,合理的组织结构划分,从小的功能组件,到大的模块结构,都能通过合理的巧妙的搭配,不仅能化复杂为简单,更能提升代码运行...

    wushuiyong 评论0 收藏0
  • 如何降低前端开发杂度

    摘要:我们作为前端开发,都应该具有这样的能力。那么如何才能降低业务开发的复杂度呢细分组件都说模块化开发,其实在,这些思想规范之前就已经有模块化开发的规范了,虽然标准从然后隔了年才有了,在那年基本都是函数式开发,一切皆函数。 优秀的程序员总是能优雅的组织自己的代码,清晰的编写思路,合理的组织结构划分,从小的功能组件,到大的模块结构,都能通过合理的巧妙的搭配,不仅能化复杂为简单,更能提升代码运行...

    LinkedME2016 评论0 收藏0
  • ELSE 技术周刊(2017.10.16期)

    摘要:前端中的计算机领域的通常认为起源于。并对其主要内容作了自己的解读。搬到另一个地区会导致名气降低。年度报告,年最受欢迎的编程语言年上最流行的种编程语言及前十最火热的项目排行榜,分别由及登顶。技术周刊由小组出品,汇聚一周好文章,周刊原文。 showImg(https://segmentfault.com/img/bVWHC4?w=1000&h=710); 本期推荐 反击爬虫,前端工程师的脑...

    0xE7A38A 评论0 收藏0
  • ESLint 在中大型团队应用实践

    摘要:自动化接入和升级方案通过命令行工具提供一键接入升级能力,同时集成到团队脚手架中,大大降低了工程接入和维护的成本。原始代码经过解析器的解析,在管道中逐一经过所有规则的检查,最终检测出所有不符合规范的代码,并输出为报告。 引言 代码规范是软件开发领域经久不衰的话题,几乎所有工程师在开发过程中都会遇到,并或多或少会思考过这一问题。随着前端应用的大型化和复杂化,越来越多的前端工程师和团队开始重...

    alogy 评论0 收藏0
  • 方案设计--如何看待前端框架选型 ?

    摘要:纯前端开发主要是针对静态页面。自主权最大,正常是使用进行辅助开发,上线等。大致原因使用是为了和端的保持同步。四总结对于比较正式的项目,前端技术选型策略一定是产品收益最大化,用户在首位。 对于前端团队,可以实现企业受益最大化要点。 一、技术选型的策略 1、保证产品质量 (1)功能稳健:网页不白屏,不错位,不卡死;操作正常;数据精准。 (2)体验优秀:加载体验,交互体验,视觉体验,无障碍访...

    gnehc 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<