一、技术选型
选择技术稳定、大部分成员都掌握的语言和技术，减少技术壁垒造成的维护成本大的问题。针对团队小，项目节奏快，非核心功能，我们就实际一点，选型时尤其是非核心功能， 没必要因为一个不重要的功能，专门投入人力维护它。
失败案例：团队前端有10人，核心业务都在B端的vue开发上。后来评估有一小部分功能要平行在APP端开发。当时恰逢Flutter技术兴起，我们就选择了使用flutter实现APP端的功能。后期就发现了多个棘手的问题：
1、前端人员中抽调两个专门学习dart语言及flutter技术，后期这两人在APP端忙的时候主要做APP开发，APP端工作少时，穿插着帮助其他干活，这两人后来都出现了部门变更，导致APP端工作无人接手，重新培养两个人学习Flutter；
2、这两个人员要懂所有的模块业务。APP端的工作量不多，但是涉及的模块和业务却非常多。B端的人员安排，都是一个人固定开发一两个模块的功能，还不具备掌握全部业务的人员。而APP端的人不仅面临新技术的学习，还有全系统业务的学习，经常出现修改引入新问题的现象出现，代码质量无法保障；
3、因为APP端功能少，业务设计和需求变更时，经常忘记APP端的设计，导致APP端始终在补齐B端的功能，却始终赶不上B端的变化。因为B端和APP端公用一个接口，经常出现接口变动后，APP端不知情，被动修改bug的情况频频发生。
以上APP选型换成uni-app的话，以上三个问题就不会存在，B端和APP端一个人负责，修改B端时APP端就一起修改了，他也只需要掌握自己这个模块的功能即可。
这个案例，是有一定的要求的
二、基础设施建设
1、公共组件要先行，并有人看管和维护，且确保API帮助有固定访问地址。开发自己的公共组件，统一代码风格的情况下，能提高代码可维护性、提高代码质量、避免重复问题、减少后期优化成本等；
2、代码规范要制定并带领大家学习；
3、代码走查要求要宣贯和跟踪
①新组件团队，每天做代码走查，检查2个月
②新人员加入团队，每周做两次代码走查，坚持2个月
4、定期开展规范、要求、知识的培训会议
5、开发工具统一，建议用vscode
6、代码格式化规则统一
7、ESLint代码检视规则统一
8、打包编译要考虑性能：
①公共第三方包，放在CDN上，确保不同服务版本一致，且避免每个服务页面渲染时都要加载一遍公共静态资源，影响页面性能的问题；
②业务公共组件，放在CDN上
三、代码规范
1、【要求】废弃的代码片段，要删除彻底，提高代码的可阅读性，减少维护成本。
如果要删除一个新增功能，则要将新增按钮，以及按钮调用的触发函数、对应的新增弹窗组件、弹窗中依赖的变量以及vuex中的变量，全部删除干净。否则定位问题时，这种扑朔迷离的感觉只会叫人口吐芬芳。
不好的案例：润滑工单删除了新增功能，代码中只是将新增按钮注释掉了，点击事件仍然存在，点击事件需要打开新增弹窗组件代码存在、新增组件依赖的选择设备组件存在。
2、【要求】废弃的代码文件，直接删除，不能保留。后续排查整改时，不知情情况下仍需要花费人力整改验证，一系列操作后发现该文件无用，避免这种情况发生。
3、【要求】代码要持续优化，发现问题及时优化，不能容忍。
不好的案例：翻页组件由于开发人员经验有限，重复定义了“当前页”这个变量：current和pageNum。第一个使用这个组件时人，没有审核就同时使用了这两个变量。赶上项目人员急剧膨胀，大家都拷贝这种写法，以为是项目的成熟经验，导致上百处地方错误使用了这个变量，后面修改都改不过来，代码里一会儿用这个变量，一会儿用那个变量，排查整改难度加大。中间有再次给大家强调这种用法是错误的，但是，仍然没有阻止这个问题的继续发展。如今项目稍微稳定，需要整改也得等待时机。
4、接口定义和调用简洁
①、后端接口设计时，参数要简洁明了，并且尽量相互独立，不能耦合；不相关的参数不要出现在接口定义中，防止后期定位问题参数杂乱理不清头绪；前端调用接口时，要严格遵守接口参数定义，只传接口明确定义的参数，不能多传不相关数据；
②、后端的swagger接口说明文档，要明确说明每个参数的含义、数据类型、以及是否为必填，并持续维护；
③、后端接口定义时，同一个含义的变量，在多个不同接口中参数命名要一致，尽量也要与响应中的变量名称保持一致；不允许出现多个变量同时表示一个含义的情况；
④、接口设计时要遵循功能最小原则。一个接口只解决一个最小的问题。如果将包装物料和散装物料的退料功能设计在一个接口中，两者虽然都是物料，但是退料时两种类型的物料参数重叠的部分较少，大部分参数都不相同（包装规格、包装数等），会导致因参数太多，代码逻辑复杂。并且前端在调用时，分不清楚散装物料需要哪些参数，包装物料需要哪些参数。（接口说明文档不是时刻都出现在眼前的）
5、【要求】有新的业务组件出现时，则停止引用旧组件；避免后期再整改。
6、【要求】每个页面开发，都要按照组件封装的思路设计代码层级结构，以方便后续提取成公共组件；
7、【要求】vue开发规范（风格指南 — Vue.js (vuejs.org)
）
① 文件命名
② 组件命名：组件名应该始终是多个单词，用中划线连接多个全小写单词
③ 文件夹命名
prop 的定义应该尽量详细，至少需要指定其类型
总是用 key 配合 v-for
永远不要把 v-if 和 v-for 同时用在同一个元素上
组件样式要设置作用域
【建议】样式要提取到单独样式文件中，便于换肤
【要求】vue文件中的样式，必须带scoped属性。<style scoped>
【要求】尽量封装成可拼装的小组件
【要求】组件的文件名称，所有单词首字母大写连接在一起，或者全小写用中划线连接起来，例如MyComponent.vue，my-component.vue
【要求】和父组件紧密耦合的子组件应该以父组件名作为前缀命名
四、代码走查
1、走查依据：编码规范
2、走查方式：
①项目组件初期，或新技术使用初期，以开会形式集体对每个人代码进行轮流走查；
②后期人员加入，可以二对一每两天一次或一周两次；
③后期可以通过git合入门禁，对每一次合入进行走查；
3、走查跟踪：走查问题要全部整改并验收；
4、提倡大家互相走查、主动走查
