/tags/%E4%BB%A3%E7%A0%81/Recent content in 代码 on 文叨叨 | IaaS 排障手记Hugozh-cnSat, 28 Mar 2026 10:00:00 +0800/posts/constant-single-source/Sat, 28 Mar 2026 10:00:00 +0800/posts/constant-single-source/魔数、默认值使用常量封装。提高可读性，统一定义唯一来源，唯一来源相当于是统一了标准。常量在离使用代码最近的地方定义比较好。/posts/design-principles-avoid-problems/Sun, 22 Mar 2026 10:00:00 +0800/posts/design-principles-avoid-problems/把只读状态写到了事务字段里，明显不符合单一原则。一个字段怎么能表示多种意思呢？如果一开始就不违反单一原则，即便没想到并发冲突问题，也不会出现问题。/posts/patch-object-oriented/Sat, 21 Mar 2026 10:00:00 +0800/posts/patch-object-oriented/哪里遇到问题了，就找个地方加个开关、加个检查、加个条件判断来处理掉。这导致不够系统化，引入了局部的分支点，会造成多流程的耦合交叉，扩展容易遗漏。/posts/code-consistency-interface/Sat, 14 Mar 2026 10:00:00 +0800/posts/code-consistency-interface/不仅数据有一致性问题，代码的一致性问题更加遍地都是。判断主机是否运行应该面向 libvirt 接口，而不是面向实现中的文件、过程。/posts/interface-oriented/Sun, 08 Mar 2026 10:00:00 +0800/posts/interface-oriented/接口很多时候听起来很有道理，写的时候会质疑是不是为了接口而接口。一写二抄三重构，前面没有必要的时候不用接口，后面重复的时候可以引入接口。/posts/encapsulation-vs-independent/Sat, 07 Mar 2026 10:00:00 +0800/posts/encapsulation-vs-independent/封装仅仅是为了复用，但是独立有管理能力。封装调用了就得执行，独立有自己的一套管理规则，比如排队、限流、调整优先级、丢弃、转换等。/posts/bottom-default-value/Sun, 01 Mar 2026 10:00:00 +0800/posts/bottom-default-value/底层（被依赖者）最好有默认值，上层（依赖者）可以少硬编码。判断不是问题，问题是重复判断；硬编码本身是必须的，问题是重复的硬编码。/posts/one-goal-one-implementation/Sat, 28 Feb 2026 10:00:00 +0800/posts/one-goal-one-implementation/不要封装太多的实现方法，会造成使用复杂度。一个目的提供一种方法，提供的太多，反而让使用者陷入学习复杂性。/posts/encapsulation-frequency-not-complexity/Sun, 22 Feb 2026 10:00:00 +0800/posts/encapsulation-frequency-not-complexity/如果一个工具仅仅在一两个地方调用，那无所谓封装。如果一个工具通篇各处都在调用，那就一定要封装了，即便这个工具仅仅是一行命令。/posts/wrap-third-party-call/Sat, 21 Feb 2026 10:00:00 +0800/posts/wrap-third-party-call/调用第三方工具一定要封装，哪怕仅仅是一个命令行。封装的好处：应对版本变化、方便做切面、简化使用、提供统一方法。/posts/abstract-flow-vs-object/Sun, 15 Feb 2026 10:00:00 +0800/posts/abstract-flow-vs-object/要不要抽象，关键在于要不要复用。业务流程都是独立的，不需要复用；技术类流程需要复用。一写二抄三重构，第二次大量重复时就可以开始重构了。/posts/code-write-three-times/Sat, 14 Feb 2026 10:00:00 +0800/posts/code-write-three-times/写代码高价值套路：代码写三遍。第一遍跑通，第二遍防御，第三遍优化。过早的优化是万恶之源，尤其是新服务新项目的时候。