掘金专栏可能会更新不及时，欢迎大家移步道德经：程序之路
天下皆知美之为美，斯恶已。
皆知善之为善，斯不善已。
故有无相生，难易相成，长短相形，高下相倾，音声相和，前后相随，恒也。
是以圣人处无为之事，行不言之教，万物作焉而不辞，生而不有，为而不恃，功成而弗居。
夫唯弗居，是以不去。
《道德经》第二章谈的是一个技术人很熟悉的问题：什么才算“好”？
好代码应该简洁，好架构应该先进，好产品应该克制，好团队应该高效。我们需要这些标准，否则代码无法评审，需求无法取舍，团队也很难协作。
可老子提醒我们，一旦大家共同认定了什么是美，丑也随之出现；当某种做法被定义成善，其他选择就很容易被归入“不善”。
标准帮助我们判断，也可能遮住真实场景。
当“好”被固定下来
“天下皆知美之为美，斯恶已。”
这句话不是反对美，而是在说美从来不是孤立存在的。我们称赞一种选择时，也在无形中贬低另一种选择。
技术圈就经常发生这样的事。
微服务被认为先进，单体架构便显得落后；代码越抽象越像高手，直接实现则容易被说成不优雅；页面追求极简，复杂信息就像设计能力不足。
然而，真实项目不按审美标签运行。
一个只有五个人、业务尚未跑通的团队，使用单体架构也许更稳。为了处理线上事故写下的临时代码并不漂亮，却可能在当时保护了大量用户。企业后台信息密集，未必是设计失败，也可能是业务本身就需要比较、筛选和批量操作。
工作中的很多选择不是善恶题，而是场景题。脱离团队规模、业务阶段和维护成本讨论“好”，标准就很容易变成偏见。
“最佳实践”为什么会变成迷信
最佳实践当然有价值。它通常来自前人踩过的坑，能帮后来者少交学费。
问题出在“最佳”两个字。它容易让人忘记，任何实践都有成立的前提。
假设一个小团队准备拆微服务。理由听起来很充分：独立部署、故障隔离、便于扩展。真正实施后，他们却多出了服务发现、链路追踪、接口兼容、数据一致性和部署运维等问题。原来在一个进程里就能定位的 bug，现在需要跨几个服务追查。
微服务没有错。错误在于团队把别人的答案，直接当成了自己的答案。
中台、规则引擎、复杂状态管理也是如此。它们解决的都是真问题，但如果业务模型仍在频繁变化，过早固化反而会放大成本。
成熟的技术判断，不是问“这是不是最佳实践”，而是问：
它究竟在解决我们哪个问题？引入之后，又会把复杂度放到哪里？
这个问题不够漂亮，却更接近工程。
很多“简单”，只是复杂度换了位置
老子说：“有无相生，难易相成。”
难和易并不是固定属性。用户操作越简单，系统内部可能越复杂；配置越灵活，维护和测试的成本往往越高。
例如扫码登录，用户只需要拿出手机扫一下。这个动作背后却包含二维码生成、状态轮询、过期处理、账号绑定、设备信任和安全风控。前台的“易”，来自后台承担了“难”。
需求评审里常听到一句话：
不就是加一个字段吗？
页面上确实只是多一个输入框，但字段进入系统后，还可能牵动数据库迁移、历史数据兼容、接口、权限、搜索、导入导出和报表。提出需求的人看见了一个点，负责实现的人面对的是一串关系。
这并不意味着研发应该用复杂度拒绝需求，也不意味着产品必须掌握所有技术细节。更好的协作，是一起确认复杂度应该由谁承担。
如果复杂度必须存在，通常应该尽量留在系统内部，而不是转嫁给用户；如果某种灵活性只服务极少数场景，就要判断它是否值得长期维护。
“有无相生”也提醒产品经理，产品的价值不只来自做了什么。
一个配置入口上线后，运营可能每天都要调参；一个导出按钮出现后，用户可能绕开在线协作，重新回到 Excel；一个跳过流程的后门，很可能演变成所有特殊需求的默认解法。
每增加一个功能，系统也增加了一块解释和维护的表面积。因此，“暂时不做”有时不是偷懒，而是在保护产品主线。
一个字段，如何长成一套系统
有个团队曾经接到一个看起来很小的需求：在注册页增加“邀请码”。
产品最初的设想很简单。用户填写朋友的邀请码，注册后双方得到奖励。页面只增加一个输入框，接口多接收一个参数，研发评估似乎也不该太久。
真正开始设计后，问题一个接一个地出现。
邀请码由谁生成，是否永久有效？用户注册时没填，以后能不能补绑？同一个设备批量注册怎么办？邀请关系建立后，奖励是立即发放，还是等新用户完成某个动作？活动结束后，历史关系如何处理？如果奖励涉及现金或优惠券，财务又该如何对账？
没有人故意把需求变复杂。复杂度本来就藏在“邀请”这件事里，只是最初那个输入框没有把它表现出来。
会议开到这里，团队出现了两种声音。研发认为需求远比描述复杂，应该一次把模型设计完整；业务则担心错过活动窗口，希望先快速上线。
如果用“对”与“错”来判断，争论很难结束。研发看到的是未来维护风险，业务看到的是当前机会，它们都是真实的一部分。
最后团队没有直接建设一套通用邀请平台，也没有只加一个不受约束的字段。他们把第一期范围收在一个具体活动里：邀请码由系统生成，只允许注册时绑定，奖励在完成首单后发放，并为异常设备增加基础限制。更通用的能力，等真实使用数据出现后再决定。
这个方案不算最优雅，也不代表未来不需要重构。但它把当前价值、实现成本和未来风险放在了同一张桌子上。
所谓场景感，就是接受一个方案可能同时包含好与不好。重要的不是把它包装成“最佳”，而是清楚知道这次选择保护了什么，又暂时放弃了什么。
好的管理，不需要在每个地方证明存在
“是以圣人处无为之事，行不言之教。”
无为不是躺平，而是不为了显得有用而过度干预。
有些管理者参加每次评审，都要修改几处方案；听完汇报，总要重新调整优先级。久而久之，成员不再围绕问题做判断，而是开始猜测管理者喜欢什么。
管理者越忙，团队反而越不会自己运转。
真正有效的管理，往往没有那么热闹。目标是否清楚，决策边界是否稳定，风险说出来后有没有人处理，这些事情比多开一次会更重要。
“行不言之教”也是如此。团队文化不写在墙上，而是写在一次次真实选择里。
如果嘴上说重视质量，排期却总把测试时间压掉，成员自然知道质量只是口号。管理者说允许试错，但失败后第一件事是追责，团队很快就会只选择安全方案。
相反，当认真写文档确实减少了沟通成本，当 code review 是在帮助对方而不是展示资历，好行为会自然被学习。系统会替管理者说话。
不要让“能力强”变成系统风险
“生而不有，为而不恃。”
很多团队都有一个特别可靠的人。核心模块只有他敢改，线上故障最后都找他，历史背景也主要存在他脑子里。
短期看，这是能力强。长期看，这是单点故障。
如果一个人请假，项目就停；一个人离职，团队就失忆，那么被拥有的不只是知识，还有整个系统的安全感。
成熟的技术负责人会主动削弱这种依赖。他把排障经验写下来，让新人进入真实项目，用监控和自动化代替个人记忆。这样做似乎降低了自己的稀缺性，却把个人能力变成了团队能力。
真正高级的不可替代，不是“没有我就不行”，而是“我让这里不再需要英雄”。
功劳当然要被看见，但不必被占住
“功成而弗居。夫唯弗居，是以不去。”
职场不是修行场，做出的贡献需要被表达，合理的回报也应该争取。老子并不是让人隐去自己。
他提醒的是另一件事：如果一个人太急着占住功劳，影响力反而会变窄。
一个复杂项目很少由某个人独立完成。产品找到了问题，研发承担了复杂实现，测试守住了边界，运营和客服又让方案接触到真实用户。负责人如果把所有成功都归到自己身上，团队会记住他的成绩，也会记住他的自我中心。
能把功劳分出去的人，通常更容易得到长期信任。因为大家知道，他关心的不只是证明自己，而是让事情真正成立。
这就是“夫唯弗居，是以不去”。不必牢牢占有，价值反而留下来了。
看场景，不等于没有底线
谈到这里，很容易走向另一个极端：既然好坏都和场景有关，是不是所有方案都可以被现实理由辩护？
当然不是。
为了赶时间写下临时代码可以理解，但要记录风险，并为后续清理留下入口；小团队暂时使用单体架构很合理，却不能因此放弃模块边界；产品为了验证需求做一个简化版本，也不代表可以忽略用户安全和数据正确性。
场景感不是替糟糕决定找借口，而是让标准拥有优先级。
有些底线不能交换，例如数据安全、基本正确性和对用户的诚实。有些标准则需要结合阶段取舍，例如抽象程度、架构形态和功能完整度。
成熟不是拒绝判断，而是能说明这次为什么这样判断，以及什么条件变化后需要重新判断。
写在最后
第二章并没有给出一套新的标准。
它只是提醒我们，在说“这是好代码”“这是先进架构”“这是优秀员工”之前，先把场景和代价放回判断里。
标准是工具，不是真理。最佳实践是经验，不是命令。简单与复杂也不会凭空消失，它们只会在用户、系统和团队之间转移。
真正成熟的技术人，不是背下更多正确答案，而是逐渐知道答案在什么条件下成立。
事情做成以后，也不必让系统永远依赖自己的判断、知识和功劳。能让复杂度得到安放，让团队自然运转，让其他人也长出能力，这大概就是第二章所说的“不争”与“无为”。
