Doer Notes

提高代码团队质量

2025-11-05 · 5 min read

Git使用规范

（1）所有代码必须上传至Git仓库,如有破坏性更新请先创建版本分支

  • 直接在 master 分支上修改并 push 破坏性代码 → 可能导致线上服务崩溃
  • 代码只写在本地，未提交到 Git → 团队无法协作
  • 删除旧 API 但未通知其他团队 → 调用方系统报错

（2）分享给同事的代码需保证完整且可正常运行

  • 运行代码前先 git pull一下保证代码最新
  • 如果需要用到第三方dll且不提供nuget下载的情况下，需要把dll放在sln文件同级Lib文件夹重新引用(vs自动转换成相对路径)
  • 禁止使用绝对路径引用，例如 D:\Libs\xxx.dll (你电脑上有这个路径，人家有吗？)

（3）重要节点必须创建分支或Tag标记

版本管理要求

  1. 核心类必须包含版本概念，便于调试

    • 1.0.0.0 —— 传统四段式版本 : ios 16.x 17.x
    • 2025.1.0.1 —— 年份+序列号风格 vs2013,vs2022,vs2026,iso 26.1

  2. 每发布一个版本必须创建Tag或分支

  3. 代码提交需规范记录新增、修改、修复内容

    • fix: 类型 为 fix 的提交表示在代码库中修复了一个 bug
    • feat: 类型 为 feat 的提交表示在代码库中新增了一个功能
    • docs: 用于修改文档，例如修改 README 文件、API 文档等
    • refactor: 用于重构代码，例如修改代码结构、变量名、函数名等但不修改功能逻辑
    • perf: 用于优化性能，例如提升代码的性能、减少内存占用等
    • build: 用于发布版本

  4. 所有改动均需记录，特殊需求需备注需求人

技术栈与编码规范

第三方类库使用

  1. 直接使用官方包，尽量少修改原代码，如需要修改请clone到内网并发布到内网或者myget包

  2. 可适当参与PR提升自身阅读代码能力 (黄老板发现的bug)

数据库操作规范

  1. 非必要禁止在代码中出现SQL语句（复杂报表除外）

对比之前：



之后：

  1. 其他应用(客户端小软件/服务)对接本系统禁止直接操作数据库，统一使用WebAPI
    • 有泄露连接串风险(即使代码加密只要在内存里连接串都可以dump出来)
    • 数据库密码变更影响大。
  2. 推荐使用FreeSQL/Sqlsugar/EF/Dapper等ORM操作数据库
  3. 不推荐使用存储过程和原生SQL语句
对比维度 存储过程（Stored Procedure） 代码实现（Application Code）
性能 ✅ 通常更快：逻辑在数据库服务器执行，减少网络往返；预编译，执行计划可缓存。 ⚠️ 可能较慢：需多次数据库交互；但现代 ORM 和批处理可优化。
可维护性 ⚠️ 较差：逻辑分散在 DB 层，版本控制困难；调试和测试工具链弱；团队协作成本高。 ✅ 更好：代码集中管理，支持 Git、单元测试、CI/CD 等现代开发实践。
可移植性与耦合 ❌ 差：强依赖特定数据库（如 T-SQL、PL/pgSQL），迁移成本高；业务逻辑与数据层紧耦合。 ✅ 好：使用标准语言（如 C#、Java），配合 ORM 可轻松切换数据库；逻辑与数据解耦更清晰。
  1. 大多数情况下查询数据必须建立实体类，使用面向对象方式
  2. 非必要不使用DataTable/DataRow，请改用实体或Record类

代码结构优化

  1. 命名空间和项目名称需规范
  2. 建立完整的文件夹结构，保持项目清晰
  3. 代码超过2000行必须抽离为独立方法或文件，专有事件处理专有逻辑，减少代码冲突
  4. 一个function 一般长度不超过两个屏幕
  5. 适当使用设计模式


异常捕获

1.更推荐使用全局异常拦截。

2.事务处理不太好

推荐：

适当添加扩展方法

适当封装 xxConfigService类




封装后：

适当使用自动映射



网站推荐

  1. 全球最大同性交友平台 https://github.com
  2. 约定式提交
  3. 设计模式

培养解决异常问题能力

  1. 问题的本质是期待的状况与现实状况的落差
  2. 5WHY分析法

题外话

..