随笔

年轻时，看《Thinking In Java》这本书时，总是会被里面简短的代码所吸引，代码虽然短，但是都能明确的引出一个问题，从而触发思考。思考后，问题就好理解了。 今天我们也一样，用一段简单的代码，

如果简单描述这个原因，那就是：现在的工作没有充分发挥他的能力，但是在公司内部，又找不到发挥的方式。 好像技术高手都挺相似的，我团队里的几个高手来我这边面试时，我问离职原因，也大概类似，比如： 上家公司

在技术方案评审会议里，有时候吵得最凶的，往往不是代码的对错，而是对「什么叫好」的认知不同。 我们常说的技术品味，其实它和技术能力完全是两回事。能力解决的是能不能做出来，而品味解决的是在这个具体的项目里

提到分离关注点，你的第一反应是不是会想到Spring AOP? 确实，日志、事务、权限校验，这些散布在各个方法里的逻辑，用AOP抽到切面里统一处理，确实是分离关注点的典型应用。但这只是SoC(Sepa

如果一个方法里的if嵌套超过了3层，这代码大概率现在或者将来藏着不好排查的bug。很多时候，并不是写代码的人逻辑本身弄错了，而是过深的嵌套结构把条件判断和它对应的处理结果错开了。错误就这样隐身在层层叠

关于代码清晰度的话题，我之前已经写过很多了。 那么今天，再从另外一个维度来讨论代码清晰度的问题。也即是：代码的排列顺序(相关性)对可读性的影响。 不说算法逻辑，也不说什么架构设计，也跟任何开发语言没有

给结算（checkout）接口写单元测试是一件很痛苦的事。核心算账逻辑可能就几十行，但Mock代码得写上百行，因为有购物车、SKU、会员信息、优惠券……依赖的Service和Mapper非常多。 之所

这个工作流呢，是根据我日常的实际踩过的坑后，总结出来，它可以尽量保证你写的代码的质量。 很多人都来跟我要这个工作流，但是我想说，这个工作流，我也是让AI写的，只要你有想法，AI可以帮你搞定的。 你真的

了解业务? 跟现有的开发团队了解情况? 这些要做，但是我的个人建议是，作为刚入职的架构师，应该是先去参与开发，从小模块做到中模块，再到大模块。 为什么? 因为：如果没有对系统具体细节的深入了解，你作为

有位网友问了这么一个问题，代码如下： 运行输出三行： 疑问是：实例初始化块明明写在静态块前面，按一般的理解，静态初始化应该先于实例初始化执行，为什么normal先输出了？ 这个问题问到了一个很容易被误

Java里每个对象都有构造方法。哪怕你不在类里写，编译器也会替你补一个无参的。可有一个例外：数组。数组是对象，这一点并没有什么疑问，你能对它调用Object里提供的方法，能把它当Object传来传去。

Spring Boot把内嵌Web服务器纳入了Spring的启动流程，但Spring Framework的源码一行都没改。关键就在于Spring预留的一个默认空实现。本文就从这个细节出发，看看开闭原则

Java里有一个很有意思的问题： 两个对象明明都是List，为什么一个能add，另一个却不让你add？ 代码能编译，但运行时直接抛出UnsupportedOperationException。 如果把

学习和理解单一职责，一个比较好的办法，是去看一个真正按这个原则设计的类。比如JDK 17里的java.time.LocalDate。 第一次接触LocalDate时，很容易会认为，既然它负责表示日期，

有开发者在使用RocketMQ的MessageListenerOrderly做顺序消费时，发现日志里同一个线程在同一毫秒内连续打印了多条消息： 消息编号75、79、83...99，递增顺序没问题，但同

我个人认为是可以的。 那种鼓吹通过进行精心的设计，写清晰度和可维护性强的代码，就可以少写注释的，是错误的观点，是站不住脚的。程序员一定要根据自己的实际工作体验，来评估各种国内外技术大神的观点，要质疑的

写了十几年代码，对代码这件事的看法变了不少。刚入行的时候觉得代码写得多就是产出高，一天提交几百行特有成就感。后来慢慢发现，代码越多，背上的包袱越重。一个项目到了后期，改一行代码要理解前后十几个模块的关

做过电商系统订货模块的，基本都遇到下单扣库存这个问题。 用户下单后，订单系统要先写自己的订单表，同时还要调用库存系统扣库存。问题是，这两个操作不在一个系统里，中间还隔着网络。订单写成功了，库存扣失败怎

我这边的业务系统，要对接的第三方系统非常的多，比如: 金蝶； 低代码平台； 北森； 合思； 君子签合同系统 钉钉； 等等。。。。 而一旦涉及到调用第三方系统，则必须处理一个事情：对方系统不稳定。 这个

面试里经常有人会问：数据库把数据拆到多台机器上，不就是分布式了吗？ 严格来说，分片确实是分布式系统的一种基础能力。但在工程选型的语境下，我们通常把只做了数据拆分和具备完整分布式协作能力区分开来。分片解