最近，在为 Coco 优化分层架构之时，我陷入了各种决策困难之中。所以我通过不断地延迟决策，以摸清更适合现有系统的现状。换个简单来说，在危险边缘徘徊，以期待能获取最大的收益。
在结合了《大规模 C++ 程序设计》中引入的物理设计的概念，以及《系统重构与迁移指南》一书中引入的『四级重构』，重新论证了我先前的一个想法：并不需要成为 xx 语言的熟练开发者，我也能分析这个语言的系统设计得是否合理？
内源即将开源方法（最佳实践、协作方式、架构模式等）融入到组织的软件构建和发布方式之中，以在组织内构建类似开源的文化。
过去的十几天里，在 Inherd 开源小分队的努力之下，我们实现了 Coco 的第一个完整的功能 —— 实现对于一个项目的基本架构可视化。（PS：Coco 是一个研发效能分析工具，如团队发展现状（根据架构复杂度及行数变更）、团队演进、历史分析等。）
整体来看，从大的趋势上没有太大的变化。这里并不考虑某些特定的技术，而是从总体上（战略）层面来看待问题。所以，就有了这么几个点：
写一个取代自己的工具，是怎样一种体验？
结合最近非常火热的无代码/低代码开发，又或者是各类的代码生成，以及我和同事正在设计的 Datum 语言（原 Charj），顿时间我领悟到了一种新的、未来的、下一代的架构模式。
2020 年，庚子年，注定是不平凡的一年，所以就平凡的过去了。年初，疫情让我在家办公了几个月，年中开始了忙碌的几个月，年底又归于平凡。也因为疫情，多了一些 beach 的时间，不得不休完 20 天的看似，还有没机会用上的婚假，所以我有机会尝试一些新的想法。
最近，我在探索中发现公司内的各种 Growth Paths（成长路径）已经成熟了，比如我试着重新对比一下其中各类的模型，Technical Anchor。那么，我的下一个阶段是不是应该与 PRINCIPAL ENGINEER 相挂钩？
几个月前，因为项目的需要，我大量地阅读了 Android Studio 和 Intellij Community 的源码，以及它们配套地大量上下游的代码。然而，这并不是一个简单的工作，因为你接触到的大部分东西都没有文档。而且在复杂的系统里，没有人能知道所有功能背后的场景。