首席架构师汪洋坐镇，欢迎大伙提问啊：软件架构连载讨论之一：正确认识软件架构

yanyangtian4502

回复 27# chenyx


    抚琴在这一块确实有研究！不错的

yanyangtian4502

感觉这个问题太泛了，和业务关系很大，比如说WEB应用层，语言本身的性能问题基本是可以忽略的， ...
bs 发表于 2011-10-13 10:59

    性能的话题太广泛了，如果不考虑成本，基本上没有什么需要考虑的！因为一切可以用钱砸，用人堆嘛！

yanyangtian4502

回复 36# snow888


    是的，现在的大型网站都要采用服务器负载均衡与数据集群技术来实现

yanyangtian4502

可否谈谈架构师与各个团队的合作的问题以及经验，架构师如何将自己的理念传达下去，并确保执行，现实中遇到 ...
bs 发表于 2011-10-13 14:14

    当然了，这个我会在后面详细的讲述的！放心吧 呵呵呵

yanyangtian4502

回复 41# snow888


    其实说到这点，也是国情！很多的国内软件项目 不要架构师 几个开发人员上就行了！ 架构师在创业企业和外企还是比较多的， 特别在互联网行业！ 架构师的核心竞争力是无法代替的！
这就是在一个职业发展的问题，很多人不会把技术一直搞下去！也不是很多人想要达到架构师的位置！ 人各有志，无可厚非！

当你把技术做到一定程度之后，就会发现：用技术带来经济价值才是最重要的！
其实这也是我现在比较关注的一点！

yanyangtian4502

回复 43# napleon


    架构不仅仅只是考虑逻辑的层面，或者说 架构不仅仅只是考虑代码方面的东西，其实更多的时候是综合的考虑：人，资源，技术，投资者的利益等

yanyangtian4502

所以一个架构做出来之后，我们可以看到的可能就是一些文档，代码等，其实这些都只是架构的一种反应形式，架构！=编写文档！

yanyangtian4502

不同的人对架构有着不一样的理解。无论是在建筑行业、软件行业，还是在网络或书本上，“架构”一词有着各种各样的解释。在编程的世界中，很多对架构的解释都是从技术的层面来定义的，而且在不同的技术或平台上面，对架构的定义又不太一样，甚至有些定义和理解失去了其原本的核心意思，这就使得部分架构学习者感到迷茫。

如果认为“架构”是一个简单的实体，能够用一份文档或一张图纸来描述，那么你就错了。确实，架构师在为系统创建架构时经常要做出很多与设计相关的决定，而且会以用文档的形式记录下来，但是架构和文档又不是等同的，之所以要以文档的形式保存，主要是为了便于以后对这些设计决定进行审核和修改，并且将其作为构建软件时的约束和指导。

yanyangtian4502

回复 50# AD8018


    ok，我看看

yanyangtian4502

言归正传。
我对系统架构上面有两个疑问，楼主能帮指点一下？

1. 无重构没有好架构

   开发一个项目之前，各方面都想的不错。
   然而，随着需求的深入和增加，缝补的东西变多，ctrl-c/ctrl-v的东西变多。
   最后，要么忍受，要么狠心重构。
   于是，在我的概念里，就有了这句话 -- 无重构没有好架构

   如何做到不重构，仍有好架构？

回答：在项目开始之前，其实我们对需求和功能不是完全清楚的，这个时候，不会，也不可能将系统架构全部做出来。此时只是的设计是最简单的，采用接口编程的形式，将每个层之间的衔接搞好，便于后续改动！
改动是在所难免的，很多人认为：架构师就是在开始就将整个系统的架构全部设计好了，其实这是不对的！架构师的在刚刚开始的时候，做出的架构也很简单，目的在于尽可能的是的以后的改动波及到的代码更少。然后，每次的项目迭代，不断的将架构完善，重构也是一个必要的步骤（很不幸的是，在后续的迭代中，很多公司和人员都不愿意花时间去重构了，认为很花时间，并且没有效果）

2. 多一层架构，多一层混乱

   以前迷恋封装接口之类的东西。其目的，原本是统一和简化接口，
   最后，还是随着需求的深入和增加，
   统一和简化的接口，变成了多增加的接口。

   为什么？其实你没有简化接口，原本的接口还在。
   你要强迫别人不用吗？很难。

回答：设计其实就是追求的简单，从实际出发，不做无谓的假设（如果要做假设，那么就要对该项目的领域很清楚）！很多人在设计的时候，为了显摆自己很牛或处于其他的原因，把项目设计的N复杂。

   Win32 API是一层接口，c库是一层接口，mfc是一层接口。
   哪一层的封装，都使事情朝着简单和混沌两个方向发展。
   简单能理解，混沌呢，比如
    CreateThread -> beginthread -> AfxBeginThread
   用的不好会要命。你觉得封装的结果，使事情变简单了，还是变复杂了？

   这是接口设计的例子。反应到设计架构上时，俺就如履薄冰，尽量避免无畏的封装。
   封装的不好，还不如不封装。
   最终的结果，就是你的项目，变成一坨谁都不愿意碰的东西。

   如何避免以上的窘境？

总之：走简单路线，在开始的时候，设计一个基本的几层逻辑架构就行了，并且每层采用接口实现，后续项目不断的迭代，不断的改进！不要无谓的做很多的假设（不要说：以后可能会这样等话语）。也不要花尽心思想：这里采用什么模式，那么采用什么原则！等到出现的时候再改！
记住：小步骤，多行动，不断的改动！没有万灵丹！