Skip to content

Latest commit

 

History

History
161 lines (115 loc) · 4.87 KB

20221016.md

File metadata and controls

161 lines (115 loc) · 4.87 KB
Raw

开会小结

20221020下午16时

Camel-Case 驼峰命名

体现在：

  1. 函数以及各种变量命名
  2. json字段也需要符合驼峰规则

Logger日志规范

  1. 不要写中文
  2. 开头不要英文大写
  3. 简洁明了的提示给技术人员报错内容（对象是开发者，不是用户）
  • 错误示范：
e.Logger.Error(err)
e.Error(404, err, "您输入的关系类型有误！只能是 认领 或者 关注 关系")
  • 修改为：
e.Logger.Error(err)
e.Error(404, err, fmt.Sprintf("invalid req.type %s",req.Type))

常量命名

如果有一些数据库字段为常量，不要在业务逻辑里赋值写死

错误：

if req.Type == "认领" {
	err = s.InsertClaimRelationship(&req)
} else if req.Type == "关注" {
	err = s.InsertCollectionRelationship(&req)
} else {
	e.Logger.Error(err)
	e.Error(404, err, fmt.Sprintf("invalid req.type %s",req.Type))
	return
}

正确做法：

在DTO中添加常量，然后替换之前硬性规定的字符串，方便后续增删修改命名

const (
	claim = "认领"
	collection = "关注"
)

关于结构体和uri

1、明确dto中的结构体是接收前端json请求体

2、明确models中定义的结构体面向数据库

3、Update和Insert的大部分字段都相同，可以使用同一个结构体，尽量减少重复代码

4、uri字段不会通过json传递，因此不需要在dto的结构体里使用uri标签，使用c.Param()进行传参

错误示范：如果用户输入PatentId不是int类型，服务器panic之后无法掌控，因此写到api中使用c.Param()进行传参，然后进行一个类型的判断，如果类型转换失败（从路由的string转化为PatentId真正的类型int），可以自定义err报错日志，避免不可预知的错误。

type UserPatentObject struct {
	UserId   int    `json:"UserId" gorm:"size:128;comment:用户ID"`
	PatentId int    `uri:"patent_id"`
	Type     string `uri:"type"` //路由对大小写敏感
	common.ControlBy
}

修改：strconv函数和c.Param函数

req.PatentId, err = strconv.Atoi(c.Param("patent_id"))

报错：reflect: NumField of non-struct type *dto.UserPatentObject

非结构体类型的数字字段：*dto.UserPatentObject

修改：Bind(&req)为Bind(req)

req := dto.NewUserPatentClaim(user.GetUserId(c), 0, user.GetUserId(c), user.GetUserId(c))

	err := e.MakeContext(c).
		MakeOrm().
		Bind(req).
		//修改&，本来是
		MakeService(&s.Service).
		Errors

	req.PatentId, err = strconv.Atoi(c.Param("patent_id"))

原因：该req是一个函数的返回值，看看函数NewUserPatentClaim的返回值类型是:&UserPatentObject，因此不需要再加地址符&

func NewUserPatentClaim(userId, patentId, createdBy, updatedBy int) *UserPatentObject {
	return &UserPatentObject{
	......
	}
}

关于GIT协作

写到关系表的CRUD需要修改其他人的go文件时，需要先进行沟通，不要自己改，不然merge会冲突，解决很麻烦

关于合并关系表

不要单独把关系表的CRUD和models分开写，经过讨论，按照以下内容分模块完成

1、Patent及其关系表都合并入Patent：

包括User_Patent、Patent_Tag、Patent-Package相关内容合并入Patent

2、Tag及其关系表都合并入Tag

包括User_Tag

3、Package及其关系表都合并入Package

包括User_Package

4、不要暴露关系表的路由接口，以功能为单位暴露接口，而不是以简单的CRUD，CRUD都写在service里，而Api就是组装Service为一个功能。

关于路由命名规则RESTful风格

参考： https://restfulapi.net/resource-naming/

简单来说就是/资源/id method表示做什么

api/vi修改为api/vi/user-agent

关于API和SERVICE

  1. 业务逻辑尽量封装在Service
  2. Api内的判断能少则少

Git报错整理

PULL

Your local changes to the following files would be overwritten by merge

解决：确实保留了本地的修改，慎用reset回退，除非确认不想要了

git stash
git pull 
git stash pop

随后提示Dropped refs/stash就是成功了，可以再检查一下

git stash：备份当前工作区内容，从最近的一次提交中读取相关内容，让工作区保证和上次提交的内容一致。同时，将当前工作区内容保存到Git栈中 git pull：拉取服务器上当前分支代码 git stash pop：从Git栈中读取最近一次保存的内容，恢复工作区相关内容。同时，用户可能进行多次stash操作，需要保证后stash的最先被取到，所以用栈（先进后出）来管理；pop取栈顶的内容并恢复 git stash list：显示Git栈内的所有备份，可以利用这个列表来决定从那个地方恢复。 git stash clear：清空Git栈

参考：https://blog.csdn.net/ydm19891101/article/details/104505624/