高效Java编程的7个习惯

作者头像东城·2026-01-31 23:48:20·
从AI用户到AI专家
说实话，AI编码工具现在无处不在。🤖 它们不再是什么闪亮的新玩具——它们已经成为我们作为开发者日常工作的一部分，就像我们的晨间咖啡一样。☕
对于我们这些Java开发者来说，无论是在与巨大的遗留应用程序搏斗，还是在处理一堆微服务，这些工具看起来都像是快速完成工作的巨大胜利。🚀
但这里有个陷阱：仅仅编码得更快并不能说明全部问题。如果你不小心，它实际上可能导致更大的问题。🤔
真正的目标是学会如何与AI协作编写真正好的代码——坚实、安全，不会让团队中的下一个人头疼或给你的公司带来严重问题。
这意味着我们必须从复制粘贴机器升级为真正知道如何处理这些强大工具的聪明开发者。💪
所以，我分享7个关键习惯来帮助你做到这一点。这不仅仅是关于速度；这是关于在你热爱的工作上变得更好：💡
黄金法则：为你的技艺感到自豪并承担责任 🥇
喂养野兽：你项目的上下文是它的燃料 ⛽
避开"泥球"：保持代码的可维护性 🧠
清理你的房间：没有杂散代码或可疑依赖 🧹
信任但审查：分析AI、代码和供应链 🕵️‍♀️
超越覆盖率：强制进行有意义的测试 ✅
人类网关：为AI看不到的东西进行代码审查 🧠
1. 黄金法则：为你的技艺感到自豪并承担责任 🥇
第一个也是最重要的习惯不是关于责备；而是关于自豪感和责任感。作为开发者，我们是现代工匠。交付高质量、优雅和健壮的代码会带来深刻的内在满足感。这种自豪感是成功职业生涯和健康团队动态的基础。这是将困难的拉取请求对话转变为协作设计会议的因素，也是将编写代码的日常任务转变为学习和掌握机会的因素。
AI编码助手是我们工坊中强大的新工具，但就像任何电动工具一样，它们可以用来创造美丽的作品，也可以快速制造混乱。盲目接受AI生成的代码是侵蚀这种职业自豪感的最快方式。当你让未经审核的代码进入你的代码库时，你不仅仅是在引入潜在的bug；你还在放弃学习、改进和充满信心地支持你的工作的机会。规则不是"你会被责备"；而是"你的名字在上面，所以让它成为值得骄傲的东西"。
从痛苦的PR到富有成效的对话
我们都参与过感觉像是苦差事的拉取请求（PR）审查。评论是一长串风格上的挑剔、潜在的空指针异常，以及"这部分到底应该做什么？"之类的问题。这通常发生在代码匆忙或没有完全理解的时候。
现在，想象一个PR，其中代码质量很高，逻辑清晰，实现健壮，显然你完全理解PR中的代码。对话瞬间提升。团队不再挑剔语法，而是讨论架构选择、业务逻辑和潜在的功能增强。这是真正协作发生的地方。
通过使用AI作为起点，然后仔细完善输出，你确保你的PR属于第二类。你向团队展示了你已经完成了思考的艰难工作，而不仅仅是提示的简单工作。你拥有解决方案，由此产生的讨论尊重这种所有权。
技术示例：AI脆弱的CompletableFuture vs 精心制作的弹性解决方案
考虑微服务架构中的常见场景：你需要通过并发地聚合来自三个不同服务的数据来构建用户的仪表板。你问AI：_"// Java: 使用CompletableFuture，并发获取用户详细信息、他们最近的5个订单和他们的产品评论数量。将它们合并到单个DTO中并处理错误。"_
AI为了直接解决方案，可能会产生这样的代码：
  1. // AI生成的第一稿 - 脆弱且天真
  2. public UserDashboardDTO getDashboard(long userId) throws Exception {
  3. // 并行发起所有请求
  4. CompletableFuture<User> userFuture = CompletableFuture.supplyAsync(() -> userService.getById(userId));
  5. CompletableFuture<List<Order>> ordersFuture = CompletableFuture.supplyAsync(() -> orderService.getRecentForUser(userId, 5));
  6. CompletableFuture<Integer> reviewsFuture = CompletableFuture.supplyAsync(() -> reviewService.countByUser(userId));

  8. // 等待所有操作完成
  9. CompletableFuture.allOf(userFuture, ordersFuture, reviewsFuture).join(); // 第一个主要缺陷

  11. // 如果到达这里，所有服务都成功了
  12. return new UserDashboardDTO(userFuture.get(), ordersFuture.get(), reviewsFuture.get()); // 第二个缺陷
  13. }
java
这段代码在分布式系统中是一个隐藏的地雷。💣
脆弱的失败模式： CompletableFuture.allOf(...).join()创建了"全有或全无"的场景。如果只有一个服务（例如reviewService）超时或抛出错误，join()调用将抛出异常，整个操作失败。用户会看到错误页面，而不是看到他们成功获取的用户详细信息和订单。
没有超时： 没有定义超时。如果orderService很慢，这个线程将无限期挂起，消耗服务器上的资源。
一个更好的、经过深思熟虑的解决方案：
  1. // 精心制作的弹性解决方案
  2. public UserDashboardDTO getDashboard(long userId) {
  3. // 为每个服务调用设置合理的超时
  4. Duration timeout = Duration.ofSeconds(2);
  6. // 使用自定义线程池，而不是ForkJoinPool.commonPool()
  7. Executor timeoutExecutor = Executors.newFixedThreadPool(3);
  9. try {
  10. // 使用单独的CompletableFuture处理每个可能的失败
  11. CompletableFuture<Optional<User>> userFuture =
  12. CompletableFuture.supplyAsync(() -> {
  13. try {
  14. return Optional.of(userService.getById(userId));
  15. } catch (Exception e) {
  16. log.warn("获取用户{}失败", userId, e);
  17. return Optional.<User>empty();
  18. }
  19. }, timeoutExecutor)
  20. .orTimeout(timeout.toMillis(), TimeUnit.MILLISECONDS)
  21. .exceptionally(ex -> Optional.empty());

  23. CompletableFuture<List<Order>> ordersFuture =
  24. CompletableFuture.supplyAsync(() -> {
  25. try {
  26. return orderService.getRecentForUser(userId, 5);
  27. } catch (Exception e) {
  28. log.warn("获取用户{}订单失败", userId, e);
  29. return Collections.<Order>emptyList();
  30. }
  31. }, timeoutExecutor)
  32. .orTimeout(timeout.toMillis(), TimeUnit.MILLISECONDS)
  33. .exceptionally(ex -> Collections.emptyList());

  35. CompletableFuture<Integer> reviewsFuture =
  36. CompletableFuture.supplyAsync(() -> {
  37. try {
  38. return reviewService.countByUser(userId);
  39. } catch (Exception e) {
  40. log.warn("获取用户{}评论数量失败", userId, e);
  41. return 0;
  42. }
  43. }, timeoutExecutor)
  44. .orTimeout(timeout.toMillis(), TimeUnit.MILLISECONDS)
  45. .exceptionally(ex -> 0);

  47. // 等待所有操作完成，但每个都有优雅的降级
  48. CompletableFuture.allOf(userFuture, ordersFuture, reviewsFuture).join();

  50. return new UserDashboardDTO(
  51. userFuture.join().orElse(null), // 可能为null，前端需要处理
  52. ordersFuture.join(), // 永远不为null，最坏情况是空列表
  53. reviewsFuture.join() // 永远不为null，最坏情况是0
  54. );
  55. } finally {
  56. // 清理自定义执行器
  57. if (timeoutExecutor instanceof ExecutorService) {
  58. ((ExecutorService) timeoutExecutor).shutdown();
  59. }
  60. }
  61. }
java
2. 喂养野兽：你项目的上下文是它的燃料 ⛽
AI需要上下文才能生成好的代码。如果你给它提供丰富的项目信息，它会表现得像一个了解你代码库的高级开发者。如果你给它提供很少的上下文，它会产生通用的、可能不适合你的架构的代码。
提供上下文的好方法：
包含相关的类和接口
解释你的架构模式（如六边形架构、DDD）
提及你使用的框架和库
描述业务领域的特殊要求
3. 避开"泥球"：保持代码的可维护性 🧠
AI倾向于生成能工作的代码，但不一定是可维护的代码。你的工作是确保生成的代码符合SOLID原则、设计模式和你团队的架构标准。
关键点：
确保单一职责原则
保持依赖注入的清洁
避免紧耦合
保持一致的命名约定
4. 清理你的房间：没有杂散代码或可疑依赖 🧹
AI可能会引入你不需要的依赖或生成有安全漏洞的代码。始终：
审查所有新的依赖
删除未使用的导入和变量
检查安全最佳实践
验证许可证兼容性
5. 信任但审查：分析AI、代码和供应链 🕵️‍♀️
永远不要盲目信任AI生成的代码。使用工具如：
SonarQube进行代码质量分析
OWASP依赖检查进行安全扫描
静态分析工具
代码覆盖率报告
6. 超越覆盖率：强制进行有意义的测试 ✅
AI可以帮助生成测试，但你需要确保这些测试真正有价值：
测试业务逻辑，不仅仅是代码路径
包含边界条件和错误情况
使用有意义的断言
考虑集成测试和端到端测试
7. 人类网关：为AI看不到的东西进行代码审查 🧠
自动化工具可以捕获语法错误和常见问题，但人类审查关注更高层次的问题：
关注只有人类能判断的事情：
它真的解决了业务问题吗？ 🧠 AI不了解你公司新的退货政策或GDPR数据请求的法律要求的细微差别。
这是一个可维护的设计吗？ 🏗️ 代码今天可能工作，但六个月后初级开发者会理解吗？
隐藏的边界情况是什么？ ⛈️ 基于你的经验，什么可能出错？如果下游API超时会怎样？
这是指导的好机会吗？ 🌱 PR是分享知识的最佳场所之一。
示例：对话，而非判断
想象一个开发者使用AI为一个频繁调用的服务实现了一个缓存层。代码很干净，所有自动检查都通过了。✅
  1. // service/ProductService.java
  2. import com.google.common.cache.Cache;
  3. import com.google.common.cache.CacheBuilder;

  5. @Service
  6. public class ProductService {
  7. // 产品详细信息的内存缓存
  8. private final Cache<Long, ProductDetails> productCache = CacheBuilder.newBuilder()
  9. .maximumSize(1000)
  10. .expireAfterWrite(10, TimeUnit.MINUTES)
  11. .build();

  13. public ProductDetails getProductDetails(long productId) {
  14. // AI正确实现了cache-aside模式
  15. return productCache.get(productId, () -> repository.findDetailsById(productId));
  16. }
  17. }
java
以人为中心的审查在PR评论中：
高级开发者： "嘿，很好地在这里实现了缓存逻辑！AI在Guava缓存实现方面做得很好。非常干净。👍"
"我有一个架构问题供我们思考。这是一个内存缓存，对于单个实例来说是完美的。你认为当我们将其部署到生产环境时会发生什么，生产环境运行这个服务的3个实例以实现高可用性？"
"风险是缓存可能会不同步。管理员可能更新产品的详细信息，该请求可能命中实例A，更新其缓存。但实例B和C仍将在10分钟内提供旧的、过时的数据。"
"这可能是我们引入像Redis这样的分布式缓存的好机会。它将解决一致性问题，并为我们提供一个集中的地方来管理我们的缓存策略。这是一个更大的变化，但它将使我们的系统更加健壮。你对这种方法有什么想法？在这个PR中没有压力，但让我们讨论一下。🤔"
这个审查完成了人类审查应该做的一切。它验证了工作，分享了关于分布式系统的深入知识，防止了未来的生产问题，并且都以协作、尊重的方式完成。这是AI无法进行的对话。这是我们人类提供真正价值的地方。
结论：你的AI副驾驶需要安全网 🚀
AI辅助开发的时代不是要取代开发者；而是要升级他们。
我们探索的七个习惯是一个路线图，用于从AI的简单"用户"转变为熟练的工匠，以意图和智慧运用它。这是关于为你的工作感到自豪，提供深入的上下文，要求可维护性，实践良好的卫生习惯，审查一切，编写重要的测试，以及将人类元素保持在审查的核心。
培养这些习惯是一个有意识的努力，但你不必独自做。当你专注于高级设计和业务逻辑时，你需要一个安全网来捕获AI可能引入代码中的微妙错误、安全漏洞和不良实践。这就是为什么拥有自动化代码质量和安全工具集变得不可协商的原因。
这就是为什么你应该查看Sonar解决方案。通过添加SonarQube IDE扩展（IntelliJ、VS Code等），你可以在代码生成时获得实时反馈，在提交之前捕获bug和漏洞。然后，通过将其连接到SonarQube Cloud，你的整个团队对项目的健康状况有了共同的理解，确保你发布的不仅仅是功能性的，而且真正具有高质量和安全性。把它想象成你开发过程中的完美第三个合作伙伴：你的技能、AI的速度和Sonar的安全性。