Publish by2025-05-19
Updated by2025-06-09
即将成为三年工作经验的码仔，记录下一些 Code Review 环节强烈建议做的事情，在开发阶段严格自查，是最经济的投入，如果到了实际产品上线后才暴漏，危已危已。
Written by - kok-s0s
| 检查项 | 说明 |
|---|---|
| 是否有多个线程访问同一变量/数据？ | 比如定时器、回调函数、后台线程等 |
| 是否有跨线程信号/槽连接？ | 非默认连接类型，如 Qt 中的 QueuedConnection 会跨线程触发 |
| 是否涉及全局对象、单例或共享引用？ | 容易被多个线程同时读写 |
| 检查项 | 说明 |
|---|---|
| 是否存在一个线程写、另一个线程读？ | 即使写入频率不高，也有风险 |
| 是否对容器进行添加/删除操作？ | 如 append、remove、insert 都属于修改操作 |
| 是否使用了非线程安全的数据结构？ | Qt 容器（QList, QVector 等）默认不是线程安全的 |
| 检查项 | 说明 |
|---|---|
| 是否使用锁机制保护共享数据？ | 如 QMutex、QReadWriteLock 等 |
| 锁是否作用在整个访问/修改操作区域？ | 尤其是多行操作时，必须全包住 |
| 是否使用了自动锁（RAII）？ | 避免忘记 unlock（例如 QMutexLocker） |
| 是否避免在锁内做耗时操作？ | 避免死锁、卡界面 |
| 检查项 | 说明 |
|---|---|
| 是否将锁作为成员变量，保护整个资源生命周期？ | 保证资源和锁是强绑定的 |
| 是否需要封装线程安全容器？ | 如 ThreadSafeQueue、ThreadSafeMap 等 |
| 是否设计了线程通信机制？ | 如条件变量、线程安全队列、事件派发机制等 |
| 是否需要将工作逻辑放入单独线程？ | 利用 QThread、任务队列、信号/槽通信更清晰地解耦线程逻辑 |
| 检查项 | 说明 |
|---|---|
| 是否使用断言或日志检测异常访问？ | 加入一致性检查，发现边界情况 |
| 是否在 debug 模式下主动测试线程交叉？ | 强化测试不同线程交互顺序，发现潜在问题 |
| 是否出现过偶现崩溃、未定义行为？ | 若是，很大可能是线程安全问题导致的 |
我现在有一个浅薄的观点，就是一个程序员吧，如果会 code format，且 Git 的 commit 信息写的条理清晰，就感觉已经超过 75% 左右的程序员了。
统一的代码格式意味着：
代码可读性高；
减少了代码 review 的沟通成本；
有助于长期维护；
实际开发中，有太多人不关心这一点，或者仅仅依赖 IDE 的默认格式，导致团队代码风格混乱。
会熟练使用 clang-format、.editorconfig 或 prettier 的人，真的不多。
清晰的 commit message（如遵循 Conventional Commits）能让团队成员快速理解每一次改动的目的。
也体现了开发者的思考方式：是否有结构、有总结力、有文档意识。
在大型团队或 CI/CD 中，良好的 commit 甚至直接影响上线节奏与回滚效率。
上述这两个习惯是“可见的内功”，很多高级技能是“看不出来”的，比如底层优化、架构设计； 而格式与 commit 这种，是你一打开 repo 就能看见的。
两个 PR：
A：
void foo(int x){if(x>0){bar(x);}}Commit: fix bug
B：
void foo(int x)
{
if (x > 0)
{
bar(x);
}
}Commit: fix: call bar only when x > 0 to avoid crash (#134)
会更信任哪一个？毫无疑问是 B。
public 成员？private / protected？Helper, Utils, Manager 等过于宽泛的类名？如果以上大部分都做到了，那么所编写的 OOP 代码就已经有很高的结构性和可维护性了。
Top