编程教程

Salesforce 集成几乎从来不是败在协议上。认证是已经解决的问题，写入一条记录也是已经解决的问题。真正把项目拖垮的，是每天的请求配额和数据模型的形状，而这两件事通常要等到上线大约三周之后才被发现，那时夜间作业开始返回错误，却没有人说得清它在测试环境里为什么是好的。 这个模式一致到可以预测。开发者对着一个 Developer Edition 组织开发，一切通过，客户签字验收。随后这套代码遇上的，是一个已经住着营销连接器、数据仓库抽取作业和一个 2019 年就在跑的 Apex 触发器的生产组织，而那份看起来很宽裕的请求预算，其实是别人早已在花的一口共用的锅。 这篇文章把意外提前摊开来讲：你应该用哪个 API、配额是怎么算的、当你的...

大多数 WordPress 插件开发都沿着同一条弧线走。有人需要一个预约表单、一个内容抓取器,或者结算页上的一个额外字段,开发者写了出来,它能用,大家各自忙别的去了。两年后,这个站点被困在一个旧版本的 WordPress 上,因为没人有把握那个插件能挺过一次更新,而写它的人早就走了。 原因很少是核心跑得太快。WordPress 在破坏兼容这件事上非常保守,五年前写得像样的插件,今天不改一行仍然跑在 WordPress 7.1 上。插件会坏,坏在头一个星期定下的几个决定:功能被放进了主题,该挂钩子的地方直接改了核心文件,数据被塞进了手边最方便的结构,以及从来没有人拿候选发布版试过。 一个定制 WordPress 插件靠什么才能扛住核心...

故障复盘很容易开起来，很难做得有用。会开了，文档写了，四条改进项记下来了，六个月后同一个故障又发生一次，而某个人正好在找别的东西时翻出了那份旧文档。 在讨论这件事时，注意力几乎都落在"无指责"这个词上。这条原则确实重要，但失效的地方并不在那里。有大量组织把无指责执行得一丝不苟，复盘却什么也没有改变，原因很简单：他们把复盘本身当成了交付物，而不是当成产出交付物的手段。 判断你们的复盘是否有效，有一个简单到让人难堪的测试：过去六个月记录下来的改进项，实际完成的比例是多少？ 如果答案是"大部分"，那么无论流程长什么样，它都在起作用。如果低于一半，你们是在开会而不是在运行一个流程，换更漂亮的模板也救不了。少数几条带负责人和期限的事项，胜过一...

技术文档的失败方式非常具体，也非常好预测。有人在两周清闲的时间里写下一大堆，接着系统变了，没有人回头更新，一年之内那份文档就开始信心十足地讲着错误的内容。到了那个时候，它比什么都没有还要糟，因为相信它的读者会依据早已不成立的信息去动手。 常见的反应是号召大家多写一些，而这只会让同样的失败来得更快。有用的反应是少写，并且认真挑选写什么，因为真正的瓶颈不是写作的工夫，而是维护的工夫。文档从写完那一刻起，就开始被现实甩在后面。 判断一份文档该不该存在，唯一经得起时间的检验是： 当它变错的时候，会不会有人察觉？部署指南天天有人用，错误立刻就会浮出来。一份二十页的子系统说明只会被读一次，它的错误要等到十八个月后，有人照着它动手时才浮出来。没有...

开发者入职通常是按入职培训花了几天来衡量的，而那是问题的另一头。真正重要的数字是另一个：一个新来的工程师要过多久，才能改动某个东西，并且有把握自己没有弄坏别的地方。在大多数团队里，这个数字是以月计的，而不是以天计的。 延迟很少出在人身上。它出在系统里有多少部分只存在于别人的脑子里，以及前两周里有多大一部分时间，是靠一次次打断别人，一点一点把这些东西挖出来的。 唯一值得追踪的指标：从入职到他们的第一次改动进入生产环境，需要多久。 不是第一次提交，提交可以只是改一个错别字，而是一次有意义并且真正上线的改动。如果这个时间超过一周，障碍几乎从来都不是能力。而是一份最近没有人从零走过一遍的环境搭建流程，或者一份没有人带路就找不到入口的代码库。...

软件源代码托管，也就是把源代码交给中立的第三方保管（英文称为 software escrow），回应的是一种完全合理的担忧：为你构建并运维关键系统的供应商倒闭了，而你手上留下的，是一个自己离不开、却又维护不了的东西。托管协议把源代码存放在第三方那里，一旦真的发生这种情况，第三方就把它交付给你。 这种担忧是站得住脚的。问题在于这项工具经常被误解，而两者之间的落差催生出一类协议：每年都在花钱，真到需要它的那一天却帮不上忙。 签字之前应该先问的那个不舒服的问题： 如果明天就把代码交到你手上，你这边真的有人跑得起来吗？一份没有构建说明、没有基础设施定义、没有它所调用的第三方服务凭据、也没有数据的源代码托管，不是业务连续性方案。那只是一个文件...

在固定价格合同和按工时计费之间做选择，通常被描述成一次关于风险的选择。这个说法本身没错，但紧接着就被处理错了，因为双方都默认风险会消失，而不是只从一方转到另一方身上。 风险不会消失。在固定价格的安排里，供应商承担估算出错的风险，并把这份风险提前算进报出的数字里。在按工时计费的安排里，承担风险的是客户。真正的问题从来不是哪一种方式能消除不确定性，而是哪一方更有条件去管理它，以及为转移风险付出的代价值不值得。 能预判哪种方式管用的检验： 你能不能把“完成”写下来，写到两个人对是否已经达到这个状态能给出一致判断的细致程度？如果能，固定价格是你可以用的选项，而且多半是合理的。如果写不出来，固定价格合同并不会消除模糊，它只是把将来每一次分歧从...

关于 API 版本管理的争论，几乎总是从错误的一端开始：版本号该放在哪里。其实这是整个话题里后果最轻的一个决定。真正要紧的是，究竟哪些变更才需要一个新版本，而大多数团队恰恰在这里判断失误，而且是往掉以轻心的方向失误。他们发布了自认为纯属新增的东西，然后某个客户端就坏了。 有用的思维模型是：你的 API 是一份承诺，规定了调用方可以依赖什么。如果一次变更让一个讲道理的调用方原本依赖的东西失效了，那它就是破坏性的。而调用方依赖的东西，远远多于你的文档明确允许他们依赖的范围。 让所有人都栽跟头的那种变更： 往响应里加一个字段。它只是新增，按理说不可能弄坏一个写得规范的客户端，可它偏偏经常弄坏真实的客户端，因为其中有些客户端会严格校验响应，...

软件 RFP，也就是需求建议书，本来的作用是让不同的供应商变得可以互相比较。可现实中大多数文件恰好起了反作用：它们把解决方案写得足够细，细到把答案的空间捆死，却偏偏漏掉了任何人报价时都需要的那些信息。结果就是五份报价，彼此相差一个数量级，形式上每一份都回应了要求，但没有任何两份在测量同一件事。 常见的解释是供应商在打太极。偶尔确实如此。但更常见的情况是，文件要了一个从它自身内容里根本推不出来的数字，于是每家供应商都用各自不同的假设去填补空白。假设不同，价格自然不同，这里并不存在诚不诚实的问题。 判断你的 RFP 是否有效的检验方法： 两家不同的供应商读完之后，能不能得出实质上相同的范围？如果文件里只写了“用户管理”，没有说明有多少种...

软件维护成本，就是那个把一个成功项目在十八个月之后变成一场难堪谈话的数字。开发阶段有预算、有审批、也如期交付了。可上线之后会发生什么，被一句「支持服务」轻轻带过，然后配上一个有人凭感觉给出的金额，而那个金额几乎每一次都太小。 原因出在结构上，不是谁不上心。开发有一个可以定价的范围。维护没有范围，因为决定它的是还没有发生的事情：某个依赖库爆出漏洞，某个供应商改掉了自己的接口，某个用户碰上了当初谁都没想到的情形。 人人都在引用的经验法则是每年按开发成本的 15 到 20 个百分点计算，而它之所以危险，恰恰是因为它离正确答案不远。 它对的次数多到让人放心，错的时候又总是朝同一个方向错：它低估了缺陷集中冒出来的第一年，而在有合规义务或者外部...