架构 vs. 编程

很多人对架构一直持有怀疑性,认为架构师是架构宇航员(不落地)如图:

博文Architecture versus Code对此提出了自己对架构实用性认识,本人非常赞同,转贴如下:

1.架构应该注重自身的可伸缩性和可维护性
软件最终是需要成长,其他程序员需要接管继续编程拓展维护,如果你架构是如此僵化令人费解,以至于软件就不能成长拓展,它可能需要被重新设计(BanQ语:推倒重来很符合中国国情,又多了一次采购机会)

2.方法论和设计模式不应该过于复杂
虽然学习曲线是可以接受的,如果需要过多的时间来学习插件和架构时,它可能不值得使用,尤其是对于较小的项目。

3.架构必须有助于解决现在的问题
如果你有一把锤子,所有的问题看起来像一个钉子,没有一种尺寸适合所有裤子,人们容易有一种倾向,将业务和基础技术架构进行分离,偏袒他们知道,或他们所认为的“可以接受”的做事方式。

4.架构应该推荐最佳实践模式,引导程序员进入结构化稳定开发方式。
在代码完成,史蒂夫麦康奈尔描述了良好的架构作用:

深思熟虑的架构提供需要保持一个系统的从底部到最高层的概念完整的结构。它提供指导程序员以各自水平入手的方便性。良好的架构使施工方便。坏的架构使开发几乎是不可能的。

Grady Booch总结了架构和良好代码之间的平衡(总结见原文),这首先来自于一个面向对象设计,因为没有硬性规定实战中应该采取哪些设计方案,所以必须在一个项目开始架构之初就确定出一个好的适合本项目的架构设计思想。



[该贴被banq于2009-11-18 15:34修改过]

易用性差的架构必然是不成熟的架构,最好的架构应该可以让人们忘记他的存在,让人身处其内而不知。如果存在这样的架构,那么一定会大行其道。

架构是要用设计图纸来解决问题的!不能只有抽象的文字说明和杂乱无章的代码实现。

可惜的是领导层关注的是利益,甚至有深远意义的市场都视而不见,所以他们关注所谓的“快速编程”!!!
没有质量的软件是毁坏市场的“有力”工具!
我们这些做事的就受这种没有技术基础的利益驱动,怎么来做出良好的架构呢?(这句是抱怨!)
针对软件,我觉得jdon的精神就很明确了,为了可扩展的高质量的软件而努力,这点使我在此受益匪浅!!
[该贴被taochenpfj于2009-11-21 09:41修改过]

关于领导插手的问题,建议看一下<<快速软件开发>>中对于这个问题的描述.好的架构就应该是为快速软件开发准备的,因为并不是架构一定要花更多的时间.另外,如果领导无理取闹,那就不是软件架构范围的事情了.

没有架构设计和监督的软件代码其实很恐怖,就像没有监理建筑设计的房子你敢住吗?很多人说:
“手上的代码以个action就有几千行,一个if else都有几百行,太恐怖了”

这是不对的 都是应付工作 没有人检查代码,以为代码写出来就可以付工资了,公司不注重代码质量的原因,不注重代码质量实际就是不注重架构,这种现象都发生在中国的很多世界5百强大企业中,可见架构和编码对比中,架构是多么忽视。

架构师不但负责项目前期的架构选型设计,也要负责代码检验,监督保证代码能够实现架构的可伸缩性和可维护性,千里之堤 毁于蚁穴,代码坏味道就是蚁穴。

8种代码臭味

2009年11月22日 16:50 "banq"的内容
没有架构设计和监督的软件代码其实很恐怖,就像没有监理建筑设计的房子你敢住吗?很多人说:
“手上的代码以个action就有几千行,一个if else都有几百行,太恐怖了”

这是不对的 都是应付工作 没有人检查代码,以为代码写出来就可以付工资了,公司不注重代码质量的原因,不注重代码质量实际就是不注重架构,这种现象都发生在中国的很多世界5百强大企业中,可见架构和编码对比中,架构是多么忽视。

架构师不但负责项目前期的架构选型设计,也要负责代码检验,监督保证代码能够实现架构的可伸缩性和可维护性,千里之堤 毁于蚁穴,代码坏味道就是蚁穴。

8种代码臭味

大公司也是这样吗?呵呵,那在小公司里面要是多多钻研也不必他们差了!