前言
进入公司一年多，总结一下这一年针对项目优化建议，其中部分已经完全实施，部分因为时间、成本等各方面的原因未能完成进行完毕，部分问题还需要继续观察
项目目录结构图
├── public # 不参与编译的资源文件
├── src # 主程序目录
│ ├── index.js # 程序启动和渲染入口文件
│ ├── config.js # 全局配置
│ ├── components # 全局公共组件
│ ├── utils # 公共工具类
│ ├── assets # 资源文件
│ ├── layouts # 页面结构组件
│ │ ├── BasicLayout # 基本布局
│ │ └── OtherLayout # 布局组件根据具体功能调整，在路由配置中引用
│ ├── routes # 动态路由目录（每个功能一个文件夹的MVC结构）
│ │ ├── index.js # 所有子系统路由入口
│ │ ├── Common # 子系统公共路由,如登录页、404、403等
│ │ │ ├── Account # 个人中心页面
│ │ │ ├── Login # 登录页面
│ │ │ │ ├── index.js # 路由配置文件
│ │ │ │ ├── components # 页面组件
│ │ │ │ ├── model # dva model
│ │ │ │ ├── service # dva service
│ │ │ │ └── routes ** # 子路由(目录结构与父级相同)
│ │ │ └── *** # 其他公共页面
│ │ ├── IAMS # 子系统：后台管理系统
│ │ │ ├── index.js # 子系统路由入口
│ │ │ ├── config.js # 子系统路由配置文件
│ │ │ ├── System # 一级目录
│ │ │ │ ├── Users # 二级目录
│ │ │ │ │ ├── index.js # 路由配置文件
│ │ │ │ │ ├── components # 页面组件(如果有)
│ │ │ │ │ ├── model # dva model
│ │ │ │ │ ├── service # dva service(如果有)
│ │ │ │ │ └── routes ** # 子路由(目录结构与父级相同,如果有,三级子路由统一用subAdd、subDetail 等命名)
│ │ │ │ └── *** # 二级导航/其他
│ │ │ └── *** # 一级导航/其他
│ │ └── *** # 子系统/其他
项目目录层级过深
以IAMS/System/Users/routes/*为例，当我需要创建Users下的子页面的时候需要到相对于routes第六层文件夹下去创建页面文件夹，文件夹内子页面还可能继续存在文件夹，不方便日常开发展开查找
解决方案：目录层级不划分二三级，全部采用一级目录,即IAMS下就是各页面文件夹。相关子页面可以通过命名区分入口，例如User文件夹下可以建立detail.js、edit.js等相关子页面，model/components统一放到一个文件夹下
项目路由注册方式不合理
结合上面目录机构图，目前的路由的注册方式是通过每个文件夹下的index.js导出Route,然后在上层index.js导入下层全部index.js最后在routes下的index.js聚合。当我们需要新建一个页面文件夹的时候就需要再文件夹下建index.js文件导出Route，并且再依次去上层文件夹下导入，过程操作繁琐。同时目前每个子系统（例如IAMS/config.js）下还拆分出来了一个文件，提取了类似所有子路由的公共前缀、标题等信息，导致路由注册都需要引入这个文件整个操作更加繁琐
解决方案：在子系统下新增router.js文件，系统下所有页面路由集中在该文件注册，然后汇总到routes/index.js下创建路由；同时删除每个页面文件夹下的index.js文件，删除IAMS/config.js文件
文件保持单一性
例如untils/pageHelper下requestFormat方法是直接关联src/config.js内部的pageHelper.requestFormat 方法;
解决方案：遵从单一性原则建议pageHelper相关统一到pageHelper目录下，或者在需要的地方引入config.js不重新关联到pageHelper下
第三方模块文件夹划分不清晰
目前部分第三方模块像lodash md5 moment 在utils文件夹下重新导入导出类一次
解决方案：可以考虑取消这一层导出，直接使用时import即可
第三方组件封装存在问题
项目内对antd组件的封装导致了官方原有配置失效，新增了一些私有属性，新增了dom嵌套层级影响默认样式，同时这些更改缺乏必要的文档说明；
解决方案：封装应该基于增量的方式去处理，不应该破坏原有配置，并且必须要有组件说明问题
自定义管理状态管理混乱
例如弹窗组件设计的时候会从外部传入visible控制显示隐藏，但同时又在内部state设置visible属性控制显示隐藏，然后通过例如componentDidUpdate周期获取变更重新更新state；
解决方案：对于相同功能不设置多个状态来管理，统一外部或者内部管理，如果外部管理可提供方法到内部进行调用
前后端数据格式统一
例如分页格式
前端：{ pageNum,pageSize}
后端：{ currentPage, pageSize}
下拉数据格式
前端：{value,name}
后端：{ code,codeName} | { id,name}
解决方案: 后续对于这类公共数据，应当采取前后端统一格式，考虑到前端UI组件使用antd有自己的数据格式，后端进行调整更加合理
项目代码数据管理方式错误，滥用dva modal
项目中不管是临时数据还是长期数据都放到了dva modal,部分类似详情页面数据也存在了modal，导致部分开发人员启用了if1等变量区分是否第一次加载，页面卸载是也没有进行数据清除等不规范设计
解决方案：设计之初应当结合业务实际情况考虑数据的生命周期，类似详情数据这类临时数据可用存放再内部state，跟随组件生命周期自动销毁
CSS样式问题
目前项目中未对css书写做限制，存在大量全局样式，冲突严重，存在大量!important
解决方案：禁止使用！important；禁止写全局样式；需要覆写的样式新增类名增加权重去覆写；使用css modules管理样式
热更新、打包时间过长
目前项目热更新需要时间10s+,打包时间在3m左右
解决方案：替换create-react-app方案，采用webpack自定义配置针对性优化，开启cache功能解决热更新慢问题，优化文件目录结构减少文件层级，针对不同情况创建不同打包指令缩减打包文件范围
总结
公司项目存在着诸多弊端，但是目前存在着船大难掉头的局面，只能逐步逐点进行修复完成改进；细思这些问题背后的原因大概有这些
- 系统最初搭建人员完全采用了开源项目，没有根据公司实际的业务的情况进行改造；
- 最初选择项目没有选择像antd pro经过社区严格校验的考验
- 后续开发部分人员经验不足，项目负责人没有对项目质量进行管控，导致一份错误设计到处扩散
- 项目开发期间人员变动比较大，没有统一项目开发规范
一年的对项目的思考经验所得，项目如何不变成屎山是很考验项目负责人的能力，如何管控项目质量、如何统一开发规范、如何面对人员的频繁变动等一些问题值得继续思考；
如有经验虚心请教