老板说“快上线”，你说“会崩”，谁是对的？两个循环告诉你：资深程序员总爱说“加功能会变复杂”，但老板只听“快点试”。本文用两个生意循环解释矛盾：市场要快，系统要稳。高手不该阻止需求，而要反问“有更快的方法试吗？”这既能减少市场的不确定性，又保住系统稳定性，才是真本事。
作者背景
Tuhin Nair，软件架构师，前团队技术负责人，专治程序员与产品经理的“翻译病”
资深程序员其实是麻烦消灭机
我加入一个新团队时，总能遇到两种高级程序员。第一种人特别爱说这些：“我发现一个新工具，老厉害了”，“那个跟我们完全不像的公司是这样搞的，所以我们也该这样”，“你看这个技术论坛的帖子说了这是行业标准，我们得跟上”。说实话，我不太喜欢这种。他们有点自我保护，行业混得久，人也挺好，但跟我不是一个频道。
另一种人画风完全不一样。他们会问：“咱们真的需要那个吗？”“如果这事不干，会发生什么？”“能不能先凑合用，等真重要了再回来搞？”哎呦，这才是我的菜。他们是麻烦消灭机，能省就省，能复用就复用，能躲就躲。他们就是想尽可能少写代码。为啥？因为他们在追猎软件开发里的唯一大怪兽：复杂性。各种特殊判断、分支条件、新数据库表、新组件，全都是恶心的东西。高级程序员恨不得半点都不加，花大量时间确认是不是真的必须多写一行代码。因为往系统里加东西，就是往火堆里浇油，增加复杂性。
当然，这说得太简单了。确实有高级程序员特别擅长解决没人搞定过的问题，设计出聪明的新方案。但说到底，如果你要对一个正在跑的系统负责，你肯定怕复杂性。那么问题来了：复杂性到底坏在哪？为啥别人就不懂呢？
公司其他人只害怕不确定
咱们用两个圈圈来简化理解公司运作。这是第一个圈：市场、销售、产品经理、公司老板，全都活在这里。这个圈的核心目标是尝试和学习。公司想把东西推给市场，然后收集反馈，看自己搞出来的到底有没有价值。在这个圈里，大怪兽是不确定性。
不确定性很残忍，因为没有任何策略保证能成。加上时间压力（市场销售的工资、老板的现金、产品经理的数据），你会感觉在截止日期前唯一能减少不确定性的方法就是拼命把东西推出去。你能推给市场的东西越多，收回的反馈越多，减少不确定性的机会就越大。这个圈，所有公司都从这个圈起步，核心就是纯粹的速度。
但公司拿到客户之后，会发生什么？
高级程序员死磕稳定性
现在来看第二个圈。付了钱的客户们。这个圈里蹲着大量高级程序员。目标是服务的持续和保障。让系统一直能跑，让系统容易被理解，容易被调试，容易修，容易教给新人，总之就是保持稳定。高级程序员操心稳定性，因为他们要负责让公司持续服务好客户。
那什么会威胁这一切？复杂性。它让系统更难理解、更难调试、更难修、更难教，最终变得更不稳定。复杂性升高 = 稳定性下降 = 高级程序员没尽到责任 = 糟糕糟糕很不妙，支付中断，所有人都不开心。
所以，第一个圈的目标是减少不确定性，第二个圈的目标是管理复杂性。但为啥这会搞砸沟通？因为一旦有了客户，两个圈会同时运转。公司既要探索新可能，又要服务好现有客户。
现在你可能看出这篇文章标题的答案了。你大部分时间待在哪个圈，你看问题的方式就完全不同。这就解释了为什么程序员对人工智能的看法也会分裂，有人更多待在前一个圈，有人更多待在后一个圈。
两个圈讲的是两个完全不同的故事
第一个圈里的人是这样看事情的：需求像雪片一样飞来，团队拼命上线，公司就能更快从市场里学到东西。这个圈的故事核心是：动作要快，反馈要快，赢在速度。
第二个圈里的高级程序员的故事完全不同：每一个新需求都是在给系统增加复杂性，像往一个精细的积木塔上不断放石头，随时可能压垮他负责的整个系统的稳定性。他脑子里全是维护成本、可理解性、长期开发速度、团队未来效率。
这两个故事根本不搭。高级程序员收到的需求越多，他越想说：“呃，不行，复杂性太高……维护成本太高……后面的人看不懂……以后改起来太慢……”但这些话对公司的其他人毫无帮助，因为他们正在拼命解决“不确定性”这个难题。
用文案界的说法：你不能拿你自己的问题，去解释掉别人的问题。正确做法是：你要把你的解决方案，描述成也能解决对方问题的方案。高级程序员沟通失败，就是因为他们总在讲述“管理复杂性”这个难题，可他们应该做的，是把他们的解决方案包装成“减少不确定性”的方案。
高级程序员的绝招是反问“能不能更快试一下”
承认公司的其他人真正想要的是减少不确定性之后，高级程序员就能用自己的本事帮忙了。那高级程序员最牛的技能是啥？是对“建不必要的东西”的强烈抗拒，是发现“复用已有东西”的机会的能力。
需要收集问卷数据？用网上的表单工具就行了啊。需要搞一个完整的新功能来做测试？你能不能先在现有界面上加个按钮，看看有没有人点？需要新的数据分析服务？你先说出我们要靠数据做的最重要的决定是啥，能不能先从一个决定、一张图表、一个指标开始？你想给我烤整个生日蛋糕？你就往我的三明治上插根蜡烛吧。
这就是高级程序员学到的本事：他们学会用现有的软件资源，想办法给人他们真正想要的东西。但你怎么把这个本事说出来，而不需要给人发几千字的说明呢？
文案界有个技巧，把复杂信号浓缩成一句话。
所以，这句每个高级程序员必须学的神奇咒语来了：“咱们能不能找个更快的方法试一下？”注意，“更快”两个字，直接承认了他们真正追求的是速度；“方法”暗示还有别的路子能达到目标；“试一下”允许不完美，但也保留“可能够用”的希望。
这句话精准切中公司其他人的需求：用速度减少不确定性。同时又让高级程序员施展自己的专长：减少、复用，如果运气好，直接避免。这就是我对标题的回答：当所有人都在担心不确定性时，高级程序员却满嘴复杂性。
不过！一个大大的不过！现在人工智能好像让这一切都变得没意义了，对吧？还减少什么？复用什么？避免什么？人工智能分分钟能写那么多代码。哎，但它还做不到高级程序员能做的唯一那件事：承担责任。
高级程序员更像是编辑而不是写手
高级程序员极度在意理解整个系统，因为只有理解了，出问题才能修。只有理解了，系统需要扩展时才能聪明地扩展。只有理解了，才能稳定可靠地持续服务付费客户。人工智能威胁这种可理解性。它极擅长提高推向市场的速度，但也影响了另一个圈，就是高级程序员负责的那个圈。
如果一堆人工智能助手、新手程序员、非技术人员，甚至你的投资人和他妈妈都往系统里加代码，你会得到一个为了速度而牺牲稳定性的系统，而且牺牲得很过分。忘掉保持稳定性吧，人工智能简直是个不稳定制造机。它让系统更难看懂、更难修、更难调试、更难教、更难保障，所有这些“难”字辈的东西。人工智能搞完这些，一丁点责任都不承担。这很不妙，而高级程序员的主要担忧就这么被无视了。
幸运的是，高级程序员兜里还有几招。其中最管用的一招：解耦。很久以来，软件开发人员是唯一能建系统的人。他们同时要对两个圈负责，一个系统支撑两个目标。那如果我们搞两个系统，一个对一个目标呢？
打个比方，小说作家会飞快地写完初稿，然后从中提取有用的部分，扔掉没用的。快速写完初稿之后有一个编辑过程。编辑的工作是挑出写得好的片段，把它们塑造成一个完整的作品。
如果我们搞一个系统专门追求速度呢？所有想快速把东西做出来的人都在这里面干活。人工智能、我们自己生成的未经审查的代码、新手程序员、市场人员等等。我们可以叫它“速度版”系统。它的目标不是可理解，而是“够好到能拿给市场看”。
然后再搞第二个系统专门追求稳定性。我们可以叫它“规模版”系统。它由高级程序员设计，要求稳定、可理解、可扩展。“速度版”让公司其他人能继续从市场学习，同时高级程序员在后面慢慢打磨一个经过审查、容易理解的系统。而且，“规模版”的设计会参考“速度版”里哪些东西管用、哪些不管用。
功能先在“速度版”里搭建，然后在“规模版”里稳定下来。实际怎么操作可能还不清晰，但核心思想是：明确说清楚这个解耦，告诉大家跑速度和跑稳定是两码事。想象一下，有人让你做个很猛的功能，你回答：“行，速度版我三天搞定。稳定版大概六周。”他们得到了他们想要的：速度和冲劲。你得到了你想要的：观察和设计。也许呢？
你怎么看，资深软件程序员？哦不，我应该叫你，资深软件编辑？