不止一次接手过复杂的业务功能模块，一开始总是卡在里面，摸着头皮在心里暗骂了无数个深夜。相信你也有过类似的经历。面对复杂的业务逻辑，看代码要花两小时，写代码要花五分钟。最近自己总结回顾一下，以备日后之用。如果有喜欢骗他的同事，可以按照这个方法练习（不保证100%成功）。以我拙见，如有错误请指正。1.如果数据属性过多，多使用数据属性，放置一些不用的key，让属性看起来更丰富，增加理解成本。最好打开带有数据属性的页面前100行，这样会让维护或者参与开发组件望而却步，瞬间尊重组件。这正应了《代码的臭味》所描述的：良药与毒药的区别在于剂量。拥有少量全局数据可能没问题，但数量越大，处理起来就越困难。如图，效果比较好：2.组件输入参数过多的问题。数据属性在组件中。如果你看多了，加上评论，你可能就明白了。在组件中添加过多的props输入参数正好可以避免这种情况。问题是太多的输入参数会使理解变得更加困难。必须先了解父组件中绑定的值是什么，然后再了解子组件中的入参是干什么用的。当然还有更高级的用法，就是让父组件的值和子组件的props名称不一致。这样比较有趣，难度急剧增加。3.耦合mixins和业务代码适当封装mixins可以让代码更容易复用和理解。这不是我们想要的。耦合mixins和业务组件代码可以达到事半功倍的效果。常规做法是业务组件调用mixins的方法和变量。我们反其道而行之，让mixins调用组件中的方法和变量，然后让mixins添加更多的引用。虽然看起来很像mixins，但是没有mixins的功能，让后期想要摆脱包的人无从下手。小Tips：普通的mixins方法会通过添加特殊的前缀来区别于组件方法。我们不能使用此规范使mixins方法更难找到。4.不要封装纯函数。如果有一个非常重要的业务组件可读性很差，势必需要小步迭代重构。不要害怕这种情况。我们的一个小习惯可以让这件事情变得简单。困难的方法是不要包装纯函数方法。纯函数的优点是不引用其他变量，可以方便地移动和替换；让每个方法尽可能引用数据属性。当别人要迁移或替换你的方法时，首先要了解引用的属性和全局变量，然后再进一步，你可以在方法中引入mixnins中的变量和方法，这个小习惯会让他们望而却步。5.使数据结构尽可能复杂使数据结构复杂绝对是一种必杀技。数据结构可以随便嵌套几层循环，看得你目瞪口呆。再加上一些风骚的操作，递归遍历，加上一些判断和删减，写一些难以捉摸的注释，就算是高级工程师或高级工程师，也需要努力一段时间，才能弄清楚真正的业务逻辑是什么。这种方法还有一个好处，那就是你也可能会目瞪口呆，一起陷入一个有趣的逻辑梳理游戏中。6、不要写评论或写看不懂的评论。如果说其他方法复杂费时，那么这个方法简直就是高效。你只需要写一些别人看不懂或者容易被误解的注释，就可以很轻松的把接手代码的同事敲晕。这项技能还取决于个人表现的水平。还可以在评论中恐吓劝阻参与开发者修改功能代码，煽动开发者放弃修改，伤透他们的心。7、让前端逻辑变重良好的分层设计可以让系统变得简单健壮；为了突出前端的重要性，要把逻辑集成到前端，让前端逻辑变得更重，尤其是写一些特殊的代码配置和稀奇古怪的规则。别跟产品跟后台讲这件事情不合理，全往前端塞。当需求重新讨论时，他们会忘记特殊的逻辑，你可以根据代码挖掘很多东西，让你变得更加重要。8、不要封装mixin和组件如果想把功能做得更复杂，就不要拆分UI组件和业务组件，更不要根据业务抽取可复用的mixins，组件尽可能大，一个到两个不等千行，最重要的是五六千行，没有上限，都塞在一个组件里。
