共计 2927 个字符，预计需要花费 8 分钟才能阅读完成。
前言
进入公司一年多，总结一下这一年针对我的项目优化倡议，其中局部曾经齐全施行，局部因为工夫、老本等各方面的起因未能实现进行结束，局部问题还须要持续察看
我的项目目录结构图
├── 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 通过社区严格校验的考验
- 后续开发局部人员经验不足，我的项目负责人没有对我的项目品质进行管控，导致一份谬误设计到处扩散
- 我的项目开发期间人员变动比拟大，没有对立我的项目开发标准
一年的对我的项目的思考教训所得，我的项目如何不变成屎山是很考验我的项目负责人的能力，如何管控我的项目品质、如何对立开发标准、如何面对人员的频繁变动等一些问题值得持续思考；
如有教训虚心求教
