介绍页
关于郑天祺
此站是个人站，记录分享学习平时学习，喜欢编程的小伙伴可以加我共同探讨，一起进步。
小于 1 分钟
GitHub Actions 实战：Java 项目的 CI/CD 流水线搭建
从零搭建一条完整的 Java 项目 CI/CD 流水线，包含编译、测试、代码扫描、Docker 镜像构建和多环境自动部署。
1. CI/CD 核心概念与价值
1.1 什么是 CI/CD
传统开发流程（无 CI/CD）：
开发 → 本地测试 → 提交代码 → [等待] → 集成 → [发现冲突] → 排查 → 修复 →
手动构建 → 手动测试 → 手动部署 → [部署失败!] → 排查 → 重新部署
时间：数小时到数天
现代 CI/CD 流程：
开发 → 本地测试 → 提交代码 →
┌───────────────────────────────────────────────┐
│ CI（持续集成） │
│ 自动检出 → 编译 → 单元测试 → 代码扫描 → 构建镜像 │
│ 时间：5-10 分钟 │
└───────────────┬───────────────────────────────┘
│ 全部通过
▼
┌───────────────────────────────────────────────┐
│ CD（持续交付/部署） │
│ 自动部署到 dev → 集成测试 → 部署到 staging → │
│ 部署到 production（手动审批或自动） │
└───────────────────────────────────────────────┘
大约 10 分钟
Jenkins 完全指南：从"又老又丑"到"CI/CD 常青树"
如果你问一个 10 年经验的后端："十年前你们怎么部署代码？" 他八成会叹口气，然后说出那个让他又爱又恨的名字——Jenkins。
一、用故事开头：Jenkins 到底是干嘛的？
想象一个场景：
凌晨 2 点，你刚写完最后一个功能。测试说 OK，前端说联调通过。现在你要——
- 拉最新代码
- 跑一遍测试
- 打个 war/jar 包
- 上传到服务器
- 停掉旧服务
- 启动新服务
- 确认部署成功
- 给群里发个通知
大约 10 分钟
部署策略对比：蓝绿 vs 金丝雀 vs 滚动，怎么选
部署策略选错，轻则用户体验受损，重则生产事故。本文从原理到实践，帮你做出正确选择。
1. 四种主流部署策略图解
1.1 策略全景图
┌─────────────────────────────────────────────────────────────────┐
│ 四种部署策略对比 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 滚动更新（Rolling Update） │
│ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │
│ │ v1 │ → │ v2 │ → │ v2 │ → │ v2 │ 逐个替换 │
│ └───┘ └───┘ └───┘ └───┘ │
│ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │
│ │ v1 │ │ v1 │ → │ v2 │ → │ v2 │ │
│ └───┘ └───┘ └───┘ └───┘ │
│ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │
│ │ v1 │ │ v1 │ │ v1 │ → │ v2 │ │
│ └───┘ └───┘ └───┘ └───┘ │
│ │
│ 蓝绿部署（Blue-Green） │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Blue (v1) │ 切换 → │ Green (v2) │ │
│ │ 所有流量在这里 │ ──────→│ 所有流量切过来 │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ 金丝雀发布（Canary） │
│ 流量: 90% v1 ──┐ │
│ ├──→ 观察指标 → 10% OK → 50% → 100% │
│ 流量: 10% v2 ──┘ │
│ │
│ A/B 测试 │
│ 用户群A → v1 (对照组) │
│ 用户群B → v2 (实验组) → 对比转化率/留存率 │
│ │
└─────────────────────────────────────────────────────────────────┘
大约 13 分钟
AI Coding 工具对研发团队管理的影响
前言
2024 年，GitHub Copilot 月活用户突破 180 万。2025 年，Cursor、Claude Code、Devin 等 AI 编程工具如雨后春笋般涌现。2026 年，AI Coding 工具已经从"开发者的个人玩具"变成了"团队的生产力工具"。
作为技术管理者，你可能已经在思考：AI Coding 工具应该如何落地？它对团队管理意味着什么？代码审查标准要不要改？新人培养方式要不要调整？
本文将系统性地回答这些问题。
一、AI Coding 工具全景
大约 13 分钟
从需求文档到技术方案：PM 和 RD 的高效协作模式
前言
PM 和 RD 的关系，大概是互联网公司里最经典的"爱恨交织"。PM 觉得 RD 总是说"做不了"，RD 觉得 PM 总是在"改需求"。
但真相是：PM 和 RD 不是对立面，而是同一枚硬币的两面。 PM 定义了"做什么"，RD 决定了"怎么做"。两者配合得好，产品就能又快又好地上线；配合得不好，就是无尽的返工和互相甩锅。
本文从 RD（后端开发）的视角，探讨如何与 PM 高效协作，从需求文档平滑过渡到技术方案。
大约 13 分钟
如何用数据驱动技术重构决策
前言
"这个模块该重构了！代码太烂了！" ——每个开发都说过这句话。
但当你把这句话翻译给老板时，老板问："重构要多久？有什么收益？不做会怎样？"你突然发现，除了"代码太烂"之外，你并没有什么有力的论据。
本文将介绍如何用数据来驱动技术重构决策——让你在提出重构时，不再是凭感觉，而是拿出让人信服的数据。
一、什么时候该重构：数据驱动的决策模型
1.1 重构决策矩阵
重构决策矩阵：
│ 数据不支持 │ 数据支持
──────────────┼────────────────┼─────────────────
业务需要 │ 谨慎评估 │ ✅ 高优先级重构
（需求频繁） │ 可能不是好时机 │ 业务 + 技术双驱动
──────────────┼────────────────┼─────────────────
业务不需要 │ ❌ 不建议重构 │ 中优先级重构
（需求稀少） │ 改了也没人用 │ 技术驱动，主动预防
大约 12 分钟
技术债管理：从识别到清偿的完整策略
前言
你有没有经历过这样的场景？
"这段代码是三年前老王写的，老王已经离职了。我们谁都不敢动它，一动就出事。但我们又不得不在上面加新功能，每次加都像在雷区里走——不知道哪一步就会触发一个隐藏的 bug。"
这就是技术债的典型症状。它不是一朝一夕形成的，而是日积月累的结果。本文将系统性地介绍如何识别、量化和管理技术债，让你的团队不再被它拖累。
一、什么是技术债，为什么会有
1.1 技术债的定义
大约 15 分钟
技术方案怎么写才能让产品经理看懂
前言
你花了三天写了一份 20 页的技术方案，满怀信心地发给 PM，结果 PM 只回了一句：
"我看不太懂，你能用大白话讲一下吗？"
挫败感拉满。但冷静下来想想：PM 看不懂你的技术方案，真的只是 PM 的问题吗？
技术方案需要两个版本：一个给技术团队看的"完整版"，一个给 PM 和业务方看的"产品化版本"。本文教你如何写出让 PM 也能看懂、愿意看、看了有用的技术方案。
大约 12 分钟
技术方案怎么写：一个后端视角的评审清单
前言
你有没有经历过这样的技术评审？
PM："我们这个需求很简单，就是加一个按钮，用户点了就能导出报表。"
你（后端）："好的。"
一周后，你发现这个"简单按钮"需要跨 3 个微服务查数据、实时聚合 500 万行记录、支持 10 万用户并发导出。
技术方案，就是这个"简单按钮"与你实际要写的 3000 行代码之间的桥梁。本文将从一个后端开发的视角，告诉你如何写出一个不会被评审会"怼穿"的技术方案。
大约 16 分钟
...