各位客爷大家好，沉寂了一段时间我们又见面了，这次我和大家讨论的方向是javascript的元编程（meta-programming）。

       元编程，什么概念？一个曾经也让我在面试中打磕巴的东西。

搜了一下维基百科：

       “元编程是一种编程技术，编写出来的计算机程序能够将其他程序作为数据来处理。意味着可以编写出能够读取、分析或者转换其他程序的能力，甚至是在运行时修改程序自身。”

       上面这行太官方了，如果理解起来吃力的话无所谓，反正我也看不懂.....😂

       我们不妨从字义上去理解一下，Meta-Programming，Meta 我们将它直译为元，而在西方它代表“关于事物自身的事务”，所以以在下愚见，可以魔幻的理解它是：

所谓元编程，就是用代码去编写代码。

                                                                                            ——前端装逼架构师 Yubble

以下我们逐步来看哈，在学习的过程中，我发现前端的元编程又分为两个方向：

       1、运行时的动态代码生成

       2、运行时的语言结构修改，此处我们通常描述为反射

介于反射在元编程中也占了一大部分知识，所以我们今天先重点讨论下动态代码生成这块儿~

       其实在ECMAscript早期已经出现了元编程方法eval，但是由于此方法安全性差，且在设计初对于动态转化为机器代码的性能缺陷，所以各大书籍以及文章中对它的描述都不予看好，但是他也实实在在的实现了用代码编写代码的原则，如下：

       这段代码意义不大，只是往user对象中塞了一个属性和值，但是它的运行代码是包裹在eval方法中，起码也能说明javascript最开始也是往元编程的方向去靠的.....🐶

        观众大人：“看了这么半天你就让我看这些？”

        各位客爷稍安勿躁，我要拿出点干货了，就是 new Function~🌹

        不知道各位客爷之前有没有了解过这个宝贝，它其实做的事情和eval一样，也是用代码去编写代码，具体区别得您自己百度了，话不多说，先上干货。

业务场景

        我们是一家宠物商店，在这个网站中我们可以查看到对应宠物的信息，价格，出生地等等。

        下面是我们已录入的宠物信息以及后端提供给我们的查询接口：

        此时老板告诉我，要将所有出生地非中国的小动物加价5元（多扯淡，数据这东西让显示层改😂），那么聪明的我们首先先写了这么一个工厂

        聪明的你是不是一下子就看出问题了，怎么每个获取信息方法长得都差不多，不就是调用接口不一样吗？所以聪明的你把这个调用接口与通用逻辑做了一个抽象。

        这样我把类似逻辑全部抽离出来，代码就变得清晰多了，如果还有其他的小兔子、小鸡、小耗子之类的，给动物工厂增加方法就可以了。但是如果优秀的你足够高阶的话，一定还能搞到更加高效的方法，这就是这偏文章的重点，元编程——动态生成。

        我们如果真的要搞元编程，那么就离不开一个概念叫’元数据‘，通常是用来描述我们生成的程序的数据。在这个需求里，DS.apis就是我们的元数据。

        所以，我们可以将DS.apis先传进来，用这个元数据来动态生成方法。

        我们改变了这个动物类的结构，首先获取前面给到的所有api方法，再将api方法便利一次，从而拿到所有api的diff部分，用这些diff部分来调用默认方法define_methods。

        重点来了，define_methods则将我们前面写到的通用逻辑整体包装为一套描述函数内容的字符串，并将这套函数赋予给了Animal的原型。

        这样不管是'get_cat_info'还是'get_dog_info'都可以自动生成出来，不管后面还有什么小鸡、小鸭、小猴子，都可以让他们在元数据上做文章，不需要我们手动在类中添加方法了。

        在使用的时候就是这样：

        就这样，一个勉强的元编程实例编写完了，其实这个实例代表性还有点勉强，如果将id换成仓库id就更有说服力了，第一次查找编号为21的仓库，可以分别查出猫猫与狗狗的信息，第二次再更改个仓库id，查猫猫狗狗信息。这块儿只是给大家看一下元编程的应用能力，各位多包涵哈~

使用缺点

        这种元编程的在工作中也不是面面俱到的。

        首先它创建函数时必须要是字符串的方式，所以可维护性并不强，所以这类代码里最好不要代码业务逻辑。上面这个实例就有待改进，业务和创建原型方法一定要拆开写，不然后期业务变更需要改代码可够受的。

        其次元编程是十分依赖元数据的准确性和标准化的，如果上游数据出现问题，影响到元编程的执行，那么我们排错时就会比较麻烦。

        另外new Function和eval都存在安全方面的隐患，eval更甚，所以这一部分代码我更倾向于埋到底层执行，避免过度曝光。

结论

        元编程中动态创建这一块儿就给各位客官演示完了，根据上面的讨论内容，我们也看到了在元数据提供丰富的前提下，前端动态生成函数、方法的可能性。如果您就职在一家类似ToB的公司，整体为元数据驱动的技术背景下，使用元数据来抽出一层动态方法层是完全可行的。

        终于可以和大家一起聊闲磕了，前段时间刚从上家公司离职，跟老婆一起度了个假，顺便把元数据这块儿整体搞清楚了。说说我上家公司的经历吧，年初入职了一家成立了20年的公司，司内员工基本司龄6年以上，极为抱团，碰他们的代码跟抢了他们饭碗似的，几千行代码一点注释没有，文档或架构图就更别提了。领导的管理水平极为感人，提了些流程优化的意见也好像影响到了她的权威一样。所以和另外一个差不多同期入职的小伙伴不堪重负选择离职了（后来刷了脉脉才知道，这家公司风评很差，疯狂内卷，毁约应届生）。

        劝各位客官，当下虽然是一个互联网的下行时代，我们面临着各种裁员失业，但是也别太心急随便加入一家公司，如果您有一份稳定的工作，一个动力十足的团队就踏实干下去。如果收到了一份offer，多刷刷脉脉，看看这家公司风评如何，加班不可怕，可怕的是大家都卷在了内耗上。