架构一直在你身边----致励志成为架构师的人.

曾经有面试官问我:”你真的喜欢编程么?”,面对这问题,我百感交集,却不知何以言表.

答案不言而喻,我是个梦想成为架构师的人.

严谨的行事风格和习惯,我知道我无法证明,于是我久久沉默不语…

当自己成为面试官,也希望知道初次蒙面的人是不是一个喜欢编程的人.

我并未提出”你喜欢编程么?”这样的问题,

相反,我会问我自己:什么样的人才是喜欢编程的人?

你我都是打工的程序员,其实是去实现产品人员的想法,是一个执行者.

即便你可以跟策划讨论产品实现,最终还是要去敲代码,将想法变为可见.

之后,你拿到需求文档,看到了需求中的逻辑,却看不到该需求的架构.

于是,你可以按照逻辑编程,也可以思索如何设计,让代码更加优雅.

这就是程序员的两类人,至于那种只会动嘴不会动手(注意,说的是不会动手;而不是简单的不动手)的,根本算不上程序员.

没人愿意承认自己是第一种程序员,但如果你真的是第二种,那我愿意相信你热爱编程,并且架构一直在你身边.

举个例子,举个王者荣耀中的例子.

牛头冲锋将亚瑟击飞.

那编程中如何表示亚瑟的状态?

于是,我们用了一个变量fly = 1表示亚瑟处于空中.

亚瑟被击飞后,又落到了地上,程序又该如何表示?

于是,我们用了一个变量onFloor = 1表示亚瑟在地面上,并将fly设置为0.

一切按照逻辑,可以实现,有什么问题?

对计算机的计算来说,都可以.但对人来说,变量太多,不利于扩展和维护.

于是,你会说,为什么不用一个变量代表状态.0表示在地上,1表示在空中,2表示被击退等?

对的,这就是架构,有些人会认为这跟架构扯不上关系,这就算是基础.

我同意这种观点,但我更倾向于认为这是架构思维的萌芽.

就是这种思考的习惯,让人知道,互斥的状态可以用枚举搞定,

有相同属性不同动作的类可以做成多态,可以使用工厂模式等.

你一直有一个思考的习惯.

渐渐的,你的项目需要有多少类?同一时刻该类的实例对象有多少?

分别在哪几个线程?哪几个进程?你均知晓.

渐渐的,渐渐的你写出了优雅的代码,做了一些别的程序员用得到的东西,同行不排斥看(很多情况是不愿意看).

渐渐的,有人愿意跟你分享技术观点,愿意跟你维护同一套代码.

渐渐的,你设计了对整个产品的架构,分了若干个服务,每个服务放在了哪台物理机的哪个进程中…

…

…

于是,你可以骄傲的回答开篇提的那个问题:我是一个热爱编程的人!

写在最后,珍惜每次编程的机会,将代码写的优雅,更优雅,再优雅.

架构,一直在你身边.