赞同 1
分享
刷新
代码仓库的规范建议
简介：GIT中，混乱的、缺失的、语义不清的commit是代码仓库管理与软件版本管理的巨大阻碍，我们可以找到一个行业内公认的、通用的表述来统一commit的风格标准。
2024.01.23
Bug Man
1
39
172.17.0.1
中国.上海
项目规范
代码仓库的规范建议：
先定义一下什么是好的代码仓库提交记录，我认为首先应该是粒度足够细致的，其次是描述尽可能做到贴切（涉及到模块/功能名称定义，不能够有产生歧义的叫法），以这两点作为前提还可以再仓库管理上下功夫，如：合并master分支用pull request替代，可以让管理员做一次代码审核后同意且合并（当下团队小，项目以敏捷见长，这一点可以暂不做考虑）。
https://open.leancloud.cn/git-commit-message/
| 类型 | 说明 |
|---|---|
feat |
feature - 所有实现新功能、新行为的 commit 都属这个类型 |
fix |
修正缺陷的 commit |
chore |
日常维护性的改动，例如 linter 的配置等 |
test |
与测试有关的改动 |
refactor |
不改变行为的对代码结构的改进 |
style |
对代码风格的修正（仅限缩进、空行一类的简单改动，对结构有影响的用 refactor） |
cosm |
cosmetic - 不改变行为的对界面的纯视觉上的改动 |
docs |
对文档的改进，包括对外文档和代码注释 |
build |
和构建流程、持续集成等有关的改动 |
# 格式
类型(可选的范畴): 简短描述
# 示例
feat(基金池):创建基金池子接口
feat(基金池):获取子基金池子数据接口
fix(beta筛选):修复目标日期到当前日期的间隔季度个数
style:删除全局已经处理的todo注释
refactor(beta筛选):修改视图与各小指标的代码结构
refactor:修改全局GDFundClass的实例化传参
# 额外的扩展
# 可以在描述中加入coding（协作平台，同类有：禅道、jira）中的bug的id
# 当团队逐步扩大到需要专业的软件测试时，描述中带有协作平台id可以提高辨识度
# 也有利于打通协作平台与仓库管理之间的隔阂，让项目管理数字化，样式如下
fix(私募): #6235 修复私募时间窗口数据格式问题
项目/模块 结构的规范：
项目/模块经常被抽象，但还是不断的被拷贝，不断的被重写。问题的根本就是没有人知道被抽象、代码抽象不彻底，以及没有完备的文档说明。一个高级的程序员除了对技术原理有深刻的理解，其次就是能够把 项目/模块 很好的说明给对接的人员，比一线开发更有价值的应该是造出能够为 新项目/模块 赋能的轮子。
# 范式有很多，通用的编码规则中一个文件不宜过长这种（这个是我们在冒险的事情）
# 列举几个应该避免的显著的问题
# 1.遵守基本的语言命令规则，不使用保留关键词做变量名；
# 2.尽可能利用python的类型标注特性，加快代码阅读者的理解速度；
# 3.写好注释，很多看似简单的历史包袱，一个月后就忘记了缘由；
# 4.写好api接口文档，推荐使用ApiFox（目前捕基能手已经收录了80多个接口），方便其他人调试；
# 5.项目/模块做额外的文档说明，介绍其支撑的业务是什么，以及使用/部署的流程和注意事项（越细致越不嫌细致）。
容器化：
容器化到现在应该不算是时髦的话题，在大部分企业因该已经成为了技术栈的一部分了。容器化的优势是显而易见的，比如：环境隔离、迁移便捷、服务扩展。单机可使用单机编排工具docker-compose，集群可搭建k8s平台，可以极大的为将来的架构升级做充分的准备。容器化的学习成本是有的，但学习成本绝对是较低的。
广告位招租
