故障复盘很容易开起来，很难做得有用。会开了，文档写了，四条改进项记下来了，六个月后同一个故障又发生一次，而某个人正好在找别的东西时翻出了那份旧文档。 在讨论这件事时，注意力几乎都落在"无指责"这个词上。这条原则确实重要，但失效的地方并不在那里。有大量组织把无指责执行得一丝不苟，复盘却什么也没有改变，原因很简单：他们把复盘本身当成了交付物，而不是当成产出交付物的手段。 判断你们的复盘是否有效，有一个简单到让人难堪的测试：过去六个月记录下来的改进项，实际完成的比例是多少？ 如果答案是"大部分"，那么无论流程长什么样，它都在起作用。如果低于一半，你们是在开会而不是在运行一个流程，换更漂亮的模板也救不了。少数几条带负责人和期限的事项，胜过一...
代码质量
关于代码质量的文章、指南和教程，为开发者和企业提供实用知识与技巧。面向开发者与技术团队。
技术文档的失败方式非常具体，也非常好预测。有人在两周清闲的时间里写下一大堆，接着系统变了，没有人回头更新，一年之内那份文档就开始信心十足地讲着错误的内容。到了那个时候，它比什么都没有还要糟，因为相信它的读者会依据早已不成立的信息去动手。 常见的反应是号召大家多写一些，而这只会让同样的失败来得更快。有用的反应是少写，并且认真挑选写什么，因为真正的瓶颈不是写作的工夫，而是维护的工夫。文档从写完那一刻起，就开始被现实甩在后面。 判断一份文档该不该存在，唯一经得起时间的检验是： 当它变错的时候，会不会有人察觉？部署指南天天有人用，错误立刻就会浮出来。一份二十页的子系统说明只会被读一次，它的错误要等到十八个月后，有人照着它动手时才浮出来。没有...
开发者入职通常是按入职培训花了几天来衡量的，而那是问题的另一头。真正重要的数字是另一个：一个新来的工程师要过多久，才能改动某个东西，并且有把握自己没有弄坏别的地方。在大多数团队里，这个数字是以月计的，而不是以天计的。 延迟很少出在人身上。它出在系统里有多少部分只存在于别人的脑子里，以及前两周里有多大一部分时间，是靠一次次打断别人，一点一点把这些东西挖出来的。 唯一值得追踪的指标：从入职到他们的第一次改动进入生产环境，需要多久。 不是第一次提交，提交可以只是改一个错别字，而是一次有意义并且真正上线的改动。如果这个时间超过一周，障碍几乎从来都不是能力。而是一份最近没有人从零走过一遍的环境搭建流程，或者一份没有人带路就找不到入口的代码库。...
关于 API 版本管理的争论，几乎总是从错误的一端开始：版本号该放在哪里。其实这是整个话题里后果最轻的一个决定。真正要紧的是，究竟哪些变更才需要一个新版本，而大多数团队恰恰在这里判断失误，而且是往掉以轻心的方向失误。他们发布了自认为纯属新增的东西，然后某个客户端就坏了。 有用的思维模型是：你的 API 是一份承诺，规定了调用方可以依赖什么。如果一次变更让一个讲道理的调用方原本依赖的东西失效了，那它就是破坏性的。而调用方依赖的东西，远远多于你的文档明确允许他们依赖的范围。 让所有人都栽跟头的那种变更： 往响应里加一个字段。它只是新增，按理说不可能弄坏一个写得规范的客户端，可它偏偏经常弄坏真实的客户端，因为其中有些客户端会严格校验响应，...
技术尽职调查不是一场代码质量比赛，而为它做准备的团队，往往把时间花在了完全不重要的地方。没有哪个买家是为了给你的抽象层打分才来收购公司的。买方想弄清楚的只有两件事：持有这套系统要花多少钱，以及在钱易手之后，事情可能糟糕到什么程度。 这个视角的转换很重要，因为它会改变你应该优先修哪里。丑陋但能跑、团队看得懂、可以安全修改的代码，只是一条轻微的发现。相反，写得优雅却只有一个人看得懂的代码，是一条严重的发现，而真正会让价格发生变化的，恰恰是后者。 所有问题背后的那个问题： 如果创始工程师在交割后的第二周离职，这套系统还能继续运行、并且继续被修改吗？几乎每一条压低报价的发现，都是对这个问题的具体回答。知识集中在一个人的脑子里、没有文档的部署...
数据库性能的排查工作，通常从有人提议换一台更大的实例开始，又通常以这样一个发现结束：每次加载页面时，有一条查询都在对 400 万行做顺序扫描。瓶颈从来不是硬件，瓶颈是执行计划。 这个模式重复得足够稳定，值得当作默认假设写下来。当应用很慢而数据库又很忙时，原因几乎总是少数几条具体的查询，而不是整体容量不足；把机器换大，只能把问题掩盖到表再次长大的那一刻为止。 动手改之前，先量。 凭猜测去优化一条查询，正是团队花掉整整一周添加索引、结果写入变慢而读取一点没快的原因。任何数据库都能告诉你哪些语句消耗的总时间最多。从那里开始，修掉排在最前面的那条，然后再量一次。这样反复两三轮，事故通常就结束了。 数据库性能始于找出那条查询总时间比最坏单次更...
人们谈论软件测试策略时，几乎总是从覆盖率讲起，而覆盖率恰恰是整个领域里信息量最低的一个数字。一个覆盖率达到九十的代码库，照样可能在最常被走到的路径上把缺陷送进生产环境，因为覆盖率衡量的是测试运行期间哪些代码行被执行过，而不是有没有针对这些行做出任何有意义的断言。 真正信任自己测试套件的团队，并不是覆盖率百分比最高的那一批。他们是这样一群人：当东西真的坏了，测试会红；其余时候，测试保持安静。这个性质比大多数人想象的更难用钱买到。 对任何一个测试都值得问的问题： 如果它失败了，我知道该怎么办吗？因为行为改变而失败的测试，会告诉你一些东西。因为某个实现细节挪了位置而失败的测试，只能告诉你有人做了重构。这样的失败积累到一定数量，团队就不再阅...
软件开发生命周期（通常缩写为SDLC）是团队将软件从一个想法推进到可运行、可维护产品所遵循的结构化流程。无论是开发软件还是委托开发，理解这一流程都至关重要，因为流程的质量在很大程度上决定了结果的质量、成本和及时性。本指南清晰阐释软件开发生命周期：每个阶段及其内容、敏捷与瀑布方法的区别、项目通常在哪里出问题，以及良好的流程如何控制成本和风险。 要点总结 软件开发生命周期是规划、构建、测试、部署和维护软件的结构化流程 经典阶段包括规划、需求、设计、实现、测试、部署和维护 敏捷和瀑布是通过这些阶段的两种方式：迭代式与顺序式 大多数软件失败可追溯到薄弱的早期阶段，尤其是理解不清晰的需求 良好的SDLC通过在问题还容易修复时及早发现，降低风险...
网络开发最佳实践是仅仅能运行的网站与性能出色、排名靠前、经久耐用的网站之间的差距所在。2026年，标准比以往任何时候都要高：用户期望即时加载速度，搜索引擎奖励速度和可访问性，而安全威胁则持续不断。好消息是，能产出优质网站的实践方法已经广为人知。本指南涵盖了当今真正重要的网络开发最佳实践，涉及性能、可访问性、安全性、SEO、代码质量和测试等领域，提供可以实际应用的实用指导，而非抽象原则。 概要 性能不容妥协：针对 Core Web Vitals 进行优化，因为速度同时影响排名和转化率 可访问性是基本要求，而非可选附加项，良好的可访问性能提升所有人的使用体验 从一开始就构建安全性，而不是在上线后补充 编写其他开发者（以及搜索引擎）能够理...
过去两年中，“技术债务"的搜索量增长超过35%，这在很大程度上是由英国工程团队推动的，他们继承了在截止日期压力下构建的遗留系统，如今苦于维护或扩展这些系统。这个术语在Jira积压和迭代回顾中被随意使用，但大多数开发人员从未见过精确的定义，更别说系统性的应对策略了。 本指南涵盖技术债务的真正含义、它的来源、如何衡量，以及在英国真实产品团队中有效的实践策略。它借鉴了Ward Cunningham的原始比喻和Martin Fowler的四象限模型，并将其与你在本次迭代中可以付诸实践的日常决策相结合。 摘要 技术债务是选择当下更快、更简单的解决方案而非更好方案所产生的隐性返工成本。与金融债务一样，它会随着时间的推移积累利息。 Fowler的...