跬步 On Coding

整洁架构落地实践

Aug 4 2025

最近在新公司接手了一个历史悠久的项目，功能不多，代码量却不小。深入其中，才发现有太多太多的槽点，简直让人头大。每当要新增一个功能或者修复一个 Bug，都感觉像是在雷区里跳舞，步步惊心。

总结下来，这个项目主要有这么几个“硬伤”：

  1. 代码逻辑不内聚：同一个功能的实现，像天女散花一样分散在好几个不同的文件里，想理清完整的逻辑链条，得在 IDE 里跳来跳去，极其耗费心智。
  2. 分层过多且混乱：一个简单的请求，要穿越重重关卡，经过好几个层级的调用才能抵达终点。有时你都分不清某一层到底是干嘛的，感觉纯粹是为了分层而分层。
  3. 内部自研框架不好用：项目依赖了一个内部的 kgo 框架，但文档缺失，设计理念也比较陈旧，出了问题排查起来非常困难。
  4. 外部依赖离散：对数据库、缓存、外部 API 的调用封装得五花八门，没有统一的规范和入口，整个项目像一个杂乱的“百宝箱”。

恰好，Leader 对这个项目制定了新的方向与目标，之前这些遗留问题实实在在成了我们前进路上的绊脚石。因此，一次彻底的架构升级与重构势在必行。同时，部门内也正在推广项目规范化和最佳实践输出，这简直是天赐良机。

很久以前我就读过《架构整洁之道》这本书，在之前的项目中也或多或少受到一些启发，但从未有机会从一个项目初始就完整地贯彻整洁架构的理念。这次，我决定抓住机会，来一场彻彻底底的整洁架构实践。在这个过程中，我感觉自己对整洁架构的理解，以及对 SOLID 原则的落地方式，都有了前所未有的深入体会。

打造一个属于自己的AI书签

Jul 7 2025

前言

我一直是个重度的书签使用者，多年来都依赖 Pocket 来收藏和沉淀那些在网上看到的、值得一读的文章。然而，最近 Pocket 宣布其通知服务即将关闭，这对我来说像是一个信号，是时候去寻找一个更稳定、更可控的替代品了。

我的探索之旅就这样开始了：

  1. Raindrop.io：社区里很多人推荐，功能也确实强大。但不知道是不是网络原因，我这边访问起来总是感觉有点慢，而且用惯了 Pocket 的我，对它的界面和交互逻辑始终有些不太习惯。
  2. 自建服务：作为程序员，第一反应自然是自己动手。我找到了像 linkding 这样的优秀开源项目。我尝试把它部署在 fly.io 的免费实例上，但 linkding 对资源的要求不低，最低配的 256M 内存实例直接就 OOM (Out of Memory) 了，升级配置又意味着成本。
  3. 从零开始写一个？ 这个念头一闪而过。我甚至构思好了技术选型：参照 linkding 的功能，用我最近在学习的 Rust 实现后端，部署在 Cloudflare Workers 上，再配上 Cloudflare D1 的 SQLite 数据库。这套方案 Serverless、成本极低，堪称完美。但转念一想，这工程量可不小，对于业余项目来说，我实在没有那么多时间投入进去。

就在我快要放弃，准备将就着用某个方案时，我想起了一篇以前收藏过的文章。

我理解的AI Agent与MCP

Apr 2 2025

前言

最近AI圈子里Manus这个项目可以说是相当火了，连带着MCP（Model Context Protocol）这个概念也开始频繁出现在各种技术讨论区。作为一个程序员，自然也对这些新东西充满了好奇，于是花时间捣鼓了一下AI Agent和MCP相关的知识。这篇文章就是我学习和思考后，对这两个概念的一些个人理解和梳理。

1. 从Workflow到AI Agent：大脑的进化

回顾我们以前做自动化任务，比如搞个自动抢票、自动下单之类的，思路基本都是围绕着一个固定的workflow。我们会预先设定好一套流程逻辑：收到指令 -> 判断条件 -> 走对应分支 -> 调用特定工具（API、脚本等）。整个过程就像一个流程图，每个节点和路径都是我们程序员预先设计好的。在这个模式下，我们程序员就是这个workflow的“大脑”，我们把执行计划通过代码逻辑，“硬编码”到系统里。比如预定机票这个场景，我们会写代码一步步调用查询接口、选择航班接口、填写乘机人信息接口、支付接口等等。

云原生开发入门

Mar 28 2025

作为一名在云原生领域摸爬滚打了一段时间的开发者，我时常会遇到一些刚接触这个领域的朋友，他们面对 Kubernetes (K8s)、容器这些概念时，常常感到有些迷茫，不知道从何学起。这篇文章，我想结合自己的一些学习体会，为想要入门云原生开发的同学提供一个相对清晰的指引。

我自己并非科班出身，从最初接触软件测试写 Lua 脚本，到后来学习 Python 做后端，再到进入腾讯接触 Golang 和 K8s 相关开发，一路走来也踩了不少坑。云原生技术栈确实庞大，但核心的理念是利用容器、微服务、声明式 API 等方式，去构建更可靠、更具弹性的分布式系统。而 K8s 作为这个生态的核心编排引擎，可以说是我们必须掌握的关键技能。

这篇文章，我会从基础概念聊起，分享几本我学习过程中觉得非常有帮助的书籍，一个不错的社区文章集合，以及两个可以动手实践的代码项目。最后，还会结合实际工作经验，聊聊 K8s 运维实践中一些重要的事情。希望这些能帮助大家在学习云原生的路上少走一些弯路。

一、云原生与 Kubernetes：从基础概念开始

云原生到底是什么？

我理解的云原生（Cloud Native），它不是指某一个具体的技术，更像是一种面向云环境的应用设计、开发和部署的最佳实践集合。它鼓励我们使用像容器、微服务、不可变基础设施、声明式 API 这些技术和方法，目标是让我们的应用能更好地利用云计算的弹性、分布式、自动化等优势。根据 CNCF（云原生计算基金会）的定义，这些是关键要素。简单说，就是让应用为云而生，能在云上运行得更好。

为什么 Kubernetes 这么重要？

容器技术（比如 Docker）解决了环境一致性的问题，但当你有成百上千个容器需要管理时，手动操作就变得不现实了。Kubernetes 就是来解决这个问题的。它是一个开源的容器编排平台，最初由 Google 开发，现在由 CNCF 维护。它可以自动化地完成应用的部署、扩缩容、服务发现、负载均衡、故障恢复等一系列复杂工作。在我看来，掌握 K8s 是进入现代后端开发、特别是平台工程领域的一张重要门票。

我的学习路径建议：

回顾我自己的学习过程，我建议可以按以下步骤来：

  1. 先搞懂容器：理解 Docker 的基本概念，比如镜像（Image）、容器（Container）、Dockerfile，能自己动手构建、运行一个简单的容器化应用。
  2. 再深入 K8s 核心：学习 K8s 的核心组件（比如 Pod、Service、Deployment、StatefulSet、Namespace 等）都是做什么的，它们之间是如何协作的。了解控制平面（Master）和数据平面（Node）的基本工作原理。
  3. 动手实践是关键：理论学习后，一定要动手实践。尝试编写 YAML 文件部署应用，使用 kubectl 与集群交互。然后可以去探索存储（Volumes, PV, PVC）、网络（Ingress, CNI）、配置（ConfigMap, Secret）等更深入的主题。
  4. 理解运维视角：开发的应用最终要跑在生产环境。了解 K8s 集群的监控、日志、告警、排错等运维实践，对于写出更健壮、更易于维护的应用非常有帮助。

接下来，分享一些我在学习过程中用过且觉得不错的资源。

从《软件设计的哲学》谈代码的复杂性与应对

Jan 10 2025

几个月前读完了《软件设计的哲学》这本书，在结合自己多年的工作体会，对于代码的可读性，可维护性有了系统性的体会，然后基于我记录的读书笔记然后经过AI的润色，形成了这篇笔记。希望对你也有所帮助。

读完《软件设计的哲学》，感觉像经历了一次代码的“深度体检”。这本书没有讲解具体的编码技巧，而是从更高的维度帮助我们重新审视代码复杂性的问题，并提出了许多实用的建议。今天，我想结合自己的理解，分享这本书带来的启发。

什么是代码的复杂性？

简单来说，复杂性就是那些让系统难以理解和修改的因素。它不仅仅指代码的行数或逻辑深度，还包括：

  • 难以理解：即便是自己写的代码，过一段时间可能也看不懂，更别提其他人。
  • 修改成本高：一个小改动需要改动多个地方，甚至引发新的问题。
  • 模糊的改动范围：不知道该修改哪些模块才能实现目标，或者不确定修改后是否会引发其他问题。
  • 难以修复的错误：修复一个 bug 可能需要大量时间，还可能引入新的问题。