获得徽章 7
- 值此元宵佳节，个人开源的 json-repair 库迎来了 0.3.0 版本的发布，增加对文本内容中 JSON 字符串的提取功能，同时支持对提取 JSON 的修复。
随着 DeepSeek 将 LLM 的使用成本打下来，25 年必然会迎来更多应用层的尝试。如果你所在团队尝试用 Java 、 Kotlin 等 JVM 语言构建 Agents 或 RAG 系统，不妨来试试这款 Java 库吧。展开评论点赞 - AI 辅助写作甚至是委托 AI 写作是必然不可阻挡的趋势，在掘金上找了两篇阅读量尚可的文章，基本上判断有一半的部分是 AI 创作（参见前两张图）。后两张图是个人近期发表的文章。赞过
评论1 - 2025 年，还有 Java 后端同学想要通过开源项目刷履历的吗？可以看看哦，文章中提到的待解决的 issue 至少还有 40 个，跟着文章操作，便可以成为顶级项目的贡献者哦
![[惊喜]](//lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_93.5ee641b.png)
等人赞过 45 - 祝各位 JYM 元旦快乐
![[庆祝]](//lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_123.da47506.png)
看来 Java 开发的系统在 AIGC 时代确实落后了呀，一方面在与大语言模型集成时没有现成的 JSON 异常修复库，另一方面相关文章也没什么水花。
个人觉得可能与 LLMs 集成的应用多以 JS、Python 等新建应用居多，而 Java 应用存量 “老” 系统居多。另一方面可能现在多数厂商对于 LLMs 的集成还普遍停留在 chatbox 的形式，不太需要 function call。
各位 JYM 在工作中开始集成 LLMs 了吗？都是怎样集成的呢？展开赞过 评论1 - 推荐这本 20 年出版 “Unit Testing: Principles, Practices, and Patterns”。这本书里会讲得比较“务虚”，但可能恰恰可以解决单元测试实施的部分问题，作者开始便强调没有必要为所有代码编写单元测试，那么如果确定需要为哪些代码编写单元测试呢？作者提出了关于好的单元测试四要素的定义，在其中作者给出了他的答案。
1. Protection against regressions
其中关于 regression 作者给出的解释为 “一个功能在一些代码改造后不再按预期工作”
关于如何评判单元测试是否满足这点，可以从3个方面考虑：
a: The amount of code that is executed during the test：概括来就是如果一个方法/函数涉及很多代码行数非常多，那么有必要为其编写单元测试，因为 “code is not an asset, it's a liability” （代码不是资产，而是负债），因为随着代码量的增长，相应的系统问题也会越多。
b: The complexity of that code：如果代码的复杂度较高，那么也需要为其编写单元测试。
c: The code's domain significance：单元测试所覆盖的代码要具有具体的业务语意。
2. Resistance to refactoring
好的单元测试应当满足，当其覆盖的应用程序代码完成重构后不会测试失败。对应的令人沮丧的是，当我们完成代码重构后，满足所有功能测试与验收，唯一无法通过此前编写的单元测试......
3. Fast feedback
测试一定要是能够快速执行的，似乎没什么好特殊说明的。
4. Maintainability
单元测试也需要考虑维护成本，好的单元测试代码也一定是易于理解的，容易修改的，请把单元测试同样作为一等公民。展开赞过 评论1 - 强烈推荐这本21年出版的“Learning Domain-Driven Design : Aligning Software Architecture and Business Strategy”。
如果你是领域驱动设计的初学者，只看一本书的话推荐看这本。如果你对领域驱动设计有所学习，并且也在实践中尝试过，但依然对其有诸多疑问，那么也推荐用这本书重学一遍。如果你认为自身对领域驱动足够了解，但在实践领域驱动设计时依然有很多 trade off 的内容说不清，那么推荐这本书重学一遍。
这本书好在哪里？就两点：说的清楚明白的同时删繁就简。清楚明白对比的是Eric Evens 自己的书。删繁就简对比的是“领域驱动设计模式、原理与实践”。
基本上把 DDD 的东西5、6个章节就全讲完了，而且让人醍醐灌顶，很多似是而非的概念，三言两语说不清的内容，落地就需要 trade off 的内容，基本在这5、6章都说清了。当然我不确定我是否是因为量变到质变。但如果我在6、7年前就看到这本书的话，可能都不需要这么多量来换质。对，这本书就是这么好，你看完之后就不用在浪费时间在其他DDD内容上了，实操去吧，你已经会了！
后续章节融合了很多 DDD 提出之后架构与模式的演进与 DDD 的结合，可以说非常与时俱进了。
最后中文版貌似叫：领域驱动设计学习手册。如果你看中文版，我建议可以先查查 domain、context 的英英词典，不要轻易地理解为：领域和上下文，会有一定帮助。后知后觉，这两个词用的很精准，但普遍的翻译是缺失了背后的含义的。展开等人赞过 15
![[拳头]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_122.b3763ee.png)
juejin.cn![[惊喜]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_93.5ee641b.png)
![[庆祝]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_123.da47506.png)
![[抱拳]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_120.6c3effe.png)