前言

进入公司一年多，总结一下这一年针对我的项目优化倡议，其中局部曾经齐全施行，局部因为工夫、老本等各方面的起因未能实现进行结束，局部问题还须要持续察看

我的项目目录结构图

├── 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性能解决热更新慢问题，优化文件目录构造缩小文件层级，针对不同状况创立不同打包指令缩减打包文件范畴

总结

公司我的项目存在着诸多弊病，然而目前存在着船大难掉头的场面，只能逐渐逐点进行修复实现改良；细思这些问题背地的起因大略有这些

  1. 零碎最后搭建人员齐全采纳了开源我的项目，没有依据公司理论的业务的状况进行革新；
  2. 最后抉择我的项目没有抉择像antd pro通过社区严格校验的考验
  3. 后续开发局部人员经验不足，我的项目负责人没有对我的项目品质进行管控，导致一份谬误设计到处扩散
  4. 我的项目开发期间人员变动比拟大，没有对立我的项目开发标准

一年的对我的项目的思考教训所得，我的项目如何不变成屎山是很考验我的项目负责人的能力，如何管控我的项目品质、如何对立开发标准、如何面对人员的频繁变动等一些问题值得持续思考；

如有教训虚心求教