最近逐渐开始写一些简单且稍微务虚的文章。原因有挺多，其一是，自己的工作内容和企业的内部情况绑定的更加深入了，许多信息如果要在互联网上分享，需要考虑在很多地方做加工；其二是，过分拘泥于非常深度的技术挖掘，可能只能涉及到一些特定的领域，不利于技术博客的持续运营，并且从读者的视角，形式简单但内容富有思考的干货，才是真正有价值的产出。
因此，今天这篇文章，就从笔者自己的角度，谈一下代码架构治理的四层境界，把读者自己最深层的思考内容给解剖出来。希望这篇文章能够帮助到一些在代码架构治理工作方面，感受到痛点的同行们，让大家可以通过文章提到的一些思维工具，去解决实际工作中代码架构治理方面的问题。
这四层境界分别是：
第一次在技术博客里面写生活日记，也算是破了个小天荒。个人以为，博客是个人生活思考的载体，而技术只占生活的一部分，那么博客里为什么一定要限制只能够写技术内容，不能写点其它生活上的东西呢？思来想去，近几年在深圳万象天地和她一起探过不少餐馆，吃过不少东西。于是乎，决定写一篇万象天地餐馆探店点评，给没来过或者想来深圳万象天地的人一些参考，少点踩坑。
本文评价纯粹综合她和自己的主观意见，胃口分布于北京、江南跟广东，稍偏咸口。有些店可能很长时间没去了，所以只能基于主观印象给分。满分5星，4星以上推荐在线下做多刷。详细评分内容如下:
今天灵光一闪，决定调研一下自己的技术博客，可以怎样方便迁移到其它社媒平台。想要达到的效果是，把自己在掘金的专栏：从1到∞精通Python，迁移到知乎上面去。
简单花了两三小时时间，找到一个比较快捷的方法，就是结合python爬虫、clean-mark工具和zhihu-on-vscode插件，实现从掘金到知乎的文章搬运。
正直劳动节，翻了下2023年美团的技术年货，挑选了一些和变更风险防控和稳定性建设相关主题的文章做了下浅读。本文仅简单记一下阅读笔记。
总共选读了3篇文章，分别是《基于AI+数据驱动的慢查询索引推荐》、《代码变更风险可视化系统建设与实践》，以及《AIOps在美团的探索与实践——事件管理篇》。
在基于Golang的后端开发中，channel是一个必须要掌握的并发编程概念。和python的queue一样，channel在不同的goroutine里承担着传递信息的作用，使得业务逻辑的状态上下文可以在不同的goroutine中共享。今天，我们就来看一下channel的用法还有一些使用上的基本原则。
首先，我们需要知道什么场景下会用到channel。一个简单的例子是，在主流程里，我们希望启动一个方便处理panic的goroutine，异步跑一个任务，然后主流程等待这个goroutine给join进来。解决这个问题，就可以用到channel，代码这样写：
在变更风险防控领域，对于线上变更元信息的分析是非常重要的一部分，这是因为，只有理解了变更元信息，结合自主定制的变更规范，才能够知道具体的变更风险在哪里。不同的变更风险防御能力，实现的思路可能是不同的，因此很有可能出现对于一次变更，在信息的理解上有所不一致，从而导致检测结果不够置信。基于此，我们需要一个独立的变更元信息分析框架，把所有的变更元信息分析过程和结果都归到一个独立的系统当中。这样，从变更风险防御能力的视角，变更分析的结果都是共享的、全局的、一致的，从而能最大限度提升变更风险防御能力可挖掘的潜力。
本文，就简单聊一下，变更元信息分析框架设计的部分重点。
在服务或者其它线上资源发布新版本的时候，我们都有必要为发布信息本身和上线的资源做风险检查，以确认发布内容不会对线上造成影响。通常来说，在检查能力铺垫时，一个主旨的思路是保证问题的召回率，即检查能力本身必须理论上可以拦截更多的风险，这样才能够基本限度保证发布过程的安全。但随着检查能力集合变得成熟，业务也肯定会有对检查能力优化的需求，需要提升检查的准确率，不至于出现太多无用的噪音，这也成为了风险检查提升可靠性的一项挑战。
因此，本文就浅谈一下，提升发布风险检查准确率的一些思路。
今天闲聊一下可持续性架构设计的秘诀，总共八个字：概念拆解，重组改造。
说到新开发一个技术工程，很多同学会引用需求拆解的思路，自顶向下拆解子需求，做对应的层次模块设计，然后直接按照拆解结果分模块编码。依照这样的思路，虽然最终架构形态比较符合预期，但不一定能够保障长线迭代。这是因为，技术实现始终是自底向上，而不是自顶向下的，如果说在拆解过程中，思考深度不够，没有触及到底层概念的粒度，那么技术实现的结果，必然是失去可扩展性——上层隐含的底层概念跟需求强绑定，导致底层功能无法拆分出来，不能适配更多场景，最终不断堆积，就产生了技术债。
这个问题需要如何解决？举一个游戏领域的例子。以客户端自动化测试为例，我们期望的一个效果，是要通过客户端自动化测试工具，可以代替人力做游戏场景遍历，解决遍历冒烟测试耗时的问题。为了解决这个问题，可以简单做子问题拆解：
技术风险，作为质量保障领域的重要的一环，主要研究如何通过解决方案和技术手段，解决企业内业务在基础运维、日常运营和变更上线过程中的稳定性问题，保证业务风险得到收敛。在国内，蚂蚁金服在这个方向上有沉淀很多方法论和实践经验。变更管控是技术风险地一个子领域，主要的目标是在变更过程中，通过对变更流程的管控介入，提前发现变更过程存在的事故风险，或者阻止变更过程的错误进一步扩大影响面。在这个子领域，蚂蚁开源了AlterShield变更管控平台，提供了一套变更风险防御的解决方案。今天，本文就浅析下AlterShield平台整体的设计，适用的场景以及局限性。
AlterShield的源码可以参考这个GitHub-Repo。整体的技术架构，主要包含几块部分：