代码过程中出现的种种问题
例如：
重复定义接口，组件；
废弃的组件没人敢删；
store数据重复定义；
业务表单字段控权逻辑复杂，越维护越多之前的没人敢动；
一套代码兼容多地区业务中，没有对多地区业务做隔离导致的“改了东坏了西”。
大多人员没有写注释的习惯。
这些种种的问题暴露出一个很大的问题，就是代码缺乏管理，团队临时拼凑组建，权责不明确，该做好管理工作的人没有把好关，在代码设计思路上没有与其他人达成统一，最终形成统一的开发指导规范。
代码设计上的理解
代码设计原则
单一职责原则SRP：一个对象/方法只做一件事。例如：单例模式，代理模式，装饰模式，迭代器模式等
最少知识原则LKP：减少对象之间的联系，避免改一处，相关的多个对象受到影响。例如：中介者模式
开放-封闭原则：好的设计应该在遇到新需求的时候去增加代码，而不是修改旧代码。例如：发布-订阅模式，模板方法模式，策略模式，代理模式，职责链模式
业务组件重构思路
1. store
公共信息只在store维护一份。
从分层角度：store分为全局级别，子系统级别；
从维护角度：为了避免多人协作开发中store信息重复声明，action重复编写。store在全局以modules方式分类维护保持一份。
最终策略：系统全局系信息在store维护以modules方式维护，各个子系统需要哪个就在系统自己的store中注册进去。
store的拆分尽量以业务原子功能为单位，比如：登陆注册，账户，项目，统计，审查，抽查，上传下载，人员管理，权限管理等。
一些系统级别的store数据（state）初始化逻辑，可以在aop层面去考虑着做（比如路由钩子中），在具体业务模块，只需要从getter中拿来直接做业务逻辑。
数据引入方式：
// 直接引用方式
getProject () {
return this.$store.getters['projectModule/getProjectInfo']
}
// 辅助函数方式：直接引用accountModule模块中的getters
...mapGetters(
'accountModule',
['getAccount']
)
// 辅助函数方式：引用accountModule模块中的getters，可以起别名
...mapGetters(
'accountModule',
{ getPermissions: 'getPermissions' }
)
2. 业务组件结构
从分层角度：
组件内部是view层，纯展示，包含自有的跟业务无关的交互功能；
外部是业务container层，负责接收业务数据，整理成组件能识别的数据结构，同时负责接收view组件的反馈，以便向外层传递数据。
从分类角度：
尽管功能类似，但是使用场景和展现样子完全不同的组件分割成2个，不要揉到一起，避免不必要的耦合。
container层如果包含了无交叉的业务线，使用设计模式给分隔开来，避免不同业务逻辑互相影响。
3. 代码拆分组合实现细节
目前比较倾向于mixin，在vue组件中，使用mixin可以很自然的把抽离出来的规则或者配置再融入到业务组件中，可以方便的使用上下文。
mixin文件内部：
抽离工具方法
引入配置
组装mixin对象
这里有个细节问题就是，vue框架内部用的是严格模式，在confC里面不允许直接使用arguments，所以声明了参数
个别业务配置内部：
业务组件中使用：
4. 关于组件的交互控权
这个相对复杂，一个组件整体，或者一个组件内部的输入项，都可能需要单独控权。
最终控制的效果有2种：display和disabled，最终使用哪种跟业务需求有关。
影响的因素有很多：
1）组件自带交互操作或者联动效果。
2）权限控制（模块级权限？更细的操作级权限？跟系统的权限设计有关,有些特殊的场景游客权限就能操作，可以前端把权限整合到store统一处理）
3）角色控制（角色本质上还是权限，可以看作一个权限包，这个跟系统设计有关，很多时候后端权限控制没有那么精细）
4）流程控制（包括新建，保存，提交，回退，完结等）
5）系统配置（类似于实施过程中配置的业务参数）
以上的因素在不同业务系统中可能不一样，但是有一点肯定的是，随着业务的迭代，影响因素会越来越多，代码如果不把控好，就会变得越来越难以维护。
组件或者组件的输入项，影响它的交互（display和disabled分开处理）的因素（以上的5种）不能重复声明,否则会开启挖坑模式，越来越难维护。
打个比方：v-if=“规则1 || 规则2 || 规则3”，这个规则1规则2规则3都是迭代过程中追加的控权逻辑，如果有2个都包含权限的引入判断，就是不允许的。
下图是某版本的代码，重在描述意图：
computed中：
表单模板中：
5. 关于组件传参
1）有些页面需要用的业务参数繁多，是因为后端接口设计不够优雅，对前端暴露了太多细节，让前端处理。例如一个业务行为要调多个接口，或者一个数据请求要传很多辅助参数。这些情况需要后端的接口优化，前端配合调整，才能做好。
2）还有些业务参数的传递，是从父组件到子组件链式传递的，尽量不要这么做，如果需要，可以考虑把业务参数声明在store中，注册进当前子系统，在更高的层面统一管理，这也是一种发布-订阅模式，满足了最小知识原则。
网友评论