什么决定架构或者说影响架构的核心因素是什么？
 |
faye.feelcool
2010-05-26
今天和同事探讨一些问题，偶尔提到了为什么要架构的问题，并交换了观点。对过去一些项目进行了反思，包括一些刚提拔上来的架构师做的一些成果，进行了检讨。
到底需不需要架构，也就是为什么要架构？如果要的话，到底什么决定架构？个人觉得，回答这个问题，就要看回答者所处的层面或者说立场了。架构的好处，可以有一堆资料，我也就不罗嗦了。 但是我们需要一个东西，就是因为这个物品有一堆好处吗？我想不一定吧！梳子是一个好东西，但是对于和尚来说，不一定就需要这个，或者说大部分和尚是不需要的，古董奢侈品除外。 现在很多一谈架构，必谈SSH，好像没有了spring那简直不叫架构。那到底什么决定架构呢？常识？流行？通用？我想也不是吧。我们请客吃饭，一般都会点些猪肉制品。但是，是不是只要是请客就必须有猪肉制品呢（如红烧排骨啊等）。起码请回族的朋友就不能点。 那，到底要不要架构，这个我们要回到架构的本质，架构为谁而生，这个概念的产生的初衷是什么。在10年前我们也不谈架构，而现在我们做什么都谈架构。到底是为什么？ 现在的客户再也不是以前的客户了，他们掌握的信息化知识比以前要多的多，而他们期望信息化给他产生效果的周期越来越短，投入也希望更少，而且企业用户为了应对快速变化的市场，他的需求也在不断的变革。这就是架构产生的背景。架构的产生就是为了能让软件开发者或企业能更好的应对这些问题，而产生的一种软件构造方法和技术。 所以架构对于需求千年不变的应用，可有可无。没有什么时间成本压力，就搞个艺术品。如果没有那么好的待遇，就搞个生活品。 那什么决定架构呢？其实上面的例子里已经很明确，就是客户决定架构。说得更直接就是客户给的钱决定架构。道理很简单架构也是要成本的，架构选用的技术都是成本。你不能点一个菜，却要求餐馆给满汉全席的待遇给你吧。 欢迎拍砖。 |
 |
javamonkey
2010-05-27
架构有很多面，功能也很多，再我看来，最重要的莫过交流，与客户交流，与同事交流。
架构其实也是一无是处的，随便一个系统的（除了功能架构）架构，可以不经过修改就应用到另外一个系统。从某种意义上，架构对于“自己人”来说没有价值 我以为，架构的核心因素当然还是人，而且是解业务系统，崇尚简单实用的的人 |
|
faye.feelcool
2010-06-02
十分欣赏你说的最后一句话：了解业务系统，崇尚简单实用的人。
|
 |
凤舞凰扬
2010-06-10
任何软件都可以归功于客户的需要，但是架构的存在并不仅仅如此。其实架构本身就是来自于建筑学。如果换一个角度思考，修一个草棚要架构么？修一个农民房要架构么，修一个商住楼要架构么？修一个商用大楼要架构么？修一个歌剧院或者世博建筑要架构么？
呵呵，其实这就是问题的关键，当一个软件系统越来越复杂，越来越庞大时，它不就是简单的堆砌和抄袭就可以的了，架构师也就应运而生了。 当然了，绝大多数我们所做的软件系统只是一个简单的MIS，只是独立不需要太多而外因素考虑的独立系统，SSH在开发层面已经做得很好了，至少让我们经常碰到的架构实现没那么复杂。但是请注意，它们能帮助到你的仅仅是你的快速开发而已，对于其他层次的问题，它们能解决么？比如业务架构关系、性能、部署与通信模式等。 不是架构太简单，而是如今拥有架构师头衔的人太简单了啊~ |
 |
ecsoftcn
2010-06-27
“不是架构太简单，而是如今拥有架构师头衔的人太简单了啊~ ”凤舞兄这句话说的很到位。
“什么决定架构或者说影响架构的核心因素是什么？”个人觉得这个命题还算比较大的，考虑如下层面因素： 1、规模：如果你的项目只是一个很小的系统，如一个普通的MIS，那么的确不用什么架构，或者简单的SSH就可以了；但是当你的项目是一个千万级会员使用的系统时，架构就变得尤为重要。 2、成本：如果你的公司很有钱，如银行、电信等，那么你可以选择高端的、昂贵的数据库、存储、服务器甚至大型机等等。有了这些你的架构就简单了，因为这些高端的硬件和软件可以帮你搞定绝大多数问题【PS:最近面试的一些人，虽然也有4、5年的工作经验，但是大多都建立在这些高端设备基础之上，不懂得性能测试、不懂得负载均衡、不懂得水平/垂直拆分。。。】；但是，如果很不幸你的公司没有太多的钱，那么只好选择相对比较廉价的设备和开源的软件来搭建系统，这就要求架构师有很强的技术选型和驾驭能力。 3、员工的技术水平：设想一下，如果你的公司的员工都是搞JAVA的，那么突然有一天你决定某个项目用C来做，那么困难会有多大，结果会怎样。所以架构也要考虑员工的技术水平。 4、架构师的第六感：实在想不到什么更好的词了，其实想表达的就是架构师的经验积累、技术和业务敏感度、对业务和产品未来发展的准确预估等。 当然，对客户需求的准确把握是最最基本的要求了。 |
|
凤舞凰扬
2010-07-01
呵呵，楼上其实指出了架构设计的核心理念。一个架构师应该懂得它，而不是去照搬一些东西（比如有名的SSH，组合一下就是系统架构了，对么？其实也对，只是他忽略了架构设计的核心理念）。
在这里，我把我对架构设计的核心理念的理解整理一下，大家交流下。 1. 对于系统背景的掌握，这里的背景包括系统隐喻（系统的需求定位）、系统应用的场景（业务模式、应用环境）、系统的目标与期望值（比如用户量、业务量）等。根据系统背景的掌握。 2. 对于项目环境的理解，包括公司的对于项目的定位、项目的研发周期、资源及资源的能力、项目的规模等。 3. 对于技术方案的理解，包括不同场景下的技术方案的优缺点、不同公司产品（包括开源产品）的应用场景和优缺点。（说到这里，我不得不提一下那些动则某某技术已死，某某技术最好等思想和观念，这些都是成为架构师的最大阻力，好的架构师应该保持一个客观中立的技术观点） 4. 妥协与折中，这是架构设计最为重要的一个理念和观点。这个世界没有完美的东西，只有适合的东西。另外架构设计的理念是必须充分传递到系统的每一个角落，所以架构设计是必须让团队每一个成员理解和接受，不是闭门造车，随便组合就可以了。 |
 |
hu97086
2010-07-09
To:凤舞凰扬 准确、精要！
To:ecsoftcn 微观、可操作！ |
 |
mingjian01
2010-07-16
客户需求吧，特别是非功能性需求
|
