项目开发的一些思考
# 现象
一天的代码5s启动，一周的代码30s启动，一个月的代码1min启动。
卧槽！这代码谁写的！注释都没有...！一个文件几百行呀！我靠~，接口、方法、组件全写在一起！
淦！这又是谁写的，写的啥呀，我靠，我自己写的。。。
# 简单介绍
- 项目：A
- 当前版本：
v1.4.0 - 历史版本：
v1.0.0、v1.1.0、v1.2.0、v1.3.0 - 描述：属于M平台的一个子应用，风格方面保持一致，属于持续迭代状态
- 功能：拖拽、编辑器、svg关系图、流程编辑等
# 几个问题
# 不同场景的项目构建方式
- 工程方案：
umi、webpack、vite - 组件方案：微应用、抽离发布npm包组件、通用组件在不同项目中复制使用
- 技术选型：
Qiankun、React、Vue、JavaScript、TypeScript、Recoil、Dva、Redux
# 需要持续迭代与维护的项目（效率和成本）
- 需求调整：产品需求的变动与迭代，对于已开发完成的代码在受破坏性与可拓展性方面的能力。
- 测试用例：没有功能测试用例情况下所做的改动，会影响或破坏其他功能组件造成未知问题。
- 代码检测：JS弱类型与TS强类型在功能改动的情况下，对开发效率与安全稳定的影响。
# 项目性能及优化
一天的代码5s启动，一周的代码30s启动，一个月的代码1min启动。
- 随着项目的不断迭代，功能和模块越来越多，逻辑耦合越来越深，维护成本越来越高，编译时间不断加长、打包产物不断增加
- 对于可视化、编辑器等体积占比较大的第三方类库应如何处理
- 对于
react-dom、antd这种在多个分离的组件内或微应用内都使用的同一类第三方库如何避免重复引入和打包 webpack项目的配置优化：懒加载、压缩、分包、CDN
# 开发效率
- 对于管理后台类的高重复性组件的封装复用
- 对于常用方法库与自定义方法的共享使用问题
# 规范
强制性规范插件：
- 统一的编辑器规则配置
.editorconfig - 统一的eslint规范配置
.eslint.js - 统一的格式化风格
.prettierrc.js - 统一的git message、git commit规范和提交检测：
.commitlintrc.js
约定式规范：
- 语义化
- 文件、组件、函数方法、常量、样式、type类型等命名规范
- 项目文件及文件夹结构规范
# 分析
结合我司自有项目实例及使用场景分析：
首先，用户端与管理端使用场景及项目复杂程度大不相同，这里是有一定区别的，所以在工程配置及技术等方面可作出一些调整。
管理端：
- 组件逻辑比较复杂，各模块关联耦合比较多
- 所涉及的第三方组件比较多，尤其是一些比较大体积的库
用户端：
- 主要场景是提供给用户使用在管理端已完成配置并发布的应用。因此，这里不存在复杂的配置操作逻辑，更多的是交互和输入展示，而针对这个问题，已把核心组件拆离发布为npm包使用，最终来说就是一个比较简单的，支持登录的管理后台。
- 该项目是可以做的比较轻量一些的
其二，作为自研可持续迭代的项目，在可维护性与代码质量上需要有一定的保证：
- 前面说的一些约定规范和插件可以配合项目
TypeScript的强大之处可充分体现，这里强烈建议使用TS开发，这也是建立在认真编写类型文件的基础上，基本类型定义interface和type几乎可以满足日常大部分场景，泛型使用更多是在复杂组件封装中使用，所以在代码第一层使用中定义好，对于开发犯错和后期维护帮助很大。
针对我自身的情况分析，在开发导航栏配置模块的时候有几点问题：
虽然是在
TS项目中进行开发，但是type类型并没有做到大部分覆盖，有一些是为了快速完成快发，直接any一笔过，有的是因为类型推导出来不匹配报错和警告，而里面可能又掺杂了一些比较麻烦的联合类型和泛型等，为了省事直接any梭哈过，当然核心问题还是自身基础不够扎实，才暴露出这些问题。现实问题而言就是需要加强自身基础和能力提高，只有经常使用才能更熟练，遇到问题在所难免，前期肯定要花费一些时间学习，理解吸收了就搞定了这个问题，如果一笔带过先跳过，下次依旧，而对于自身代码质量和项目质量也会积累到其中。只能看自己，或者收集整理下来，有空研究。一开始对于整体规划与可拓展方面等缺乏全面仔细的思考，虽然客观来说确实很难考虑的面面俱到，但是有个点就是方案要反复思考完善，抽象的思考不贴切，就需要demo实践去了解流程和逻辑，进而加深自身理解，可有效减少犯错的可能，对于陌生功能模块的开发，前期准备很有必要，最好先查询下
GitHub上有可参考的列子，浏览下源码，梳理下逻辑，在git clone下来跑跑看，或者可有经验的同事沟通交流交流，很多时候重在一个正确的思路和方向。实际开发中，功能迭代，需求调整等，需要对当前功能和代码进行各种各样的拓展和改动，这里存在不少问题和隐患。我们暂且认为是在
TS强类型的情况下，认真定义了类型后，首先排除代码执行方面的错误影响。函数、变量、常量、组件等的代码功能的拆分就显得非常重要，在无测试用列的情况下，如果这些代码都拧在一起、耦合性也比较高，在改写代码的时候很容易牵一发而动全身，尽管可以发现比较明显的关联，但不可避免的会影响到其他功能模块。人不是机器，只要写代码就一定会出bug。和react的思想类似，即，每个组件只做一件事，配合TS的检测基本可以避免很多问题了，对于一些具有相对独立功能的组件，且存在复用的使用场景，可以考虑拆分抽象完善发布到公司的公共代码组件库提供同事使用。文档要写~
其三，和后端的接口约定，文档说明，mock自测
- 对于同一类型数据，拿导航栏配置接口举例，保存修改的传参规定的字段formId、action_type、parentId等，在返回接口时就变成了form_id、action、parent_id，这里的parent_id内容都被替换修改了。虽然处理起来也不是很麻烦，但很容易产生误解而出问题。对于字段命名和类型，我觉得前端同学也可以根据自己的需求场景提供给后端同学参考。
其四，没有充分使用第三方库，或有些库几乎没有使用，可以使用优秀轻量的第三方库
其五，对codereview的思考
# 一些收获
- 灵活的框架选型
- 相关代码规范
- 技术方案的思考、技术分享
