随笔

有人提问：如何能够像你一样，成为一位大牛，或者说提升自己的技术水平？ 多隆如下回复： 在我看来的话，没有所谓的大神、大牛，真的都是从做项目开始。我刚开始的时候其实什么都不懂的，比如2000年进阿里的时

有人说，编程里，用拼音命名不好的，我的回答是： 举个例子。我们系统要对接明道云这个低代码平台。那你告诉我，明道云应该翻译成什么英文？ 如果你去硬翻，最后只会得到一个谁都看不懂的英文单词。过几个月，你自

如果是让当前的我来排的话，是两个，一个是稳定性，另外一个是清晰度。 其中代码稳定性是排第一的，知道为啥吗？ 这些年，见过太多太多人因为IT故障而不得不走，也见过太多太多因为故障，整体IT部门的绩效被打

大多数业务，并不值得为了那一点性能，引入本地缓存带来的复杂度。 我自己的原则一直都是： 这其实也是一个软件设计原则：减少依赖，降低管理复杂度。 之前我还专门写过一篇内容： 好的架构，不一定是增加组件，

翻了一下我司某个微服务工程的代码，发现布尔变量的命名挺五花八门的。同一个文件里，有叫flag的，有叫success的，有叫normal的，有叫result的，还有叫warning和ignore的。各种

如果你经常看我写的关于程序员的内容，会发现我一直在说一个事情，就是程序员写代码时，要注意非功能性问题。这些问题产品prd里是不会写的。比如: 数据库压力突然变大了怎么办? 流量突然变大了怎么办? 第三

经验丰富其厉害的程序员，还有一项本事，就是知道哪些东西暂时可以不用，以便降低系统的复杂度。 很多项目发展一段时间后，总喜欢不断往里面加组件。比如： 觉得 MySQL 慢，就上 Redis。 觉得要异步

很多人面试快结束时，都会听到一句话： 不少人会回答： 其实，这几分钟挺重要的。刚工作那几年，我也喜欢问一些比较常见的问题，比如团队多少人、加班多不多、晋升机制怎么样。 但是现在的我，这个年纪了，如果去

偶然看到了一个篇文章《我为什么离开 Youtube》，作者是 Zhachory Volker，文章主要讲的是一个在 YouTube 工作多年的人，为什么决定离开，以及他对大厂职业晋升体系的一次反思。

上面是用Scala语言实现的，也即是单例模式，在Scala就是一个特性而已，毕竟单例模式原本想表达的意思是： 但是在java里想实现这个，就得好几行代码了，如下： 这个跟java这门语言的设计有关，当

刚工作那几年，我也特别关注各种编码规范。 比如驼峰命名、方法不要太长、少写 if else、多写注释，这些我现在也一直在做。 不过，写了十几年代码以后，我发现真正影响代码质量的，并不是这些，而是一些思

早期我开始在公司技术部落地DDD时，我在订单主表写了一个Repository，然后又给订单明细表写了一个Repository。我当时是认为明细表有自己的增删改查需求，单独一个Repository用起来

做DDD的项目，迟早都会遇到一个问题：聚合根放不下的逻辑，到底往哪放？ 有人说领域服务是可选的，聚合根本身就能承载大部分业务逻辑，领域服务只是补充。 看起来是对的，其实错的离谱。但凡真正做过复杂业务的

做排行榜，大多数时候一个ZSet就够了，ZADD更新分数，ZREVRANGE查排行榜，看起来不复杂。 但真正发版上线后，你会发现排行榜并没有一开始想的那么简单。随着用户越来越多、业务越来越复杂，同分排

十几亿数据做全量迁移，中间不可能一路跑到结束。 迁移过程中总会遇到各种问题：迁移程序有Bug要修、或者需要重启又或者数据库压力太大要暂停等，都有可能。 如果每次出了问题都从第一条重新开始，这个迁移基本

我们之前做的C端商品服务，要缓存的数据量很大，全部放到Caffeine这种堆内缓存里并不合适。 因为缓存对象都在JVM堆里，GC时需要扫描这些对象。缓存越大，GC压力越大，停顿时间也会越来越长。 所以

我们之前做的商品中心属于基础服务，几乎所有业务都会调用它。 首页要商品名称和主图，商品详情页要完整信息，下单要价格和库存，搜索又只关心类目和标签。 如果给每个业务单独提供接口，接口数量会越来越多，维护

而另外一些候选人，我反而不会这么问。因为他的简历里，项目实战那一块已经写得非常清楚了。我只需要沿着他的介绍，继续追问细节即可。 我这种类型的面试官，算是比较好的了。当候选人的项目写得不清楚时，我还是会

这个问题，可以从User user = new User();里的new开始理解。 我们每天都在写类似上面的代码，但估计没多少人去想：JVM到底做了什么，这个对象才真正诞生？ new只是我们写出来的「

我是觉得，与其天天研究各种 Vibe Coding 的奇技淫巧，不如先把**规格驱动开发（Spec Driven Development）**掌握好。 它足以解决你日常绝大多数编程问题。 为什么我一直