半年前，公司出了一个计划，目的大抵是培养下一任 Tech Lead。作为一个勉强算是资深的 Tech Lead，我大概是能承担这样一个工作的，所以我成了 coache 中的一员。
不过，既然花了挺多的时间，做了这么样的一件事，那么我还是得写一篇文章总结一下。
最近我工作的主要内容，是在和别人结对编程，以对一个大型的遗留系统项目进行重构。
过程中，我发现一个特别有意思的东西，我重构了很多的 if 语句。从这些 if 语句里，大抵是映射出了业务的变化。于是，我便想写一篇文章来记录一下相关的心得。
依赖分析之后，你的架构还好吗？
这些日子里，由于项目的缘故，我又双叕开始学着造轮子了。故事的开始是代码的不规范堆砌，导致软件大楼摇摇欲坠；故事的终点是，重新唤醒程序员对匠艺的追求。而故事的中间部分，则是我们所要关注的内容：代码坏味道（code smell）、包依赖合理性，应对的方案则是代码重构，目标则是 Clean Code，即易于阅读的代码。而它们（代码坏味道、重构方式等）都已经被归纳为模式。
过去的一两周里，被公司的大佬安利了 Go，用来写一个代码、架构分析和自动化重构的工具。经过这么一周对于 Go 语言的实战，我算是有底气来写一篇文章来介绍（吐槽）一下 Go 语言。
最近在思考于如何更好的设计系统架构，以及如何对系统的架构进行守护。对于这个问题来说，我想到的第一步是：分解大泥球。
上一周，我参加了一个为期一周的 Event Storming 的工作坊，便想写一篇文章梳理一下对于 DDD 的理解。
你是不是经常烦恼于放错层级的代码？你是不是经常在为一坨坨代码而奋斗？你是不是经常这样？
或许是软件正在吞噬世界，或许是软件不断被重写，越来越多的架构师、资深程序员开始关注起软件质量。
你可能不需要微前端，但是需要一个胶水框架。