随笔

说到敏捷开发，大家最容易想到的，往往是Scrum、站会、迭代和用户故事。 但这些东西其实都不是敏捷本身。 敏捷更像是一套做事的原则：尽早交付，快速反馈，根据实际情况调整。至于具体怎么做，可以用Scru

2022年，我参加过一次技术方案评审。负责方案的程序员正在介绍自己的设计，讲到一半，一个架构师突然插话：为什么不用消息中心的方式，干嘛在代码里直接调用第三方发消息的接口？ 当时我心里冒出的第一个判断是

衡量一段代码写得好不好，其中一个标准是：它写完以后，还需要你回来改多少次。 当然，只要业务需求不断变化，代码就不可能永远不动。我这里说的，是通过设计和编程手法，让代码尽可能稳定，让变化尽可能发生在代码

一个永远返回0的哈希函数，当然也能用。放进HashMap，数据照样能存，也能取。 但带来的问题是：所有键都会落到同一个桶里。查数据时，只能一个个往后找。原本应该很快的查询，最后退化成线性遍历。JDK

如果你想了解Kubernetes，我建议先搜索一个问题：为什么需要Kubernetes？ 别一上来就看它有哪些特性、有哪些组件。先把一个最基本的问题搞清楚：没有Kubernetes，项目能不能正常运行

团队做微服务，服务之间怎么通信，是个绕不开的问题。 REST+ JSON已经用了很多年，简单、成熟，调试也方便。gRPC也很流行，性能、类型安全、代码生成，这些优势确实很吸引人。 所以，很多团队都会遇

一个数据库扛不住了，升级硬件是其中一条路，但硬件总有上限。CPU、内存、磁盘IOPS都不可能无限往上加。机器越换越贵，性能提升却越来越有限。 这时候，就可以考虑把数据拆开，分散到多台机器上，这就是分片

上传文件这件事，应该没有哪个程序员没写过。 前端用创建一个FormData，把文件塞进去；后端接口接收一个文件参数，Content-Type写成multipart/form-data。 代码基本都是这

就一首好的，你心里就会觉得这张唱片是ok的。 这就是长板问题。 我用我自己的职场经历来说明一下，从08年开始到现在，差不多18年了，这漫长的18年里，有两段职场经历，是比较突出的。 三年多的大厂经历；

有一次，公司里一个技术很不错的人突然提出离职，大家都觉得很可惜。他刚升到一个不错的位置，收入也不错，手上的项目正在推进，按正常的职业轨迹，再往前走几年，应该还能继续升。 当时他给出的理由是：这不是我想

海明威曾说，作家可以省略他所知道的东西，只要写得足够真实，读者就能感受到那些未写出的部分。 换句话说：真正重要的东西，不一定要全部写出来。 一篇小说，读者看到的可能只有水面上的那一小部分，但作者真正花

Unix哲学：**程序别做得太复杂，一个程序做好一件事，还要方便和其他程序组合起来。**一个程序把结果输出出来，另一个程序接着拿这个结果继续处理。Unix里的管道 |，就是干这个的。 在《The Un

我这边的业务系统里，有一个业务场景：业务单据需要实时同步到第三方的低代码平台，各个合作方的客户在低代码平台上对这些单据做发货、审核等操作。如果某张单据同步失败了，客户在平台上看不到，就是大故障。 对接

我们当时的场景是，一张销售商品表(SPU维度)，一张商品SKU表，和一张活动表，我当时做了三表关联，全部都用到索引的，期初跑的很好，SQL都执行的很快，直到某一天，流量陡增后，连接池里的数据库连接突然

系统的可观测性，只是监控?其实不太准确，监控更像是在告诉你：系统出问题了。 比如CPU突然升高、错误率超过阈值、接口响应变慢，然后触发一个告警。 而可观测性真正想解决的是： 这也是为什么可观测性通常离

这篇作为整个SSO专栏的架构基线。后面几篇涉及的服务名、表名、接口路径、Redis Key以及JWT约定，都以本文为准。 下文认证中心均指专栏服务base-oauth2（与第01、02篇中的「认证中心

我还能胜任一线工程师的工作吗？ 还会有团队愿意雇我写代码吗？ 离开太久，手生了，我还能扛得住高强度交付吗？ 这是每一个技术管理者都会经历的、真实且合理的焦虑。而残酷的事实是：你的工程技能，确实会随着时

在深入阅读这篇十年总结之前，我想先与各位程序员同行分享文中那个最刺痛人心、也最令人释怀的核心观点： 作为程序员，我们很容易陷入一种技术自恋或者工程洁癖中。 我们追求100%的测试覆盖率、痴迷于优雅的A

很多程序员都有一个错觉，工作几年，就应该自然晋升到什么级别。 工作1-3年，初级； 工作3-5年，中级； 工作5年以上，高级。 但现实是有的人写了十年代码，依然只是一个执行者，有的人工作几年，就已经可

我建议用如下的一个过程： 第一阶段：先不要急着创新，先学习最佳实践 不要太早相信自己的判断，一般来说是有如下经历的程序员才敢这么做的： 参与过多个真实系统； 经历过很多个线上事故； 参与开发过很多个复