巴拉巴拉原则代指各种使代码更优雅的原则
写代码的人都希望代码整洁漂亮，也肯定搜索过不少文章，想要学到高内聚低耦合、开闭原则等等等等心法。但是真正动手开始写时，把自己知道的各种技巧都用上，却总觉得代码并不符合这些原则。使人无端产生一种挫败感：我懂得了这么多道理，却写不出好代码。
因为这是一个量变产生质变的过程。只有当你画出最后一笔，你画的人才看起来是个人。有一个单词不认识和所有单词都不认识是没有本质区别的，但是全部单词都认识的那一刻，就突然可以理解整句话了。只有当你键盘下的代码的方方面面都足够好，你的代码才是真正符合巴拉巴拉原则的。
而网上的大部分文章只会告诉你什么是巴拉巴拉原则，却对如果做到闭口不谈。
要做到这一点，必须审视自己写下的每一行代码：
- 嵌套的if else好吗？
- 能不能不过于依赖if else来实现流程控制？
- 状态变量定义在方法外，是否导致程序的语义更模糊了？
- 这个for循环能否用函数时变成代替？
- 能否用函数柯里化简化参数传递和方法调用？
- 能否用闭包使逻辑更内聚力，避免逻辑分散在不同方法中？
……
等等等等
无数个这样的小技巧组成了符合巴拉巴拉原则的代码。
每一次应用这些小技巧，都导致代码的巴拉巴拉指数增长了一点。当应用了世界上所有的这种小技巧时，就能写出巴拉巴拉指数满分的代码。
也就是说，这是一个积累的过程，当积累到足够多的小技巧时，代码就会趋于完美。
毕竟，连大厂如Facebook，从mixin到High order component到render props到Hooks，连他们都在挣扎寻找实现巴拉巴拉原则的技巧。广大业务代码编写人员觉得迷茫，更是很自然的事情。
不过，不同于上面列举的例子，也存在一些会显著影响代码质量的技巧。
目前前端框架，把数据和UI分开。更改数据，UI就会自动更新。这里面缺少了框架作者不会关心，业务代码编写人员却天天面对的一块：业务逻辑写在哪里？
以Vue为例：
写在Vue的组件里会导致业务逻辑和UI强耦合，并导致业务逻辑被迫按照页面的不同被分散在不同的UI组件中。
导致目前最常见的代码写法，不仅不符合巴拉巴拉原则，反而符合反巴拉巴拉原则。
正确的做法应该是UI组件里只存在UI相关的逻辑。业务逻辑全部写到Vuex里面，UI组件只负责发布action和mutation高速Vuex改更新了。
这样做，UI组件会自然按照设计师的设计分散在不同的组件里。业务逻辑也会按照产品的设计分散在不同的Vuex模块里。而且，因为高内聚的业务逻辑代码，原本由于低内聚高耦合代码导致的难以维护不复存在，写新需求、debug过程会变得十分自然。
具体写法，可以去看看Vue-element-admin模版源码。
