这一章讲工程——程序员的工作、架构师的工作、研发里的陷阱、怎么避坑。
程序员的日常,在大多数团队里是这样的——接需求、写代码、提测、修 bug、上线。这套循环熟练了之后,大部分程序员把它当成"工作的全部"。
但有一件事,程序员普遍忽视——降低代码的维护成本。
我用一个简单的公式来想——
一段代码上线那一刻,它产生的"价值"是 V0,付出的"成本"是 C0。但代码不是写完就完——它要被维护、要被改、要被新人接手、要被升级、要被重构。这些都是 Cn——未来维护成本。
一段代码的真正成本,不是 C0,而是 C0 + Cn。而 Cn 在很多项目里,远远大于 C0——一段花两天写出来的代码,接下来五年里被改、被读、被调试,可能消耗团队 200 天的时间。
降低 Cn,是程序员的修养和美德。
具体怎么降?三件事——
注释:让下一个人(可能是三个月后的你自己)看到这段代码,在一分钟内知道它在干嘛、为什么这么写、有什么坑。注释不是写文档,是写"思路"——你当时为什么选了这个方案,而不是另一个。
文档:对一个模块、一个服务、一个 API,有一个清晰的文档——让新人不需要追着你问,就能上手。这件事在中国工程师文化里被严重低估——大家觉得"代码就是文档"——不,代码不是文档,代码是机器看的,文档是人看的。
设计:这一点最深。一段代码的"维护成本",绝大部分不是来自写得糙,而是来自设计错。结构搭得乱、抽象选得错、边界划得歪——这些东西一旦定下来,后面所有的人都要在错的结构里打补丁,补丁越打越多,代码越来越烂。
学习难度低是衡量工程师水平的一个重要指标。一个新人接手你的代码,他多久能跑通第一个 demo、多久能改第一个小 bug、多久能独立完成一个小需求——这个时间越短,你这段代码的设计水平越高。
我那时候 review 代码,最看重的就是"新人友好度"。不是看你算法多漂亮,是看你这段代码三个月后能不能让一个陌生人快速接手。能,这是好代码;不能,这是债——技术债。技术债跟金融债一样,越拖利息越高,有一天会把团队压垮。
架构师是研发里最容易"务虚"的一个角色。
我见过两类架构师:一类沉迷于画图——他画的架构图很好看,很全,但落地的时候团队各种崩。另一类沉迷于"先进技术"——他追新框架、新模式、新协议,把团队带到一些超前但用不上的技术栈里。
这两类架构师都在浪费团队的时间。
架构师的真正工作是什么?还是用 V0 + Vn 和 C0 + Cn 的公式来想——
Value 0 = 当前价值,Value n = 未来长期价值 Cost 0 = 当下成本,Cost n = 未来长期维护变更成本
但架构师视角里的 Value 和 Cost,比程序员视角更宽:
注意——这里的 Cost 不只是"机器成本"和"人力成本"。架构错了带来的最大成本,是**"团队整体的注意力被吸走"和"机会成本"**——一个错的架构会让团队三年内反复修补，错过其他真正该做的事。
那架构师的核心工作就清楚了——
简化架构复杂度,将 C0 + Cn 降到最小。
架构师核心工作就是在平衡"性能、可靠性、可扩展"这三件事中,简化系统复杂度。
注意,是"平衡 + 简化",不是"追求极致"。
很多架构师的本能是追求极致——追求极致的性能、极致的可靠性、极致的可扩展性。这种本能在工程上是有害的。极致是有代价的——你为了极致的可扩展性,会让架构变得很重;为了极致的性能,会引入复杂的优化;为了极致的可靠性,会增加大量冗余。这些"极致"加在一起,系统就变成了一个谁也维护不了的怪物。
好的架构师追求"足够"——足够的性能、足够的可靠性、足够的可扩展性,然后把节省下来的复杂度,投资到团队真正稀缺的地方。
我那时候评估一个架构师,核心问的不是"你的架构能支持多大并发",是"你的架构上手要多久"、"出问题平均多久能排查"、"加一个新需求要改几个地方"。这三件事是架构真正的"使用成本",一旦失控,架构本身的"性能优势"就毫无意义。
讲一件让所有产品经理都警醒的事——每 1 份需求波动,会带来总共拥有成本 13 倍的增加。
13 倍。
这个数字不是我编的,是工程上的经验数据——一份需求在不同阶段变更带来的成本差异是指数级的。需求阶段改一份,成本是 1;设计阶段改一份,成本是 1.3;开发阶段改,1.69;测试阶段改,2.19;预发阶段改,2.86;上线后改,3.71;运维阶段改,4.82;架构层面改,接近 13——而这还只是直接成本,没算因为需求波动带来的延迟交付和质量缺陷。
这个数字告诉我们一件事——需求的波动是研发成本最大的吞噬者。
很多产品经理觉得"我改一下需求很简单"——他在 PRD 文档里改一行字,十秒钟。但这一行字传导下去,可能是设计稿改三页、代码改五个模块、测试用例改十几个、文档改一遍、培训材料改一遍。
我那时候有一条铁律——需求一旦冻结,要改就改下一版。
这条规矩很硬,经常被业务方反对——"这个改起来很简单啊,为什么不能本期改?"——我都拒绝。因为只要这一次开了口子,下一次就更难拒绝。需求的冻结纪律,是迭代节奏的命脉。一旦松了,迭代就名存实亡。
当然,这条铁律有例外——重大错误、严重 bug、合规问题——这些不冻结。但除此之外,所有"我觉得这样更好"的需求变更,统统下一版。
研发里最大的陷阱,一个字——浪费。
浪费分四种,我反复跟团队讲——
无效需求。做出来用户不用、不爱用、用一次就走的功能。这是浪费的源头。一个团队产出的功能里,如果有 40% 是无效的,那等于这个团队花了 40% 的钱在做用户不要的东西。这个比例在大多数团队里超过 50%。控制无效需求,是产品经理的第一责任。
过度设计。一个简单的需求,做成一个复杂的方案——表面看是"考虑得周到",实际是"想得太多"。过度设计的特征:用了一堆现在用不上、以后也大概率用不上的抽象。这种代码"未来可扩展性"看上去很强,实际是负担。
无效沟通。三个人能聊明白的事,开十个人的会;一个文档能说清的事,反复开会确认;一封邮件能解决的事,等三天才回。沟通的浪费,是中等规模团队最大的隐形成本。
质量缺陷。bug、回归错误、性能问题——这些不只是"用户体验"的问题,它们是研发成本的吞噬器。一个 bug 修复的成本,通常是预防的 10 倍以上。
这四种浪费,加在一起,很多团队真正在产出价值的工作可能只占 20%——剩下的 80%在做这四种浪费。
减少浪费,核心两件事——精简的需求 + 精简的团队。
精简的需求:就是上面讲过的——拆细、聚焦、砍掉非核心、需求冻结。这件事是产品经理的责任,但研发负责人有义务跟产品经理一起把关。研发不是"被动接收需求",研发是产品决策的另一极。
精简的团队:这一件事很多公司不愿意承认——人越多,效率越低。一个 5 个人的团队,产出可以是 10 个人团队的 1.5 倍——因为沟通成本是 N² 的,5 个人的沟通节点是 10,10 个人是 45,翻了 4.5 倍。
我那时候有一个原则——任何一个团队,超过 7 个人就开始失控。再超过 12 个人,就必须拆分成两个团队。这个数字是从我反复试错里得出来的。不是说大团队不能做事,是说大团队的"边际产出"会断崖式下降——多招的那个人,可能不仅没贡献,还反向减低别人的效率。
亚马逊有句话——"Two pizza team"——一个团队的规模,不应该超过两块披萨能喂饱的人数。这句话有道理。
很多团队的"风控"是这三件事——
这三件事都是好东西,但它们不是真正的风控。
真正的风控只有一件事——反馈。尽早的客户反馈。
为什么?因为产品开发的最大风险,不是"做得不够好",是"做错了方向"。完美的产品设计可以让你执行一个错的方向执行得很完美;顶级的技术专家可以让你在一个错的方向上跑得飞快;清晰的业务战略可以让你笃定地朝错误前进。
只有用户反馈,能告诉你方向对不对。
所以风控的核心动作就一个——让真实用户的反馈尽可能早地进入决策循环。
具体怎么做?
先做一个最小可用版本(MVP),哪怕它很丑、很简陋。重要的不是这个版本多完整,是它能不能让用户在它上面"做出真实选择"——下载、注册、付款、推荐——这些真实选择,才是有效反馈。
找愿意先用的"早期用户",不一定多,5 个人就行——但他们要真的用、真的反馈、真的会再回来。这 5 个人的反馈,比 200 份问卷有用。
建立持续反馈通道:每一次发版,都要有数据看板、有用户访谈、有客服日志的汇总。不要"一年看一次反馈",要"每一拍看一次反馈"。
我那时候有一个习惯——每一次产品 review 会,前 15 分钟先看用户反馈。看完用户反馈,再讨论下一步。如果一上来就讨论"我们做什么",就脱离了用户。
这个习惯保下来,你的每一次决策,都有真实的依据。这是研发风险控制最有用的一件事——比任何"风控流程"都强。
工程这一章讲完。
总结一下我对工程的几条核心信念——
这五条不是工程理论,是我反复在不同团队验证过的实战法则。