先分享一段我自己比较受用的话：“See in yourself. Then, evolve.”意思是说，先真正看清自己，再去进化。这句话放在技术成长里特别合适。很多开发者不是不努力，而是长期处于“埋头写代码、基本不看方向”的状态：不知道自己项目的技术债在哪，不知道自己写的代码哪些是坏味道，也不知道服务的运行健康度已经在下滑。等技术问题集中爆发，才被迫去救火。
这篇文章我想从“自我审视”出发，写一套可落地的技术进化闭环。我会围绕一个假设的场景展开：你负责一个真实的后端服务，如何用 Git 历史、代码扫描、运行时指标这些手段，定量地看清自己项目的现状，再制定进化目标，最后通过小步重构完成一次可验证的升级。文章会给出完整的配置、命令和代码示例，适合后端开发者、项目负责人，也适合想给自己建立成长机制的中级工程师。
1. 先理解“自我审视”到底在审什么
1.1 一句口号背后的成长逻辑
“See in yourself”看起来像鸡汤，但它其实包含一个很硬核的工作方法论：没有基线，就没有改进。
设想这样一个场景：有人问你，“你的项目代码质量怎么样？”你如果回答“还行吧”“挺乱的”，这就是没有基线的主观判断。但如果你能说：“最近 3 个月新增代码有 40% 没有写测试；循环依赖有 12 处；接口 P99 延迟比上季度涨了 80ms；线上错误日志每天还有 300 条 NPE 堆栈”，这就不是感觉，而是可以决策的数据。
自我审视的本质，就是把自己的工作状态和代码现状变成可采集、可量化、可对比的数据。有了数据，你才知道从哪个方向进化，以及进化到什么程度算成功。本文标题里提到的“evolve at sleek.silisleek.com”更多是站点自身的一句话表达，我们不讨论具体站点内容，只借用这个理念来展开技术实践。
1.2 技术人的自我审视包含哪些维度
对一个后端开发来说，自我审视至少包含四个维度：
- 代码质量维度：重复代码、复杂度过高的方法、未处理异常、缺少测试覆盖。
- 提交习惯维度：提交频率、提交信息是否清晰、是否经常出现“临时修复”类提交、是否在同一分支上混入多个不相关需求。
- 运行健康维度：服务接口耗时、GC 频率、内存占用、错误日志总量、依赖中间件的连接池使用情况。
- 成长方向维度：最近半年自己主要接触了哪些知识领域，是反复写 CRUD 还是在深入性能、稳定性、工程效率。
前三个维度都可以通过工具自动采集，第四个维度需要定期复盘。本文重点讲前三个，因为它们是“可执行”的部分。
1.3 平台与工具可以帮你看到什么
工具的价值不是“看起来专业”，而是帮我们弥补记忆和感觉的盲区。比如：
- Git 提交统计能暴露你的真实工作节奏。
- 静态代码扫描能发现你自己不觉得有问题的坏味道。
- 运行时监控数据能告诉你用户请求到底慢在哪里。
- 测试覆盖率报告能让你看到哪些代码只是“能跑”，但没人保护它。
下面我们就进入具体环境准备，先把手边的工具箱搭起来。
2. 环境准备与工具清单
2.1 前置环境说明
本文示例以 Java + Spring Boot 后端项目为例，因为这类项目在代码扫描、运行时监控方面生态比较成熟。你在实际使用中不一定必须使用同样的版本，重点是理解每个工具承担的角色。版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。
建议准备以下环境：
- JDK 17 或 JDK 11（取决于你的 Spring Boot 版本）。
- Maven 3.8+。
- Git 2.30+。
- 一个可以运行的 Spring Boot 服务，建议是 2.7.x 或 3.x 版本。
- SonarQube 社区版服务，用于代码质量扫描。
- Prometheus + Grafana，用于运行时指标采集和展示（本文只做基础讲解，不是重点）。
2.2 工具链各自负责什么
| 工具 | 定位 | 主要价值 |
|---|---|---|
| Git Log 分析脚本 | 提交习惯审视 | 看清提交频率、信息质量、代码量波动 |
| SonarQube | 代码质量审视 | 发现 Bug、漏洞、坏味道、重复代码、测试覆盖缺口 |
| Spring Boot Actuator | 运行时状态暴露 | 提供健康、指标、环境信息等 HTTP 端点 |
| Prometheus | 指标采集与存储 | 定时抓取 Actuator 暴露的指标 |
| Grafana | 指标可视化 | 把指标变成图表，方便观察趋势 |
这套组合可以覆盖“代码层面”和“运行层面”的双重视角。
2.3 示例项目结构
为了后续演示，假设你的项目路径如下：
my-service/ ├── src/main/java/com/example/myservice/ │ ├── MyServiceApplication.java │ └── controller/ │ └── UserController.java ├── src/main/resources/ │ └── application.yml ├── pom.xml └── README.md接下来的实战会围绕这个项目展开。
3. 用数据建立基线：量化你的现状
3.1 Git 提交历史：看清编码习惯
这是成本最低、见效最快的审视方式。Git 已经记录了你的所有提交行为，只需要用命令把它们提取出来。
先看仓库整体提交次数：
git log --oneline | wc -l查看最近 3 个月每周提交数量分布：
git log --since="3 months ago" --date=format:"%Y-%W" --pretty=format:"%ad" | sort | uniq -c输出大致长这样：
14 2025-01-02 9 2025-01-03 0 2025-01-04 21 2025-01-05如果你发现某些周提交数量为 0，而另一些周突然暴涨到几十次，往往说明工作节奏不平稳，可能存在大量积压后集中提交的情况。
再看提交信息质量。统计常见的模糊提交词：
git log --oneline | grep -E "fix|修复|临时|update|更新" | head -20这里的 fix、update 本身不是问题，问题在于只有“fix”而没有说明修了什么。更健康的提交信息应该包含模块、问题、原因或影响范围，例如：
fix(user-service): correct NPE when querying empty user list如果你发现自己的提交信息大量是update、修改、临时提交，这就是一个非常明确的进化方向。
3.2 代码扫描：看清质量问题
Git 只能看到提交行为，看不到代码内部的坏味道。静态代码扫描是更深入的一层审视。
以 SonarQube 为例，在项目pom.xml中引入扫描插件：
<plugin> <groupId>org.sonarsource.scanner.maven</groupId> <artifactId>sonar-maven-plugin</artifactId> <version>3.9.1</version> </plugin>执行扫描命令：
mvn clean verify sonar:sonar \ -Dsonar.host.url=http://localhost:9000 \ -Dsonar.login=你的token扫描完成后，SonarQube 会给出几类数据：
- Bugs：可能引发运行时错误的问题。
- Vulnerabilities：安全漏洞。
- Code Smells：坏味道，比如过长方法、重复代码块、过深的嵌套。
- Coverage：测试覆盖率，反映有多少代码被执行用例保护。
例如一个典型的长方法提示：
Refactor this method to reduce its Cognitive Complexity from 17 to the 15 allowed.这就是非常具体的进化线索。
3.3 运行时指标：看清服务健康状况
代码静态扫描解决的是“代码写得怎么样”，运行时指标解决的是“服务跑得怎么样”。
Spring Boot 项目引入 Actuator 依赖：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>在application.yml中暴露需要的端点：
management: endpoints: web: exposure: include: health,info,metrics,env,loggers,threaddump endpoint: health: show-details: always启动服务后访问：
curl http://localhost:8080/actuator/health你会看到服务健康状态。再访问：
curl http://localhost:8080/actuator/metrics/http.server.requests这个端点可以统计 HTTP 请求的分布情况，包括最大耗时、平均值、异常次数。
如果需要更完整的可视化，可以接 Prometheus。但本文不强制要求，核心是先建立“能拿到指标”的通道。
4. 实战：从审视到进化的完整闭环
这一部分我会带你走完一个完整闭环。场景假设如下：
你负责一个用户服务，最近反馈说接口变慢，代码也越改越乱。你需要通过审视找到问题，制定进化计划，最终完成一次可验证的提升。
整个过程分为五步。
4.1 第一步：定义能力指标体系
不能等到扫描完再想指标。建议先明确自己要关注哪些指标，并给每个指标设定“当前基线”和“目标值”。
以这次实战为例，定义如下指标：
| 指标 | 当前基线 | 目标值 |
|---|---|---|
| 单测覆盖率 | 37% | 60% |
| 认知复杂度超限方法数 | 23 个 | 10 个 |
| 重复代码块 | 12 处 | 5 处 |
| 提交信息包含具体模块的比例 | 45% | 80% |
| HTTP 接口 P99 延迟 | 850ms | 500ms |
| 日志中 NPE 错误数量 | 每天约 20 条 | 每天小于 3 条 |
这些指标来自三个视角：代码质量、提交习惯、运行健康。无论团队成员还是自己独立维护项目，这套指标都能让“进化”方向变得清晰。
4.2 第二步：采集现状数据
先运行代码扫描，导出现状数据：
mvn clean verify sonar:sonar \ -Dsonar.host.url=http://localhost:9000 \ -Dsonar.login=你的token \ -Dsonar.coverage.jacoco.xmlReportPaths=target/site/jacoco/jacoco.xml如果没有配置 JaCoCo，测试覆盖率可能为 0。建议先加 JaCoCo 插件：
<plugin> <groupId>org.jacoco</groupId> <artifactId>jacoco-maven-plugin</artifactId> <version>0.8.10</version> <executions> <execution> <goals> <goal>prepare-agent</goal> </goals> </execution> <execution> <id>report</id> <phase>verify</phase> <goals> <goal>report</goal> </goals> </execution> </executions> </plugin>再导出 Git 提交统计，判断自己的提交习惯：
git log --since="3 months ago" --pretty=format:"%h|%s" | awk -F'|' '{print $2}' | sed 's/^\([a-z-]*\).*/\1/' | sort | uniq -c | sort -rn这条命令会统计提交信息里常见的模块前缀，帮助你发现哪些模块提交频繁、哪些模块被长期忽略。
接着通过 Actuator 采集接口延迟：
curl http://localhost:8080/actuator/metrics/http.server.requests?tag=uri:/users返回结果中会包含count、totalTime、max等字段。根据多个请求结果计算 P99。
4.3 第三步：制定三个进化目标
数据采集完成后，不要试图一次解决所有问题。建议聚焦三个目标，每个目标都要有明确的完成标准。
结合示例数据，我们的三个目标是：
- 降低接口 P99 延迟：从 850ms 降到 500ms 以下。
- 把测试覆盖率从 37% 提升到 60%：优先覆盖核心业务逻辑。
- 重构 5 个认知复杂度超限的方法：降低后续维护成本。
这三个目标分别对应运行健康、代码质量、可维护性，优先级从高到低。
4.4 第四步：执行重构与优化
重构必须有测试保护，否则改完容易出线上事故。所以先补测试，再改代码。
以用户服务中一个典型的长方法为例。假设原有代码如下：
public User processUserOrder(User user, List<Order> orders) { if (user == null) { throw new IllegalArgumentException("user must not be null"); } User result = new User(); result.setId(user.getId()); result.setName(user.getName()); BigDecimal total = BigDecimal.ZERO; if (orders != null) { for (Order order : orders) { if (order.getStatus() == OrderStatus.PAID) { BigDecimal amount = order.getAmount(); if (amount != null) { total = total.add(amount); } } } } result.setTotalAmount(total); if (total.compareTo(new BigDecimal("1000")) > 0) { result.setLevel(UserLevel.VIP); } else { result.setLevel(UserLevel.NORMAL); } return result; }这段代码包含多个职责：校验入参、遍历订单、计算金额、设置用户等级。认知复杂度很高。
第一步，写测试，把现有行为固定下来。示例只展示核心测试思路：
@Test void shouldSetVipLevelWhenPaidAmountOver1000() { User user = new User(); user.setId(1L); List<Order> orders = List.of( new Order(BigDecimal.valueOf(600), OrderStatus.PAID), new Order(BigDecimal.valueOf(500), OrderStatus.PAID) ); User result = userService.processUserOrder(user, orders); assertThat(result.getLevel()).isEqualTo(UserLevel.VIP); }第二步，把金额计算和等级判断抽成独立方法：
public User processUserOrder(User user, List<Order> orders) { validateUser(user); BigDecimal total = calculatePaidAmount(orders); User result = buildBaseUser(user, total); result.setLevel(determineLevel(total)); return result; } private BigDecimal calculatePaidAmount(List<Order> orders) { if (orders == null) { return BigDecimal.ZERO; } return orders.stream() .filter(order -> order.getStatus() == OrderStatus.PAID) .map(Order::getAmount) .filter(Objects::nonNull) .reduce(BigDecimal.ZERO, BigDecimal::add); } private UserLevel determineLevel(BigDecimal total) { if (total.compareTo(VIP_THRESHOLD) > 0) { return UserLevel.VIP; } return UserLevel.NORMAL; }这种重构的核心逻辑是：先通过测试固定行为，再提取方法，而不是一边改逻辑一边重构。
针对接口延迟优化，方向各不相同。可能是慢 SQL、可能是串行调用下游服务、可能是循环里做远程调用。示例中比较常见的问题是循环内调用数据库查询，可以改成批量查询，这一步需要结合你的具体业务代码去调整。
4.5 第五步：验证效果并沉淀文档
优化结束后，重新执行扫描和指标采集：
mvn clean verify sonar:sonar \ -Dsonar.host.url=http://localhost:9000 \ -Dsonar.login=你的token然后对比两个时间点的数据：
| 指标 | 优化前 | 优化后 | 结果 |
|---|---|---|---|
| 单测覆盖率 | 37% | 63% | 达成 |
| 认知复杂度超限方法 | 23 个 | 8 个 | 达成 |
| 重复代码块 | 12 处 | 6 处 | 接近达成 |
| 接口 P99 延迟 | 850ms | 460ms | 达成 |
这一张表就是“See in yourself, then evolve”的完整证据链。最好再补一份简单的验证文档，记录：优化前的问题现象、采集到的数据、采取的改动、测试结果、上线后的指标对比。这份文档的价值在两个月后回看时会非常明显。
5. 常见问题与排查思路
实战过程会遇到不少问题。这里整理几个高频场景：
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| SonarQube 扫描结果里没有覆盖率 | 未生成 JaCoCo 报告，或没有指定xmlReportPaths | 确认 JaCoCo 插件已执行并生成target/site/jacoco/jacoco.xml |
Actuator 访问/actuator/metrics返回 404 | 端点未被暴露 | 在application.yml中通过management.endpoints.web.exposure.include放行端点 |
http.server.requests指标数据波动大 | 样本量太小，或只观察了短时间窗口 | 至少运行 10 分钟压测或采集一天线上数据后再计算 P99 |
| Git 提交统计数量为 0 | 使用了错误的--since语法，或仓库不是 Git 仓库 | 先执行git status确认仓库，再核对日期范围 |
| 重构后测试失败，出现大量无关失败用例 | 重构抽方法时不小心改变了原逻辑 | 回滚到上一个提交，逐段对比行为，使用测试固定行为后再抽方法 |
| 覆盖率提升但接口仍慢 | 性能瓶颈可能在数据库或第三方服务，不在业务代码 | 用链路追踪、慢 SQL 日志、火焰图定位真正热点 |
再强调一个特别常见的工程问题：不要在没有测试的情况下做大规模重构。你可能觉得“这段代码很简单，我闭着眼睛都能改”，但长方法往往隐藏在看似简单的代码中，一旦改错，线上问题排查成本远高于你省下的写测试时间。
6. 工程实践建议：让“进化”成为长期机制
6.1 把审视做成例行仪式
自我审视不应该是一年一次的活动，而应该是迭代的一部分。比较实用的节奏是：
- 每次需求开发前：用 SonarQube 看相关模块是否有存量坏味道，顺手小范围清理。
- 每次发布前：关注覆盖率变化和新增告警。
- 每个月：导出 Git 提交统计，看自己的节奏是否健康。
- 每个季度：做一次完整的指标对比，给出正式的“进化报告”。
所谓进化，不是一个突变，而是多个小改进的叠加。
6.2 不要追求一次性完美
当扫描结果出来时，你可能会被一大堆问题吓到。这里有 80 个坏味道、20 个复杂度问题，怎么办？
合理策略是：每次只处理 3 到 5 个，并且优先处理引发线上问题的那个层级。例如：
- 先修高优先级 Bug。
- 再补核心链路测试。
- 然后重构复杂度最高的方法。
- 最后清理重复代码。
每个层级都单独提交，方便后人理解。
6.3 用版本管理保护每一次进化
推荐把“审视和改进”纳入 Git 分支策略。基本流程如下：
git checkout -b refactor/user-order-quality git add src/test/java/... src/main/java/... git commit -m "refactor(user-order): extract amount calculation logic" git push origin refactor/user-order-quality让每个提交只表达一个明确的改动意图。这样代码评审可以更快，回滚也更安全。
这里给出一个提交信息模板：
<type>(<模块>): <简短描述>类型可以是fix、feat、refactor、test、docs、chore。例如：
fix(user-order): handle null amount in paid orders test(user-order): add coverage for vip threshold calculation refactor(user-order): reduce cognitive complexity of processUserOrder我建议从这一刻就开始用，不要等一个“合适”的时机。
6.4 记录决策，回看时才知道为什么
代码里注释可以减少，但“为什么这样做”的记录不应该少。重构完成后，建议在项目 README 或 docs 目录下追加一段简短的“架构决策记录”。示例：
# 2025-02 用户服务质量进化记录 ## 问题 processUserOrder 方法认知复杂度 17，超过团队 15 的阈值； 核心金额计算没有单测保护，重构风险高。 ## 决策 1. 使用 JaCoCo 统计覆盖率，逐步补充核心链路测试。 2. 将金额计算、等级判断抽成独立私有方法。 3. 用批量查询替代循环查询，降低 P99。 ## 结果 覆盖率从 37% 提升到 63%；P99 从 850ms 降至 460ms； 复杂度超限方法从 23 个降至 8 个。这份记录不占用多少时间，但它能让三个月后的你快速想起当时的背景和意图。
7. 总结与后续学习路线
本文用“See in yourself. Then, evolve.”这句话作为主线，完整拆解了一个从自我审视到技术进化的闭环。你可以先通过 Git 提交历史看清自己的工作习惯，再用 SonarQube 看清代码质量问题，然后用 Actuator 看清运行健康状态，最后基于数据制定目标、小步重构、对比结果。这套方法不只适用于个人项目，也适用于团队质量建设。
如果按优先级安排下一步学习，我的建议是：
- 先掌握 Git 提交规范的实践：成本最低，收益立刻可见。
- 补一套测试体系：JaCoCo + JUnit 是很好的起点，覆盖率不用追求 100%，但要保护核心链路。
- 深入学习静态代码分析工具：SonarQube 的规则了解得越多，你写代码时就越有意识。
- 完善运行时监控：Actuator 只是起点，后面可以接触 Prometheus、Grafana，甚至链路追踪。
- 增加个人复盘机制：每季度写一份短报告，记录你发现了什么问题、做出了什么改变、数据上有什么提升。
“看清自己”最难的不是没有工具，而是愿意定期面对那些不够好的数据。只要你能稳定地完成一次审视和改进，后面就可以把这件事变成习惯。下一次当你觉得自己成长停滞时，试着先不要去学新框架，而是打开 Git 日志、跑一次代码扫描、看一眼服务指标，你会更清楚下一步该往哪里走。
