架构 vs. 编程
很多人对架构一直持有怀疑性,认为架构师是架构宇航员(不落地)如图:
博文Architecture versus Code对此提出了自己对架构实用性认识,本人非常赞同,转贴如下:
1.架构应该注重自身的可伸缩性和可维护性
软件最终是需要成长,其他程序员需要接管继续编程拓展维护,如果你架构是如此僵化令人费解,以至于软件就不能成长拓展,它可能需要被重新设计(BanQ语:推倒重来很符合中国国情,又多了一次采购机会)
2.方法论和设计模式不应该过于复杂
虽然学习曲线是可以接受的,如果需要过多的时间来学习插件和架构时,它可能不值得使用,尤其是对于较小的项目。
3.架构必须有助于解决现在的问题
如果你有一把锤子,所有的问题看起来像一个钉子,没有一种尺寸适合所有裤子,人们容易有一种倾向,将业务和基础技术架构进行分离,偏袒他们知道,或他们所认为的“可以接受”的做事方式。
4.架构应该推荐最佳实践模式,引导程序员进入结构化稳定开发方式。
在代码完成,史蒂夫麦康奈尔描述了良好的架构作用:
深思熟虑的架构提供需要保持一个系统的从底部到最高层的概念完整的结构。它提供指导程序员以各自水平入手的方便性。良好的架构使施工方便。坏的架构使开发几乎是不可能的。
Grady Booch总结了架构和良好代码之间的平衡(总结见原文),这首先来自于一个面向对象设计,因为没有硬性规定实战中应该采取哪些设计方案,所以必须在一个项目开始架构之初就确定出一个好的适合本项目的架构设计思想。
[该贴被banq于2009-11-18 15:34修改过]