<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://tobyqin.cn/</id><title>Practice</title><subtitle>A professional blog dedicated to sharing insights, experiences, and best practices in software engineering.</subtitle> <updated>2026-02-22T14:07:01+08:00</updated> <author> <name>Toby Qin</name> <uri>https://tobyqin.cn/</uri> </author><link rel="self" type="application/atom+xml" href="https://tobyqin.cn/feed.xml"/><link rel="alternate" type="text/html" hreflang="cn" href="https://tobyqin.cn/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 Toby Qin </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>2026：软件自建的幻觉与真相</title><link href="https://tobyqin.cn/posts/2026-02-22/software-builds-itself/" rel="alternate" type="text/html" title="2026：软件自建的幻觉与真相" /><published>2026-02-22T00:00:00+08:00</published> <updated>2026-02-22T14:06:40+08:00</updated> <id>https://tobyqin.cn/posts/2026-02-22/software-builds-itself/</id> <content type="text/html" src="https://tobyqin.cn/posts/2026-02-22/software-builds-itself/" /> <author> <name>Toby Qin</name> </author> <category term="Tech" /> <summary>2024年我们在卷 AI 辅助编码。2025年我们在卷多智能体协作。 进入 2026 年，行业共识变了。人类不应该再通过手工编码来构建软件，而应该通过定义一个会生长的系统来生成软件。 这就是所谓的软件自建。 软件形态：从大型单体到液态流动 回看这几十年，软件的形态一直在变。 最早是单体架构。像一块实心的巨石，不仅重，而且牵一发而动全身。 后来有了模块拆分和微服务。巨石变成了乐高积木，虽然灵活了，但本质还是静态的拼接。 再到 Serverless。积木开始虚拟化。 而“软件自建”指向的终点是液态软件。 它仿佛可以适配任何场景，按意图流动变化。你不再需要预先设计死板的接口，系统根据此时此刻的业务需求，自动流淌出最合适的逻辑分支。它不再是死掉的代码仓库，它是活的。 消失的流程：再见，JIRA Ticket 如果软件能自建，意味着需求到生产的链路被彻底压缩。 现在大家...</summary> </entry> <entry><title>平台工程的尽头是什么？</title><link href="https://tobyqin.cn/posts/2026-02-12/platform-engineering-endgame/" rel="alternate" type="text/html" title="平台工程的尽头是什么？" /><published>2026-02-12T00:00:00+08:00</published> <updated>2026-02-12T00:00:00+08:00</updated> <id>https://tobyqin.cn/posts/2026-02-12/platform-engineering-endgame/</id> <content type="text/html" src="https://tobyqin.cn/posts/2026-02-12/platform-engineering-endgame/" /> <author> <name>Toby Qin</name> </author> <category term="Tech" /> <summary>平台工程火了，但很多人理解错了。它不是把DevOps团队换个名字。 我见过太多平台工程做成工具展厅的。Jenkins、GitLab、ArgoCD、Kubernetes，工具买了一堆，开发者却更累了。为什么？因为从一开始，方向就错了。 平台工程的尽头，不是更多的工具，而是让工具消失。 三个阶段 平台工程的发展，大致经历三个阶段。 第一阶段，工具堆砌期。 每个团队自己选型。A组用Jenkins，B组用GitLab CI，C组用CircleCI。各自为战，各显神通。看起来是赋能，其实是混乱。运维要维护十套CI系统，开发者要学十个不同的配置语法。 第二阶段，标准化期。 公司看不下去了，成立平台团队，统一工具链。全部迁移到GitLab，全部用Helm部署，全部接入统一的监控。效率确实提升了，但怨声载道。开发者被强迫改变习惯，平台团队成了”中央集权”的坏人。 第三阶段，能力赋...</summary> </entry> <entry><title>工程师转管理的五个坑，我全踩过</title><link href="https://tobyqin.cn/posts/2026-02-11/engineer-to-manager-five-mistakes/" rel="alternate" type="text/html" title="工程师转管理的五个坑，我全踩过" /><published>2026-02-11T00:00:00+08:00</published> <updated>2026-02-11T13:08:26+08:00</updated> <id>https://tobyqin.cn/posts/2026-02-11/engineer-to-manager-five-mistakes/</id> <content type="text/html" src="https://tobyqin.cn/posts/2026-02-11/engineer-to-manager-five-mistakes/" /> <author> <name>Toby Qin</name> </author> <category term="Management" /> <summary>管理不是升职，是换了一条更难的路。 刚转管理时，我以为升职是对自己能力的证明。后来才明白，那其实是对能力的”反证明”。做工程师时的那些能力，在管理岗位上并不能直接复用。有时候甚至要打掉旧思维，建立新思维。 不破不立。 这些年踩过不少坑。有些坑当时以为是别人的问题，后来才发现是自己没转过来。五个坑，五个教训。 坑一：微观管理 我当时的做法： 每段代码都要Review，每个技术方案都要过问。团队成员变得小心翼翼，连最简单的重构都要找我确认。 真相： 我不是在管质量，我是在缓解自己的焦虑。我害怕失控，所以抓住每一个细节。结果呢？团队学会了”向上管理”。不做错，也不做多。 反转时刻： 有次我生病请假一周，回来发现代码库干净得出奇。原来没有我的时候，他们做得很好。 坑二：技术优越感 我当时的做法： “这个方案不行，我来写。” 这句话我说过太多次。下属的方案总...</summary> </entry> <entry><title>在无限游戏中，做一个永远的玩家</title><link href="https://tobyqin.cn/posts/2026-02-08/finite-and-infinite-games/" rel="alternate" type="text/html" title="在无限游戏中，做一个永远的玩家" /><published>2026-02-08T00:00:00+08:00</published> <updated>2026-02-11T13:50:32+08:00</updated> <id>https://tobyqin.cn/posts/2026-02-08/finite-and-infinite-games/</id> <content type="text/html" src="https://tobyqin.cn/posts/2026-02-08/finite-and-infinite-games/" /> <author> <name>Toby Qin</name> </author> <category term="Life" /> <summary>世界上有两种游戏。有限的游戏以取胜为目的，无限的游戏以延续游戏为目的。 这是詹姆斯·卡斯在《有限与无限的游戏》里的核心观点。第一次读到时，让我重新思考了很多事情。原来我把太多精力花在有限游戏上，却忘了自己本来可以玩无限游戏。 有限游戏的陷阱 面试、晋升、跳槽。这些都有明确规则、清晰终点、唯一赢家。 它们没有错，甚至是必要的。但问题是，当我们把所有精力都投入到有限游戏时，会产生一种错觉，胜利就是终点。 于是我们背诵八股文、做秀式加班、包装简历。然后呢？下一场面试、下一次晋升永远在等着。我们在一个又一个有限游戏中疲于奔命，却从未问过自己，这个游戏本身，值得我玩吗？ 把无限游戏玩成有限游戏 2024年，AI爆发让整个技术圈陷入集体焦虑。 大模型能写代码了，工程师是不是要失业了？这些问题背后，是典型的有限游戏思维，把技术演进当成有终点的竞赛，要掌握那个不会被AI取代的技能。...</summary> </entry> <entry><title>课题分离</title><link href="https://tobyqin.cn/posts/2026-01-17/separation-of-tasks/" rel="alternate" type="text/html" title="课题分离" /><published>2026-01-17T00:00:00+08:00</published> <updated>2026-01-17T22:54:28+08:00</updated> <id>https://tobyqin.cn/posts/2026-01-17/separation-of-tasks/</id> <content type="text/html" src="https://tobyqin.cn/posts/2026-01-17/separation-of-tasks/" /> <author> <name>Toby Qin</name> </author> <category term="Thoughts" /> <summary>课题分离是由奥地利心理学家阿尔弗雷德·阿德勒提出的一种心理学概念。 简单来说，课题分离是指：分清什么是你的课题，什么是我的课题。 这是谁的课题 阿德勒提供了一个非常简单的判别准则：因为这个决定而带来的后果，最后由谁来承担？ 如果孩子不学习，最后成绩差、申请不到理想学校的后果由谁承担？是孩子。 因此，学习是孩子的课题，而不是家长的课题。 你是否努力工作、是否尽责，由你承担后果，这是你的课题。 老板是否认可你、是否给你升职加薪，后果由老板承担，他可能失去人才或留住人才，这是老板的课题。 课题分离要求我们在处理人际关系时，遵循两个基本守则。 不干涉他人的课题。不要指手画脚，不要试图强迫别人按你的意愿行动。即使是父母对孩子、伴侣之间，也需要尊重边界。 不让别人干涉自己的课题。走自己的路，不对他人的期待负责。你不需要为了迎合别人的评价而改变自己。 为什么要课题分离 阿德...</summary> </entry> </feed>
