先分享一段我自己比较受用的话“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 --since3 months ago --dateformat:%Y-%W --prettyformat:%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 groupIdorg.sonarsource.scanner.maven/groupId artifactIdsonar-maven-plugin/artifactId version3.9.1/version /plugin执行扫描命令mvn clean verify sonar:sonar \ -Dsonar.host.urlhttp://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 groupIdorg.springframework.boot/groupId artifactIdspring-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 延迟850ms500ms日志中 NPE 错误数量每天约 20 条每天小于 3 条这些指标来自三个视角代码质量、提交习惯、运行健康。无论团队成员还是自己独立维护项目这套指标都能让“进化”方向变得清晰。4.2 第二步采集现状数据先运行代码扫描导出现状数据mvn clean verify sonar:sonar \ -Dsonar.host.urlhttp://localhost:9000 \ -Dsonar.login你的token \ -Dsonar.coverage.jacoco.xmlReportPathstarget/site/jacoco/jacoco.xml如果没有配置 JaCoCo测试覆盖率可能为 0。建议先加 JaCoCo 插件plugin groupIdorg.jacoco/groupId artifactIdjacoco-maven-plugin/artifactId version0.8.10/version executions execution goals goalprepare-agent/goal /goals /execution execution idreport/id phaseverify/phase goals goalreport/goal /goals /execution /executions /plugin再导出 Git 提交统计判断自己的提交习惯git log --since3 months ago --prettyformat:%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?taguri:/users返回结果中会包含count、totalTime、max等字段。根据多个请求结果计算 P99。4.3 第三步制定三个进化目标数据采集完成后不要试图一次解决所有问题。建议聚焦三个目标每个目标都要有明确的完成标准。结合示例数据我们的三个目标是降低接口 P99 延迟从 850ms 降到 500ms 以下。把测试覆盖率从 37% 提升到 60%优先覆盖核心业务逻辑。重构 5 个认知复杂度超限的方法降低后续维护成本。这三个目标分别对应运行健康、代码质量、可维护性优先级从高到低。4.4 第四步执行重构与优化重构必须有测试保护否则改完容易出线上事故。所以先补测试再改代码。以用户服务中一个典型的长方法为例。假设原有代码如下public User processUserOrder(User user, ListOrder 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); ListOrder 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, ListOrder orders) { validateUser(user); BigDecimal total calculatePaidAmount(orders); User result buildBaseUser(user, total); result.setLevel(determineLevel(total)); return result; } private BigDecimal calculatePaidAmount(ListOrder 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.urlhttp://localhost:9000 \ -Dsonar.login你的token然后对比两个时间点的数据指标优化前优化后结果单测覆盖率37%63%达成认知复杂度超限方法23 个8 个达成重复代码块12 处6 处接近达成接口 P99 延迟850ms460ms达成这一张表就是“See in yourself, then evolve”的完整证据链。最好再补一份简单的验证文档记录优化前的问题现象、采集到的数据、采取的改动、测试结果、上线后的指标对比。这份文档的价值在两个月后回看时会非常明显。5. 常见问题与排查思路实战过程会遇到不少问题。这里整理几个高频场景问题现象常见原因解决思路SonarQube 扫描结果里没有覆盖率未生成 JaCoCo 报告或没有指定xmlReportPaths确认 JaCoCo 插件已执行并生成target/site/jacoco/jacoco.xmlActuator 访问/actuator/metrics返回 404端点未被暴露在application.yml中通过management.endpoints.web.exposure.include放行端点http.server.requests指标数据波动大样本量太小或只观察了短时间窗口至少运行 10 分钟压测或采集一天线上数据后再计算 P99Git 提交统计数量为 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 日志、跑一次代码扫描、看一眼服务指标你会更清楚下一步该往哪里走。