便于后期可维护性,增加可拓展性。业务非独自可改变,那便增加编码规范以防屎山。
如数据库字段中常用的状态,类型等等
如此数据必须由后端来控制,前端可以根据此数据做不同的业务,但一定要由后端来控制下发。
由此可延申为字典表。
使用字典表或者前端需要用该数据实现业务等。个人认为推荐不适用字典ID,而是通过标识 如字段表:
ID Name Remark Idc
1 字段名 备注.. /test
此字段 标识为 “/test” 推荐前端做业务或者后端做业务直接使用标识进行匹配
路由命名: /模块名/功能函数名
函数命名:功能实现名
函数之上尽量使用文档注释
如:
- /**
- * 根据ID查找整条记录信息
- * 只查询单条数据
- * @param id 记录ID
- * @return Object 记录信息
- */
- public Object test(int id){
-
- return Object;
- }
首先攥写此函数的目的
其次编写附加条件
传参内容和返回的内容是什么
以至于后期维护时直接可以根据注释推测该函数功能
区分系统模块及业务模块
业务模块使用系统模块功能 由系统模块编写对外开放接口进行调用,此方式繁琐但可以方便记录日志 或进行业务拓展,实现低耦合
日志个人推荐记录方式
级别: IP post /接口路由 耗时 操作账号 函数内信息
如果级别为设定危险级别建议进行邮箱通知,即使进行错误捕获
日志推荐50天为周期(50天的日志足以应对大部分问题,服务器配置高随意)
推荐日志写入单独数据库中 记录所有传参及反参 用户环境等
此操作推荐使用mq进行记录,不过多消耗业务耗时
系统部署推荐使用Linux系统
如win系统,需要编写自启脚本、禁止系统自动更新功能
如使用第三方容器 如nginx tomcat 则备份每次的配置文件
系统开发时可能会使用root账号等
推荐在开发初期及划分数据库账号,开启数据库每日定时备份(即使数据丢失也不至于丢失很多数据),备份推荐服务器本机存储及备份至其他地方 多重保险
开发接口时记录接口版本
迭代开发
便于后期更新迭代
(此操作直接使用git即可完成。做项目一定要使用git进行版本控制,每次上传及完成一个功能,不推荐开发至一半上传一次功能)
编写config文件: 全局公共参数 如小程序appid 或前缀版本 数据库连接方式 等等 全部在同一个文件中编写配置,注入全局。方便后期进行部署或更新。
编写代码:系统编写可以繁琐,但不能乱。每个层有每层的作用。规范开发
redis缓存:推荐高IO数据进行读取redis redis中无进行操作数据库 操作完后先写入redis再获取redis中数据
需求增加:需要项目经理先进行考虑再同开发者沟通,项目经理的好坏决定产品的走向。无理的需求决定项目的上限。增加需求一定需要经过项目经理或者项目带头人
如系统前期架构对后期业务增加困难,考虑是否重构。此想法需要结合公司业务人员进行商讨。切记不可独想。如系统有后续发展空间则进行重构,无则堆屎山。
暂时想到那么多,其余想到再写