昨天，是 5.4，是我的最后一个青年节。今天，我已经是一个中年人了。
最近的最近，在与同事对于过去架构的反思和总结中，我们讨论出了一个新的架构模式：应用微化架构。由于它是一个反向的微应用化架构模式，所以从模式上来说，我们便将名字反向了一下。由于这一种架构模式，实施和设计相当的简单。所以，在进行详细的介绍之前，先了解一下我们遇到的问题。
技术调研，是一个程序员的基础能力。快速进行技术调研，是一个高级程序员的基础能力。又快又好的技术调研，是一个咨询师的核心竞争力——你永远得比客户快半步。
技术影响力这个东西，每个人都有自己的想法，有的人觉得是个好事，有的人觉得会浪费时间；每个人都有自己的目的，有的想赚一些业余的钱，有想提供一些 KPI，这些都无可厚非。
规模化的组织，经常要面临这样的挑战：每个应用的基础设施是相同的，部分的代码也是相同的，甚至于它们可能只是数据模型不同而已。结果却导致了，他/她们要一次又一次地重新编写一个应用。
但是，在 9012 年的今天，前端应用走向了 MV* 的架构方案，也有了一层很重的 View 层——类似于过去的后端应用，或者后端应用。相似的架构，也可以在前端项目中使用。
Copy-Paste 是一件非常有效的开发方式，但是它们一点儿也不适合维护——为了改一个拼写错误，要去修改代码中的七八个文件，打人的心都有了。
基于 Web 与混合应用框架的架构，设计一个实时聊天工具，并不是一件轻松的工作。
自我开始练习画插画以来，经常会有人寻问相关的事宜，诸如使用什么工具，选择什么软件，以及有什么相关的模仿对象等等的问题。既然大家都觉得它相当的有价值，那么也就有必要写一篇文章来介绍相关的内容了。
无论是向新人介绍项目，又或者是上到一个新的项目，我们都需要事无巨细地列出一个个的关注点。既然如此，那么为什么创建一个检查清单，用来帮助我们一个个的检查一遍呢。