编程教程

技术尽职调查不是一场代码质量比赛，而为它做准备的团队，往往把时间花在了完全不重要的地方。没有哪个买家是为了给你的抽象层打分才来收购公司的。买方想弄清楚的只有两件事：持有这套系统要花多少钱，以及在钱易手之后，事情可能糟糕到什么程度。 这个视角的转换很重要，因为它会改变你应该优先修哪里。丑陋但能跑、团队看得懂、可以安全修改的代码，只是一条轻微的发现。相反，写得优雅却只有一个人看得懂的代码，是一条严重的发现，而真正会让价格发生变化的，恰恰是后者。 所有问题背后的那个问题： 如果创始工程师在交割后的第二周离职，这套系统还能继续运行、并且继续被修改吗？几乎每一条压低报价的发现，都是对这个问题的具体回答。知识集中在一个人的脑子里、没有文档的部署...

数据库性能的排查工作，通常从有人提议换一台更大的实例开始，又通常以这样一个发现结束：每次加载页面时，有一条查询都在对 400 万行做顺序扫描。瓶颈从来不是硬件，瓶颈是执行计划。 这个模式重复得足够稳定，值得当作默认假设写下来。当应用很慢而数据库又很忙时，原因几乎总是少数几条具体的查询，而不是整体容量不足；把机器换大，只能把问题掩盖到表再次长大的那一刻为止。 动手改之前，先量。 凭猜测去优化一条查询，正是团队花掉整整一周添加索引、结果写入变慢而读取一点没快的原因。任何数据库都能告诉你哪些语句消耗的总时间最多。从那里开始，修掉排在最前面的那条，然后再量一次。这样反复两三轮，事故通常就结束了。 数据库性能始于找出那条查询总时间比最坏单次更...

人们谈论软件测试策略时，几乎总是从覆盖率讲起，而覆盖率恰恰是整个领域里信息量最低的一个数字。一个覆盖率达到九十的代码库，照样可能在最常被走到的路径上把缺陷送进生产环境，因为覆盖率衡量的是测试运行期间哪些代码行被执行过，而不是有没有针对这些行做出任何有意义的断言。 真正信任自己测试套件的团队，并不是覆盖率百分比最高的那一批。他们是这样一群人：当东西真的坏了，测试会红；其余时候，测试保持安静。这个性质比大多数人想象的更难用钱买到。 对任何一个测试都值得问的问题： 如果它失败了，我知道该怎么办吗？因为行为改变而失败的测试，会告诉你一些东西。因为某个实现细节挪了位置而失败的测试，只能告诉你有人做了重构。这样的失败积累到一定数量，团队就不再阅...

金融科技软件开发在报价和排期上，和普通软件开发没有任何区别，直到有人问出那句话：到底谁有资格持有这笔钱。从那一刻起，项目就不再是一道工程题，而变成一道带着工程成分的监管题，你脑中原本的时间表也不再成立。 技术很少是难点。搬运资金是一个已经解决的问题，市场上有成熟的服务商、有文档齐全的接口，还有第一天就能用起来的测试环境。真正拖长金融科技项目的，是牌照上的身份、面向审计要拿得出的留痕义务，以及好几个架构决定其实早已由持牌方替你做完了。 决定你时间表的问题： 你自己持牌，还是以代理身份挂在别人的牌照下运营，抑或完全避开受监管业务？这三个答案会产生长度完全不同的项目，而差距是用等待的月数衡量的，不是用开发的周数衡量的。在做任何范围规划之...

MVP 软件开发出问题的地方是范围会议，不是开发过程本身。有人说出「最小可行产品」这几个字，大家点头认可，接着送来的功能清单里却写着用户账号、后台管理面板、计费、通知、仪表板，还有一个移动应用。那不是最小可行产品。那是一个完整的产品，而它花掉的时间会是你心里那个数字的三倍。 真正造成损害的词是「可行」。多数团队把它读成「好到可以卖给所有人」，可它的本意是「刚好够用来判断到底有没有人想要这个东西」。 最省钱的范围测试： 对每一项功能，问问自己会因为答案不同而做出什么不一样的事。如果一项功能改变不了任何决定，它就不属于 MVP。后台管理面板不会告诉你人们是否想要这个产品；它只会告诉你，等人们想要之后，这个产品会更好管理。把它放到第二步再...

凡是按端点数量来估算定制 API 开发成本的人，几乎都会算错，而且通常差三倍。端点本身是整件事里最便宜的部分：十来个端点，只是读写你手里已经有的数据，对一位称职的后端开发者来说不过是两周的活。 真正花钱的，是把这些端点变成另一家公司愿意把生意押上去的东西所需要的一切：经得起安全评审的认证、让你日后还能改主意的版本管理、好到没人需要给你发邮件的文档，以及能告诉你哪个客户今天早上过得不顺的运维装置。有一个 API，和有一个别人依赖着做生意的 API，两者之间的那道落差，才是预算真正的去处。 价格区间速览: 只被你自己的应用调用的内部 API，通常花费 10,000 到 30,000 英镑。由少数几家指定集成方使用的合作伙伴 API，一般...

采购 COBOL 现代化服务，和买任何别的软件工作都不一样。要动的那套系统已经跑了三四十年，公司里现在没有一个人完全弄得懂它，而做砸了的代价不是错过几个迭代，是监管报送出问题。与此同时，摆在你桌上的几份方案承诺的结果一模一样，报价却差出好几倍。 这篇文章讲清楚一份认真的合作到底包含什么，几类供应商之间的差别在哪里，以及哪些问题能把建立在证据上的报价和建立在乐观上的报价分开。它假设你就是事后要为这个决定作出解释的那个人。 该看什么： 一份可信的 COBOL 现代化方案包含现状勘察、目标架构设计、数据迁移、代码转换或重新托管、以比对为核心的测试计划、并行运行、切换方案以及知识转移。只给代码转换标了价的报价，不是一份项目计划，它只是其中最...

决定聘请一位 C++ 开发者，通常是带着一个具体问题来的。某个东西必须够快，或者必须跑在硬件上，或者必须对接一个只提供原生接口的库。随后展开的招聘流程，往往把 C++ 当成一项单一技能，而这个假设正是大多数失望结果的源头。 C++ 不是一个职位。一位出色的游戏引擎程序员，在嵌入式固件上可能真的做不出东西；一位低延迟交易专家，可能这辈子没交付过一个图形界面应用。三个人都是优秀的 C++ 开发者，但只有一个适合你的项目。 一句话版本： 在发布职位之前，先确定五个 C++ 专长方向里你真正需要哪一个，因为技能的迁移远比职位名称暗示的要少。英国的合约日价按领域大致在每天 400 到 900 英镑之间，而考察时最有用的信号，是候选人依靠工具、...

第三方 API 集成是商业软件里被低估得最稳定的一类工作。文档读起来清清楚楚，供应商提供了客户端库，于是有人说两周。六周之后，团队还在争论：当一个 webhook 为一笔已经退款的订单第二次送达时，究竟应该发生什么。 这道差距不是能力问题。真正的原因在于，一次集成里有意思的部分从来不是请求和响应，而是当对方系统做出它的文档从未描述过的行为时，随之而来的一切。它一定会这么做，因为它是一个活着的产品，属于一群有自己路线图、对你的发布计划不承担任何义务的人。 经验法则： 只从一个服务拉取数据的只读集成，通常需要一到三周。会写入事务的集成需要三到六周。两个都允许编辑的系统之间的双向同步需要六到十二周，而且永远不会真正结束，因为冲突解决是一个...

需要招聘 Qt 开发者的公司，通常在做一件必须跑在机器上而不是浏览器里的东西：一块仪表盘、一个诊断工具、一个为别人都不愿支持的硬件写的控制程序。候选人的池子只有网页市场的一小部分，词汇体系不同，平常那些招聘捷径在这里也不管用。一个只按“C++”筛选的猎头，会给你送来一批从没写过一行 QML 的人。 本文讲清一个称职的 Qt 工程师究竟掌握什么、这个岗位在 2026 年要花多少钱、如何检验真正重要的能力，以及在写下任何代码之前就该定下来的许可问题。最后这一点，正是昂贵错误最容易发生的地方。 开始之前： Qt 人才稀缺且高度专业化，所以要预期高于一般 C++ 的价位，也要预期更长的招人周期。请先把许可立场定下来，因为在开源版本与商业版本...