方法论

很多时候讨论方案，“这个改起来简单”，然后就没有人说话了。简单没有错，问题是简单就是指这一次改动的简单呢？那运维的简单性、扩展的简单性、稳定的简单性、排查的简单性呢？ 现象 很多时候讨论方案，“这个改起来简单”，然后就没有人说话了。 因为这东西真有点无从反驳。 改起来简单，风险就低，你怎么反驳，又不是你改，又不是你背锅。 包括网络上有一些图，基本表达是"能跑就别动"。 但是这玩意真的对吗？ 有些时候不是跑的问题，是业务发展、竞品拼杀、商业博弈，必须有做一些特性和功能，这个时候是必须要动。 简单不是唯一标准 动不是问题，问题是怎么动，衡量标准是什么。 简单没有错，问题是简单就是指这一次改动的简单呢？ 那运维的简单性呢？扩展的简单性呢？稳定的简单性呢？排查的简单性呢？这些都不谈？ 比如要对接第三方备份厂商，居然有其他厂商入侵到我们计算节点，并且到我们计算节点删除 img 的操作方案。 可能这次是简单了，那下次呢？下个备份厂商呢？ 包括备份对接 s3 接口，多好的需求，符合生态，非常标准化。 结果硬是做成了非标能力，绑定存储，绑定各种特定流程，非得模仿老功能，依赖中转节点。 难道就不能从计算节点直接上传 s3？ 数不胜数的例子，这类问题，基本都是当时评审的时候"这个方案改动小"导致的。 这类问题真无解 这类问题其实真无解，就看 leader 的品味。 因为其他队员发言是没有权威的，文无第一。 尤其是"改动小"，比如你的方案实现了从计算节点直接上传备份到 s3，并且是标准 s3 接口，以后不做改动对接任何备份厂商。 很好吧，所有人都知道这是对的，但是不会有人主动去赞同，因为改动大，得背锅。 这类问题短期没有人在意，但是时间长了，赚钱的部门、商业线第一个跳出来： “你们写的代码怎么这么多限制，为什么别人支持，我们不支持，很奇怪。为什么这个支持 s3，那个不支持，很奇怪。” 不过到这依然没有结论，依然看 leader 的品味，看老板的品味。 小结 简单是唯一标准吗？不是； 简单没有错，问题是简单就是指这一次改动的简单呢； 还要考虑运维的简单性、扩展的简单性、稳定的简单性、排查的简单性； 这类问题真无解，就看 leader 的品味； 所有人都知道是对的，但不会有人主动去赞同，因为改动大，得背锅。

跟随主流技术非常重要，不要老用一些偏门的、古怪的技术凸显自己的别具一格。技术是手段，不是目的，所以越主流越好。 核心：跟随主流技术 跟随主流技术，非常重要。 不要老用一些偏门的、古怪的技术，凸显自己的别具一格。 比如，用 lxc 还是 docker。 别说两者底层原理都一样，用 lxc 自身可控性更好。生态和工具的适配完全是天和地的区别，这已经不是跨级别的问题，而是天壤之别。 再比如网络，主流都是用 ovs，所以别人智能网卡、dpu、新的一些设备、网络卸载等，适配的都是 ovs。 你自己搞一套，或者用小众的，别人不适配你啊。 还有国产化，都是靠着主流去适配的。 技术是手段，不是目的 技术是手段，不是目的。 所以，越主流越好。 主流代表着稳定、可靠、被大规模多场景验证过，同时有大量的解决方案和排查知识，也有大量的人才支撑。 手段不用在意创新，只需要稳定、可达、低成本。目的才需要考虑创新，创造价值差异。 小结 跟随主流技术非常重要； 不要老用偏门的、古怪的技术凸显自己的别具一格； 生态和工具的适配是天壤之别； 技术是手段，不是目的，越主流越好； 主流代表稳定、可靠、被大规模验证过，有大量解决方案和人才支撑。

要不要抽象，关键在于要不要复用。业务流程都是独立的，不需要复用；技术类流程需要复用。一写二抄三重构，第二次大量重复时就可以开始重构了。 现象 写代码的时候，总纠结要不要抽象流程、抽象对象、面向组合。 这样很难，因为没有明确的复用需求，不知道稳定点在哪。 核心：一写二抄三重构 一写，二抄，三重构。 要不要抽象，关键在于要不要复用。 业务流程都是独立的，不需要复用，所以谈不上抽象； 技术类的流程，是需要复用的。 但是没必要第一次就绞尽脑汁抽象流程、抽象对象、面向组合。 第二次是抄还是重构 不是说第二次就一定是抄。 如果是一个方法，抄没问题； 如果是一个流程，一堆方法，第二次抄就不合理了。 这样的后果是第三次重构非常困难，甚至会因为功能的兼容影响没法进行。 如果是大量的话，第二次就可以开始重构了。 抽象流程 vs 抽象对象 k8s 为什么牛逼，原因在于它定义了一套声明式的流程。 我们创建主机、创建备份等，看起来流程不一样，但是上升一个维度，都能用声明式的流程来处理。 但 2026 年更新后的认知是：k8s 是极致的面向对象。 虽然它的控制器是面向流程的，但是控制器仅仅是对象下的血肉。 顶层还是围绕对象设计的； 控制器是属于对象的； k8s 极致面向对象，消除流程，将流程隐藏在对象中。 流程是易变的，对象是相对稳定的，所以不会去抽象流程，而是抽象对象。 一个例子：采集 pv-lv 和 lv info 数据采集、数据同步，涉及到新增和删除。 所以这里的流程最后抽象为： 采集； 从 db 获取； diff 得到 insert 和 delete； 执行 insert 和 delete。 不同的数据对象，提供支持 diff、insert 和 delete 的方法即可。 这个流程也不是一开始就想出来的，也是边写、边思考做出来的。 小结 要不要抽象，关键在于要不要复用； 业务流程独立，不需要复用；技术类流程需要复用； 一写二抄三重构，第二次大量重复时就可以开始重构； 流程是易变的，对象是相对稳定的，所以抽象对象而非流程； 好的抽象是边写边思考做出来的，不是一开始就设计好的。

写代码高价值套路：代码写三遍。第一遍跑通，第二遍防御，第三遍优化。过早的优化是万恶之源，尤其是新服务新项目的时候。 现象 写代码的时候，总想一步到位。 前期查看各种基础知识，耗费时间；后面组织结构，想日志封装、调度封装，又耗费时间比较多。 结果两周没写完。 核心：代码写三遍 来自华哥（李运华）的写代码高价值套路原则： 防御性编程； 代码写三遍； 快速失败； 面向对象原则； 短函数。 其中"代码写三遍"是核心： 跑通：先把功能跑通； 防御：加上防御性编程； 优化：最后再优化。 过早的优化是万恶之源。尤其是在新服务新项目的时候。 为什么写三遍反而更快 比如这次的"自愈组件"。 如果按照写三遍： 跑通，最多 4 天； 异常场景最多 1 天； 后面针对性优化、针对性学习，学习效率高。 比如先针对学习日志，针对优化调度，这个过程中会思考是否过度优化，其实发现很多没必要。 关键这是一个快速交付的路径，很快有结果，没有汇报压力。 没有压力，有条不紊，是非常重要的一个因素。 防御性编程 防御性编程包括： 安全：边界、非法值校验、特殊情况、异常情况等； 快速失败、回滚等； 追踪：日志等。 小结 代码写三遍：跑通、防御、优化； 过早的优化是万恶之源，尤其是新服务新项目； 写三遍反而更快，因为快速交付、没有汇报压力； 没有压力、有条不紊，是非常重要的因素； 防御性编程：安全、快速失败、追踪。