从年会看声明式编程(Declarative Programming)

从年会看声明式编程(Declarative Programming)

閱讀本文約花費: 9 (分鐘)

React的设计贯彻了声明式编程(Declarative Programming)的思想,今天就说一说什么是所谓的声明式编程

和声明式编程相对应的是命令式编程(Imperative Programming),大部分语言的hello world都是从命令式编程开始的。

什么是声明式编程?可以从一个现实中的例子来说明,这个例子就是年会。

举个年会的栗子?

作为我国科技公司的一个特色,每年春节前后都要举行年会,忙活了一年怎么都要热闹热闹,搞点娱乐活动,而且一定要有员工参与的娱乐活动,也就是要员工表演节目,表演节目就需要恰当的道具,所以,采购道具是年会准备中的重要一环。

每个公司准备年会节目道具的流程可能都会不一样,这里说一下我司Hulu的方法,技术公司的流程是非常技术化的,可谓声明式编程的楷模

Hulu,每个组都要在年会出节目,HR和各组节目负责人协调道具的采购,这个过程是这样:

HR告知每一个节目负责人:“你们节目需要什么道具?告诉我,我会去买。”

然后,每个节目负责人会和自己的组员商量节目内容,最后给HR一个道具列表,之后就等着HR通知去领道具就行了。

结束了!这就是声明式编程的思想。

你可能会问:就这么简单?

回答:就这么简单,所有的采购、运输、协调,都由HR来做了。

没有对比就没有伤害,如果是用命令式编程的思想来处理,我们看看是怎样一个过程:

HR告知每一个节目负责人:“要开年会了,你们有XXXXX元的预算,自己想办法去买,怎么买去哪买自己搞定,记得要发票,拿发票填报销申请,清楚了吗?”

各节目负责人:“好吧。”

HR又补了一句:“对了,买完之后记得告诉我道具有多大,不然不知道租多大车运去年会现场。”

各节目负责人齐声说:“知道了。”

然后,每个节目负责人就去淘宝天猫或者京东上去找道具,和店家讨价还价,下单,要发票,回来之后填报销申请,然后还要告诉HR道具有多大,嗯,每个节目负责人都要忙这么一圈。

我真心希望,你所在公司不是用这种命令式编程的方式来采购年会道具的。

现在,你看到了“声明式编程”和“命令式编程”的差别了吗?

在声明式编程中,开发者要做的事情只是描述“我要的是什么样子”,至于具体怎么做,并不是开发者要关心的事情。在React中,每个组件通过render函数返回“这个组件应该长得什么样”,而不去描述“怎么样去让这个组件长成这个样子”。

在声明式编程的Hulu年会道具采购方式中,HR相当于React,各节目负责人相当于基于React开发的组件,各节目负责人只描述自己需要什么,而具体的采购、报销、运输事务都由HR完成。

与此相对的,在命令式编程的方式下,每个节目负责人都操碎了心,处理的事务很多,各组重复劳动不说,还容易出错。

声明式编程的好处

声明式编程让开发者的工作简化了

在年会的例子里,HR和各节目负责人的接口清晰而简单,节目负责人不用操心怎么买,不用操心怎么报销,不用操心怎么运输,专心搞艺术创作就行。

当然,有人也许要抬杠,说:不还是有HR在操这些心吗?

一个人操心总好过一群人操心吧,而且,我相信HR比你更会讨价还价,也更会买。

React也一样,也许你能够用jQuery写出超厉害的代码,但是React处理DOM更专业,不会比你处理得更差。

声明式编程减少了重复工作

各节目负责人的采购和报销,其实都是重复的劳动,毫无创意可言,这种事情交给HR统一来操作,肯定会效率更高,而且不容易出错,简单说,HR干这些事情专业啊,专业的事情就交给专业的人去做。

React让开发者不用再记忆jQuery那变幻无穷的DOM操作方式了,一样也是避免了重复劳动,减少了出bug的可能。

声明式编程留下了改进的空间

假如说,突然发现我司突然有人贡献了一个超级会员卡,在某电商网站上买东西一折优惠,我们当然想要用上,因为这是一个巨大的改进。

在命令式编程风格下,因为每个节目负责人自己操作采购,那就要把这张超级会员卡送到每一个节目负责人手上去买;在声明式编程风格下,各节目负责人不操心采购,只要把这张卡交给HR一个人就搞定了。

在React的世界里,如果React有一个重大的内部结构改进,比如React Fiber,虽然算法改头换面,但是组件却几乎不用改,因为组件只操心“显示什么”而不操心“如何显示”啊,当然不受影响了。

声明式编程提供了全局协调能力

还是举个例子,假如我们的年会节目预算有一百万(我说的是假如),在命令式编程的风格下,HR怎么确保不要超了预算呢?如何防止预算没有被充分使用呢?

似乎没有好办法,要是完全靠各组负责人自觉,保不准某个组真的买了九十九万的道具,那就完了,所以,一般HR用平均分或者给按人头给每个组一个报销额度上限,超额部分不给报销,这样当然可以避免超支。

但是,也有可能某些组比较朴素,群口响声,道具只买了十几个折扇,这样就白白浪费了预算,HR完全不知道如何协调,因为这些采购操作都是各组操作的,不到报销的时候她不知道钱怎么花的呀。

在声明式编程的风格下,各组的采购都由HR来控制,HR就能够全局控制一下,发现某组实际想要买的道具价格很低,那其他组的道具就可以多花一些钱,这样一百万基本都能花光,这样一来,预算就充分发挥作用了。

HR也不用要求各节目负责人上报道具大小,因为收货人是HR,她自然知道道具是多大。

在React的未来,每个组件还是只声明“想要画成什么样子”,但React却可以改进协调算法,让React组件根据不同优先级来渲染,提高用户感知性能,但是React组件的代码不需要改变,也是一样的道理。

总结

希望这个年会的例子能让大家加深对声明式编程的理解,也祝愿大家下次有一个快乐而不操心的年会

Rate this post

发表回复

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