光の技术屋

上周某天下班前，接到同事转来一个bug要排查，症状是代码重构之后某些业务效果不符合预期，由于代码重构人是笔者，于是blame到笔者这边。经过10min左右的排查和尝试后，解决了这个问题：既往逻辑没有改动，重构时候出笔误了。

简单来讲，重构之前的代码大概是这个样子：

对于一个成熟的工程项目而言，因为项目未来发展或是和企业内部更深度融合的需要，我们可能需要对既有业务逻辑做很大规模的改动，涉及到多方面的逻辑迁移和代码重构，才能够达到下一代产品所需要的效果。

今天这篇文章，就来剖析一下如何做好这件事情，尤其是在历史积淀非常厚重的场景，需要通过怎么样的手段，把这个问题解决好。

最近逐渐开始写一些简单且稍微务虚的文章。原因有挺多，其一是，自己的工作内容和企业的内部情况绑定的更加深入了，许多信息如果要在互联网上分享，需要考虑在很多地方做加工；其二是，过分拘泥于非常深度的技术挖掘，可能只能涉及到一些特定的领域，不利于技术博客的持续运营，并且从读者的视角，形式简单但内容富有思考的干货，才是真正有价值的产出。

因此，今天这篇文章，就从笔者自己的角度，谈一下代码架构治理的四层境界，把读者自己最深层的思考内容给解剖出来。希望这篇文章能够帮助到一些在代码架构治理工作方面，感受到痛点的同行们，让大家可以通过文章提到的一些思维工具，去解决实际工作中代码架构治理方面的问题。

这四层境界分别是：

1. 套设计模式
2. 自上而下需求拆解
3. 自底向上模块抽象
4. 网状概念聚类分层

第一次在技术博客里面写生活日记，也算是破了个小天荒。个人以为，博客是个人生活思考的载体，而技术只占生活的一部分，那么博客里为什么一定要限制只能够写技术内容，不能写点其它生活上的东西呢？思来想去，近几年在深圳万象天地和她一起探过不少餐馆，吃过不少东西。于是乎，决定写一篇万象天地餐馆探店点评，给没来过或者想来深圳万象天地的人一些参考，少点踩坑。

本文评价纯粹综合她和自己的主观意见，胃口分布于北京、江南跟广东，稍偏咸口。有些店可能很长时间没去了，所以只能基于主观印象给分。满分5星，4星以上推荐在线下做多刷。详细评分内容如下:

今天灵光一闪，决定调研一下自己的技术博客，可以怎样方便迁移到其它社媒平台。想要达到的效果是，把自己在掘金的专栏：从1到∞精通Python，迁移到知乎上面去。

简单花了两三小时时间，找到一个比较快捷的方法，就是结合python爬虫、clean-mark工具和zhihu-on-vscode插件，实现从掘金到知乎的文章搬运。

正直劳动节，翻了下2023年美团的技术年货，挑选了一些和变更风险防控和稳定性建设相关主题的文章做了下浅读。本文仅简单记一下阅读笔记。

总共选读了3篇文章，分别是《基于AI+数据驱动的慢查询索引推荐》、《代码变更风险可视化系统建设与实践》，以及《AIOps在美团的探索与实践——事件管理篇》。

前言

《软件研发效能权威指南》一书，对于软件研发效能DevOps领域做什么事情，解决什么问题，给出了非常全面详尽的说明。这本书的精华，基本全部都浓缩在一张附属的海报上，海报讲述了每个章节的精简摘要，可以说是现成的读书笔记。

2024年，相对于古早的纸质载体，用电子作为载体的文献在维护上成本更为低廉，并且也逐渐成为了最优的文献阅读方案。因此，顺带借着AI的东风，笔者决定用AI技术，将这份海报转化成一份电子版的读书笔记，通过OCR识别+GPT润色+人工校对，把这本书所有的精华给摘录下来。

以下，便是读书笔记的正文。

在基于Golang的后端开发中，channel是一个必须要掌握的并发编程概念。和python的queue一样，channel在不同的goroutine里承担着传递信息的作用，使得业务逻辑的状态上下文可以在不同的goroutine中共享。今天，我们就来看一下channel的用法还有一些使用上的基本原则。

首先，我们需要知道什么场景下会用到channel。一个简单的例子是，在主流程里，我们希望启动一个方便处理panic的goroutine，异步跑一个任务，然后主流程等待这个goroutine给join进来。解决这个问题，就可以用到channel，代码这样写：

在变更风险防控领域，对于线上变更元信息的分析是非常重要的一部分，这是因为，只有理解了变更元信息，结合自主定制的变更规范，才能够知道具体的变更风险在哪里。不同的变更风险防御能力，实现的思路可能是不同的，因此很有可能出现对于一次变更，在信息的理解上有所不一致，从而导致检测结果不够置信。基于此，我们需要一个独立的变更元信息分析框架，把所有的变更元信息分析过程和结果都归到一个独立的系统当中。这样，从变更风险防御能力的视角，变更分析的结果都是共享的、全局的、一致的，从而能最大限度提升变更风险防御能力可挖掘的潜力。

本文，就简单聊一下，变更元信息分析框架设计的部分重点。

在服务或者其它线上资源发布新版本的时候，我们都有必要为发布信息本身和上线的资源做风险检查，以确认发布内容不会对线上造成影响。通常来说，在检查能力铺垫时，一个主旨的思路是保证问题的召回率，即检查能力本身必须理论上可以拦截更多的风险，这样才能够基本限度保证发布过程的安全。但随着检查能力集合变得成熟，业务也肯定会有对检查能力优化的需求，需要提升检查的准确率，不至于出现太多无用的噪音，这也成为了风险检查提升可靠性的一项挑战。

因此，本文就浅谈一下，提升发布风险检查准确率的一些思路。