我这么看一个优秀架构的形成

题记:其实一直都对软件架构这个东西有点想法,但是迟迟没有想的太明白所以未敢写些东西,怕露怯了,惹了大家的笑话。近日,读了些书,从中有所得;也跟了几个项目,也有所得,有与人聊了些这方面的东西,并加以考虑,所以试着写下此文,汇报一些个人的想法。既是想写些想法,那么少聊术,而多谈道,姑且认为是我发的一些少年狂吧。

首先,有一点原则须之出来:

没有适合你的软件模型

软件工程领域有许许多多的模型,无论是架构,还是开发流程,但作为一个工程师,我们须有这样的原则。因为模型都是前人们在若干次实践中抽象出来,并加以优化的一种实验室状态,其来源就注定这个模型不可能适应一个实际项目。因此在实践过程中,当我们遇到了与模型冲突的情况,正确的做法是修改模型,调整一个适合当下项目的流程或架构出来,然后继续走下去。倘若,试图改变自己,让自己以一种非健康的姿态去遵循模型的规定,那么这次开发想必是已经开始走上歧途了。

在软件设计初期,选择一个相对靠谱的模型是必要的,在这个模型上加以变化,调整出一个适合具体项目的设计。进入下一步的开发工作,并试图遵循这个设计,当遇到一些特殊情况与设计不符,需要考虑是当初的设计不周全,没有考虑到当下的问题;还是开发过程中出现了不和谐的情况,有人试图通过某种方式绕过一些约定,从而以一种easy但dirty的方式去满足需求。而后再决定是设计重构还是修正工作方式。

上面提到了“设计重构”,那么我说第二个原则:

及时进行设计重构

在一个软件的开发周期中,总会遇到这样那样的问题是与当初的设计是冲突的,这也就是上面提到的不和谐。我认为,这些冲突至少有半数,甚至更多是设计不周全造成的。这并不是说,我们的架构师水平不高,或是我们对需求的掌握不准,云云。事实上这种冲突是必然发生的,试想如果一个架构设计可以从头到尾的正确,那么我们这个软件是什么呢?Hello, World! 吧。一个优秀的软件,必然有着强大的功能,而强大的功能是需要相对复杂的设计(相对复杂,这并不是说复杂度与功能正相关)支持的,复杂的设计就一定有许多隐形的陷阱存在,而工业上是决不会允许我们花上足够多的时间去找到所有陷阱的,因此设计不足必然存在。换句话说,找到陷阱的最好办法,就是踩下去。因此,永远不要害怕设计重构,敢于重构,让设计重构贯穿整个开发周期。

而且设计重构,需要这个软件的架构师,这个角色来推动。架构师是这个设计的作者,因此只有他最懂得这个设计该如何发展才不至于偏离方向。一个优秀的架构师要敢于推翻自己的设计,并拿出一个更优秀的。

好的架构师只是一个优秀架构产生的条件之一,在软件开发过程中,扮演更加重要角色的是:开发工程师。因此开发工程师的习惯也至关重要。原则三:

做一个有洁癖的工程师

作为一名开发工程师,我们需知道,代码不是为了需求而生的。代码产生,满足需求是他存在的意义,但注意,代码生存在这个架构中,他是为了充实这个架构而生。我们相信,在架构中,优雅的编码一定可以满足需求,否则参考之前的原则,我们需调整架构了。那么,作为工程师试图通过之前提到过的easy and dirty的方法去满足需求,只有一种可能:偷懒。这是一种不负责任的表现,作为一个工程师,就需要对从自己手中流出的没一行代码负责,做一个有洁癖的工程师,不要让自己的代码污染了整个设计。

每一个工程师,都小心的去维护这个架构,不试图污染他,那么这个架构必然会发展的更健康。

总结上面提到的三个原则,一个优秀的架构不是设计出来的,而是成长出来的,是在勇敢的架构师和负责人的工程师的呵护下成长出来的。

以上即使在下的一些拙见,或许经验丰富的大牛们会看出不少扯淡的地方,非常非常期待牛人们的指点。

标签:软件架构 架构师 工程师 软件工程

添加新评论