巴拉巴拉原则代指各种使代码更优雅的原则
写代码的人都希望代码整洁漂亮,也肯定搜索过不少文章,想要学到高内聚低耦合、开闭原则等等等等心法。但是真正动手开始写时,把自己知道的各种技巧都用上,却总觉得代码并不符合这些原则。使人无端产生一种挫败感:我懂得了这么多道理,却写不出好代码。
因为这是一个量变产生质变的过程。只有当你画出最后一笔,你画的人才看起来是个人。有一个单词不认识和所有单词都不认识是没有本质区别的,但是全部单词都认识的那一刻,就突然可以理解整句话了。只有当你键盘下的代码的方方面面都足够好,你的代码才是真正符合巴拉巴拉原则的。
而网上的大部分文章只会告诉你什么是巴拉巴拉原则,却对如果做到闭口不谈。
要做到这一点,必须审视自己写下的每一行代码:
- 嵌套的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模版源码。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。