日常开发提效实战：习惯与工作流
上一篇聊的是「用 Cursor 在 .NET 项目里提效」，这篇换一个角度：不依赖某款 IDE 或 AI，靠习惯、工作流和小工具，把「需求 → 开发 → 排查 → 交付」这条链路捋顺，少返工、少熬夜。
一、需求到手先拆解：三句话 + 一张表
需求文档或口述需求经常又长又散，直接开写容易漏点、做错范围。提效的第一件事：在写代码前，先把需求压成「可执行清单」。
三句话定边界
用三句话逼自己说清楚（可以写在任务描述或注释里）：
- 做什么：用一句话说清功能/改动目标（例如：「支持按申请单号查询发票申请单详情并返回 DTO」）。
- 动哪些层：接口层、应用层、领域层、表结构、外部调用——勾出会碰到的，避免写到一半才发现要改表。
- 不做什么：明确排除项（例如：「本期不做分页」「不接 ERP 回写」），减少和产品来回扯皮。
一张表拆任务
用表格把「需求 → 具体改动点」拆开，一行一个可交付小任务，例如：
| 序号 | 改动点 | 涉及文件/模块 | 验收方式 |
|---|---|---|---|
| 1 | Domain 新增查询接口 | IInvoiceService, InvoiceService | 单测/手测 |
| 2 | Application 封装 | InvoiceAppService | 调 API 验证 |
| 3 | Controller 暴露 | InvoiceController | 接口文档/Postman |
拆完再开分支、写代码，思路清晰，也方便估时和汇报进度。
二、分支与提交：少在合并上耗时间
分支乱、提交信息随意，合并时冲突多、回滚难。养成固定习惯，能省很多「理历史」的时间。
分支命名约定
- 功能：
feature/需求简写-简短描述，如feature/invoice-query-by-applyno。 - Bug：
fix/问题简写或bugfix/ticket-123。 - 发布/热修：
release/版本号、hotfix/问题描述。
同一需求只开一个 feature 分支，从 develop 或 main 拉，改完再合回去，避免「好几个分支不知道哪个是最终版」。
提交信息写清「做了什么」
不用写小作文，但至少要让人（以及三个月后的自己）一眼看懂：
- 好的：
feat(invoice): 按申请单号查询申请单详情接口、fix: 空列表时 NRE，增加 null 判断。 - 差的：
修改、更新、fix bug。
习惯用「类型(模块): 简短说明」的格式，后续用 git log --oneline、按模块筛选都会很顺手。
小步提交，大功能拆多次 commit
一个需求可以拆成 3～5 个 commit：例如「加接口定义」「加实现」「加 Controller」「补单测」。这样回滚、code review、bisect 找问题都方便，不必在一个巨型 commit 里翻。
三、调试与排查：先定范围再下断点
很多人一报错就全项目下断点、盲目 F10。先缩小范围，再精确打断点，能少走一半弯路。
先看调用栈和首行
- 看异常第一次出现的堆栈行（通常是你的业务代码，而不是框架深处）。
- 看报错信息里的关键实体（如「OrderInvoiceApply 为 null」「InvoiceOrderList 为空」），直接去构造/赋值这条数据的地方查。
用「二分法」锁定时序问题
怀疑是「A 执行完才到 B，但实际顺序反了」这类问题时：
- 在关键路径前后打日志（如
Log("Step1 done")、Log("Step2 start")），跑一遍看顺序。 - 或临时加断言/抛异常，确认「代码是否真的执行到这里」。
日志：关键步骤必打，格式统一
- 入口：入参（脱敏）、关键 ID（订单号、申请单号）。
- 分支：进入哪个 if、调了哪个下游。
- 出口：返回码、影响行数、耗时（大操作建议记一下）。
格式统一（如 [InvoiceApply] Create start, applyId=xxx），方便用日志系统按关键字搜、按 traceId 串起来看。
四、代码模板与 Snippet：少敲重复结构
每个项目都有大量重复结构：构造函数注入、try-catch 包一层、标准 API 返回格式、单测的 Arrange-Act-Assert。用 Snippet / 文件模板 一次配好，长期省时间。
VS / Rider 的 Snippet
- C#：
ctor生成构造函数、prop生成属性；可以自定义svc→ 生成「带 ILogger 的 Service 构造函数」等。 - 为你们项目定制：例如
invapp→ 生成「Application 层调用 Domain 并转 DTO」的模板方法骨架。
文件级模板
- 新建 Service 时：类名、命名空间、接口 + 实现、构造函数注入的骨架一次生成。
- 新建 Controller 时：路由前缀、[HttpGet]/[HttpPost]、标准返回类型、日志与异常处理。
把团队共用的模板放到仓库的 docs/templates 或 Wiki，新人也能快速统一风格。
五、读老代码：先画边界再进细节
接手老项目或改别人模块时，不要一上来就逐行读。先划清边界，再按调用链往下走。
第一步：找入口和出口
- 入口：API 的 Controller 方法、消息队列的 Handler、定时任务的入口方法。
- 出口：调了哪些其他 Service、写了哪几张表、发了哪些 MQ/HTTP。
用 IDE 的「查找引用」「调用层次」快速画出「谁调我、我调谁」，一张小图或列表就够。
第二步：抓主流程，忽略分支
- 先跟一条主流程（例如「创建发票申请单」从 Controller → AppService → DomainService → 仓储）。
- 分支逻辑（各种 if、异常处理）第一遍可以略读，等改到再细看。
第三步：用注释和便签做「路标」
在复杂方法或类上临时加 // TODO: 理解后再删 或简短注释，标出「这里在干什么」「为什么这样写」。下次再摸这块代码，直接看自己的路标，不用重新推演。
六、文档与方案：用结构代替发挥
写技术方案、设计文档、复盘报告时，先搭结构再填内容，比边想边写快很多。
方案文档的通用结构
- 背景与目标：为什么要做、做到什么算完成。
- 方案概述：一两段话总览，再分「接口设计」「数据流」「存储/依赖」。
- 影响范围：动哪些服务、哪些表、有没有兼容旧逻辑。
- 风险与回滚：可能出什么问题、怎么回滚、有没有开关/灰度。
按这个结构填空，产品、测试、运维都能快速找到关心的部分。
复盘/总结的通用结构
- 做了什么：需求/问题简述。
- 怎么做的：关键设计、关键代码或配置。
- 踩坑与解决：遇到的问题、怎么查、怎么修。
- 后续可优化：没做完的、可以改进的点。
写给自己看也行，用来做分享、写周报都方便复用。
七、小结：提效的本质是「少返工」
| 环节 | 习惯/动作 |
|---|---|
| 需求 | 三句话定边界 + 一张表拆任务，再开分支写代码。 |
| 分支与提交 | 统一命名、写清 commit 信息、小步提交。 |
| 调试 | 先看调用栈和首行，用二分法锁定时序，日志格式统一。 |
| 写代码 | 用 Snippet/模板统一重复结构，减少手敲。 |
| 读老代码 | 先找入口/出口，跟主流程，用注释做路标。 |
| 文档与方案 | 先搭结构再填内容，背景→方案→范围→风险。 |
这些都不依赖特定 IDE 或 AI，坚持一段时间，你会明显感觉「想得清、查得快、写得少重复」。若你已经在用 Cursor 或其它 AI 工具，可以把「需求拆解表」「提交规范」「日志格式」写进 .cursorrules 或团队规范，让 AI 生成的代码和你的习惯同频，效率会再上一档。
你平时还有哪些「习惯或工作流」明显提升了效率？欢迎在评论区分享。
