如我在先前的文章所说,我最近的工作主要是在做架构重构、代码重构。所以,一如既往地,我又写了个工具来帮助我完成相关的工作。这样一来,下次我可以更快速地完成相关的工作。
最近,经历了一系列代码吐槽事件之后,结合公司大佬的观点之后,大体上对于程序员的编码 level 有一个更好的认识。所以,我决定写一篇文章,以此来划分不同的程序员。我知道为别人打标签是不对的,政治上是不正确的,但是我不会明着对你说的。每个人在自己心里都有的一杆秤。
分层架构,不就是建文件夹的艺术吗?
半年前,公司出了一个计划,目的大抵是培养下一任 Tech Lead。作为一个勉强算是资深的 Tech Lead,我大概是能承担这样一个工作的,所以我成了 coache 中的一员。
不过,既然花了挺多的时间,做了这么样的一件事,那么我还是得写一篇文章总结一下。
最近我工作的主要内容,是在和别人结对编程,以对一个大型的遗留系统项目进行重构。
过程中,我发现一个特别有意思的东西,我重构了很多的 if 语句。从这些 if 语句里,大抵是映射出了业务的变化。于是,我便想写一篇文章来记录一下相关的心得。
依赖分析之后,你的架构还好吗?
这些日子里,由于项目的缘故,我又双叕开始学着造轮子了。故事的开始是代码的不规范堆砌,导致软件大楼摇摇欲坠;故事的终点是,重新唤醒程序员对匠艺的追求。而故事的中间部分,则是我们所要关注的内容:代码坏味道(code smell)、包依赖合理性,应对的方案则是代码重构,目标则是 Clean Code,即易于阅读的代码。而它们(代码坏味道、重构方式等)都已经被归纳为模式。
过去的一两周里,被公司的大佬安利了 Go,用来写一个代码、架构分析和自动化重构的工具。经过这么一周对于 Go 语言的实战,我算是有底气来写一篇文章来介绍(吐槽)一下 Go 语言。
最近在思考于如何更好的设计系统架构,以及如何对系统的架构进行守护。对于这个问题来说,我想到的第一步是:分解大泥球。
上一周,我参加了一个为期一周的 Event Storming 的工作坊,便想写一篇文章梳理一下对于 DDD 的理解。