使命: 保证项目成功
职责: 履行研发项目经理的管理角色，通过自身的影响力,运用科学的项目管理方法和工具进行高效的项目管理
作为整个项目的项目经理，要把控项目的整体进度，所以对需求及细节一定要了解的非常透彻仔细。
需求下来时，一定要将需求细化到开发，不要只听表面需求，到最后开发的时候才发现无法落实。
eg: 哪怕是简单上传下载，也要确定细化到文件格式
很多时候，项目组成员能力都是参差不齐，这个时候人员模块分工，把合适的人放到合适的位置则显得尤为重要
- 成员是否有其他项目在并行
- 成员是否有类似项目经验
- 成员之间是否熟悉
- 重复功能、技术攻坚模块是否单独提出来
大多数时候成员与成员之间的交互之中总有部分责任界限不够清晰，
- 前后端对接方式不同 eg:返回文件流还是base64
- 前端还是后端做 eg:项目经理要合理规定参数验证、分页、格式化等
- 多个成员员风格不一致 eg: 确定风格，以什么模块，或以某个成员为样板
不同的成员、项目经理之间的知识面是不同的，认知出现偏差是很常见的现象
- 有的前端也许只关注于接口的调用，他的认知面里也许只有接口的返回成功还是失败，你不能指望他在不懂业务逻辑的情况下看懂操作还是数据是否具有合理性
- 有的后端也许只关注于单个功能的实现，他的认知面里面也许不包括多个模块之前的联动是否具有合理性
- 了解每个成员的认知面和局限性，合理分工，放平心态，就能有效的避开大多数的争论
开发经理是解决问题的人，而不是提出问题的人，提出的问题一定要有解决方案，而不是提出无法解决的问题
虽说工具只是手段，实现才是目的，但是一定程度的技术面可以让你更加得心用手
页面组件
对于页面设计满足不了的前端的时候，这个时候总需要一个人来对UI页面进行定稿
框架常识
VUE的双向绑定
UI是弹性布局还是dom
是否是微服务，测试阶段是通过URL访问麽
常用组件
F12看接口调用
格式化窗口
常用快捷键，上下层跳转
类型转换，弱类型变更
文件模板
nacos和feigin
是否一个方法一个class
自动生成文件 eg:T4,Mybatisplus
底层框架 eg:mapper.list .page–> selectIdPage ，切面缓存锁自动释放
删数据库备份，数据库更新脚本
视图为虚拟表
left和join，on先筛选，查询数据库json字段
是否索引，多库多表连接查询
版本发布日志
查看提交记录 eg:一次不提交，全体加班
发布权重、滚动更新
版本定稿，sql脚本记录
日志等级，不确定的模块整体都要写日志，第三方对接也要写日志
整个发布流程，是否自动更新
错误排查顺序