看到一篇博客，讲述如何提高代码品味，对于开发的过程中时刻反思自己的代码结构这句话很有共鸣，结合目前手上项目代码而言，我觉得是缺乏思考的，代码冗余严重，即使使用组件化开发框架，却没有模块化开发的思想，从而导致项目很难维护，部分业务组件过于复杂，容易让人不适。
如何思考
一说代码结构，就很容易想到很多词汇，比如高内聚低耦合、DRY原则、单一职责原则、开闭原则等等，但是真正放到项目中却无法思考了，这里列举集中常见的场景
- 一开始分了两个模块，写着写着发现其中一个模块的体积很大，那就看看能不能再继续分
- 一开始分了四五个模块，后来写着写着发现其中两个模块交互巨频繁，他们必须一起配合才能实现一个完整的功能，那就把他们合在一起（高内聚）
- 在迭代的过程中发现两个模块虽然相互独立，但交互逻辑写得很死，依赖关系很直接，修改了一个，另一个也必须改，那就修改他们的依赖和交互，尽量做到互不影响（松耦合）
- 在迭代过程中发现两个模块的某部分是可以共用的，那就抽出来（DRY）
- 在迭代过程中发现某个模块的一段代码变更很频繁，那就单独把这部分抽出来（封装变化）
说是这么说，但是要求团队每个人达成共识，却很难实现，必须建立起某种约束，来保障项目健康迭代，比如code review、Lint结合git hook强校验等
我们有很多约定俗成的“潜规则”其实都有它背后的逻辑，譬如以前天天说的 MVC 和 MVVM 两个模式，他们的最主要区别不在于模块划分，而是模块间的交互，在划分方面它们都致力于让 UI 和逻辑分开，为什么呢？因为 UI is cheap，UI 是隔三差五会被设计师推翻再来一套的，但逻辑和数据，相对会稳定一点，所以把他们分开，UI 迭代的时候涉及的改动就比较小。那为什么前端的 React/Vue 这些近年大火的框架，又提倡所谓的组件（Component），貌似 是要把 UI 和逻辑搞在一起呢？其实不是的，组件是一个小粒度的模块，它相对独立，具有很高的内聚性，组件中的“逻辑”更多的应该是 UI 相关的交互逻辑，而不是那些比较底层的逻辑，我们还是应该把相对稳定的逻辑抽出来放到更下层。
思考上述，作者是有一定道理，似乎更加理解，React自称会有个UI层框架，而很多不规范的团队，并没有相对稳定逻辑抽出来放到更下层，而是揉在了一起，这里值得思考！
命名很重要，最近推崇的零注释编码，也是强调命名的重要性。
大到业务模块小到辅助函数，只要你觉得不好命名，那就是一个信号，说明这段代码做的事情太多太杂，以至于你无法用几个单词概况出来。
哇晒晒