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