前言

不止一次接手过复杂业务功能模块，开端总是深陷其中难以自拔，无数个深夜抚摸着头皮在内心暗暗咒骂。

相信你也有过类似的经历，面对复杂的业务逻辑，看代码俩小时，写代码五分钟，没有点胆识和谋略都不敢下手。

最近总结复盘了一下，以备后用，如果有喜欢的同事想坑他一把，可以按照此方法实践(不保证100%成功)，个人拙见，如有不当望指正。

目录

1. data属性数量过多
2. 组件入参数量过多
3. mixins和业务代码耦合
4. 不要封装纯函数
5. 数据结构尽量复杂
6. 不写注释或写无法理解的注释
7. 将前端逻辑变重
8. 不封装mixins与组件

正文

1、data属性数量过多

要多用data属性，放置一些用不到的key，让属性看起来更丰富，增加理解成本。

最好一打开页面前100行都是data属性，让维护或者参与该组件开发的人员望而生畏，瞬间对组件肃然起敬。

这符合代码的坏味道所描述的：

良药与毒药的区别在于剂量。有少量的全局数据或许无妨，但数量越多，处理的难度就会指数上升。

如图所示，效果更佳：

2、组件入参数量过多

data属性的问题是在一个组件内，看多了加上注释可能就理解，而组件增加过多的props入参恰好能避免这个问题，过多的入参可以让理解变得更困难，要先理解父组件内绑定的值是什么，再理解子组件内的入参用做什么。

当然了，还有高阶一点的用法，就是让父组件的值和子组件的props名称不一致，这样做就更有趣了，难度陡增。

3、mixins与业务代码耦合

合理封装mixins能让代码变得更容易复用和理解，这不是我们想要的，让mixins与业务组件的代码耦合在一起，可以达到事倍功半的效果。

常规的做法是业务组件调用mixins的方法和变量，我们反其道而行之，让mixins调用组件中的方法和变量，然后让mixins多出引用，虽然看起来像mixins，但是并没有mixins的功能，让后期有心想抽离封装的人也无从下手。

小Tips：常见的mixins方法会加上特殊前缀与组件方法区分，我们可以不使用这个规范，让mixins方法更难被发现。

4、不要封装纯函数

如果有一个很重要的业务组件可读性很差，势必要小步快跑的迭代重构，这种情况也不用怕，我们一个微小的习惯就可以让这件事情变得困难重重，那就是不要封装纯函数方法。

纯函数的好处是不引用其他变量，可以轻易的挪动和替换； 让每个方法尽量引用data属性，当他人想迁移或替换你的方法时，就要先理解引用的属性和全局变量，再进一步，可以在方法里再引入mixnins里的变量和方法，这个小习惯就会让他们望而却步。

5、数据结构尽量复杂

让数据结构变复杂绝对是一个必杀技，数据结构随随便便循环嵌套几层，自己都能绕晕。

再加上一些骚操作，递归遍历加一些判断和删减，写上让人难以琢磨的注释，哪怕是高级工程师或是资深工程师都需要狠狠的磕上一段时间才能摸清真正的业务逻辑是什么。

这种方式还有另外一个优点，就是自己可能也会被绕晕，一起陷入有趣的逻辑梳理游戏。

6、不写注释或写无法理解的注释

如果其他方式都复杂且耗时，那这种方法简直是高效的存在，只需要胡乱的写一些让别人看不懂或容易误解的注释，就可轻松把接手代码的同事KO掉。

这个技能也看个人发挥的水平了，你也可以在注释中恐吓、劝阻参与开发人员改动功能代码，煽动开发人员放弃修改，让其内心崩溃。

7、让前端逻辑变重

良好的分层设计能够让系统变得简洁和健壮；为了凸显前端的重要性，应该将逻辑一股脑的承接到前端，让前端逻辑变重，尤其是写一些特殊的编码配置和奇葩规则。

不要和产品、后端讲述这件事情的不合理性，统统塞到前端，当需求被重新讨论时，他们会把特殊逻辑忘的一干二净，而你可以根据代码翻出一大堆，这样你就显得尤为重要了。

8、不封装mixins与组件

如果要让功能变得复杂，就不要拆分UI组件和业务组件，更不要按照业务抽离可复用的mixins方法，让组件尽量大，轻则一两千行，重则五六千行，不设上限，统统塞到一个组件里。

结尾

结合自己的踩坑经历写了这边偏笔记，调侃之处，纯属娱乐。你有没有遇上过类似的场景，你的感受如何？又是如何解决的呢？敢不敢点个赞，一起评论区讨论。