回顾 (retro)

回顾（retro）

概述

retro 生成开发者统计报告，帮助你：量化工作成果，发现改进空间，证明自己的价值。

作为一个程序员，你可能遇到过：

• “我这周好像没做什么”
• “怎么证明我的价值？”
• “我想了解团队的开发效率”

retro 就是解决这些的。

核心价值

1. 量化成果

❌ "这周做了不少事"
✅ "提交 47 个 PR，新增 12000 行代码，修复 8 个 bug"

2. 发现改进空间

数据会说话：
- 这个月用了 30% 的时间修 bug
- 这个功能重构了 3 次
- 某个文件的复杂度超标了

3. 汇报素材

周报/月报不用愁：
- 直接贴数据
- 领导看得懂
- 价值可视化

数据维度

代码贡献

指标	说明
新增行数	实际新增的代码
删除行数	删除的代码
修改行数	改动但非新增删除
净增长	新增 - 删除

提交活动

指标	说明
提交数	总提交次数
平均提交大小	总行数 / 提交数
提交者分布	谁提交的多

文件变更

指标	说明
修改文件	改动的文件数
新增文件	新建的文件数
删除文件	删除的文件数
重构文件	重构的文件数

测试

指标	说明
测试覆盖率	测试覆盖的代码比例
新增测试	新增的测试用例
测试通过率	测试通过的比例

使用场景

场景 1：周报

这周的工作成果：

代码产出：
- 新增: 3,456 行
- 删除: 1,234 行
- 净增长: 2,222 行

提交活动：
- 提交: 23 次
- PR: 8 个
- 合并: 6 个

测试：
- 覆盖率: 78% → 82%
- 新增测试: 45 个

文件变更：
- 修改: 56 个文件
- 新增: 12 个文件

场景 2：个人复盘

这个月我在做什么：

时间分配：
- 新功能: 40%
- Bug修复: 30%
- 代码优化: 20%
- 会议/其他: 10%

发现：
- 某个模块复杂度太高
- 某个文件频繁改动（设计问题？）
- 测试覆盖率不够

改进方向：
- 重构高复杂度模块
- 增加测试

场景 3：团队对比

Q1 团队效率：

代码产出：
- 团队总产出: 50,000 行
- 我个人: 12,000 行 (24%)

效率对比：
- 我: 8.5 行/提交
- 团队平均: 6.2 行/提交

质量：
- 我: 0 个线上 bug
- 团队平均: 2 个

常用命令

Git Stats

# 本周统计
git log --since="1 week ago" --pretty=format:"%h %s" | wc -l

# 代码行数
git diff --stat HEAD~100..HEAD

# 某个作者的统计
git shortlog -s --author="username"

# 文件变更
git diff --name-status HEAD~50..HEAD

测试覆盖率

# Jest
npm test -- --coverage

# pytest
pytest --cov=. --cov-report=html

# Go
go test -coverprofile=coverage.out ./...

CI/CD 统计

# GitHub
gh run list --limit 50

# 查看 PR 统计
gh pr list --state merged --limit 100

解读数据

代码量不是一切

注意：
- 代码量 ≠ 价值
- 删除代码也是贡献
- 重构可能减少代码但提升质量
- 维护老代码可能代码量小但价值高

关注趋势

比绝对值更重要的是趋势：
- 这周比上周效率提升了吗？
- 这个月比上个月质量好了吗？
- 团队在进步吗？

速查卡片

核心价值

• 量化成果
• 发现改进空间
• 汇报素材

数据维度

• 代码贡献
• 提交活动
• 文件变更
• 测试

使用场景

• 周报/月报
• 个人复盘
• 团队对比

---

查看源文件: GitHub原始文件