架构离不开数据结构

没有人跟帖吗？
那我先谈谈我的观点吧，学计算机的人都学过数据结构这门课，教材的开始就谈到了一个公式：软件= 数据结构+算法，大家似乎认为计算软件发展到现在这个公式已经跟不上时代了，其实则不然，这个公式依旧是一条定理，就算是面向对象编程的下一代编程思想出现，这个公式仍然是正确的，因为这个公式道出了计算机软件的本质，只要计算机还是冯诺依曼计算，那么这个公式就是正确的。
面向对象的思想大大的弱化了抽象这个概念，强调自然思想，用正常的思维去分析架构软件，但是计算机还是抽象的概念，建模依然是抽象的，将现实问题转化为计算机问题就是建模，其实也就是架构，我面试过很多人，基础知识都不清楚，上来就跟我谈架构，可是你有没有想过到底什么是架构？架构与数据结构和算法难道没有关系吗？

[该贴被zzxsky1986于2011-07-20 08:53修改过]

如果站在性能方面来说我还挺支持你的观点的，但站在架构层面他们还是有许多不同处的，毕竟他们的维度不同，一个是面向数据一个是面向结构。

我认为一个架构师，一个可以谈架构的人，应该对原理有所了解，否则我认为谈架构是虚谈。依然用汽车的例子来讲，架构师相当与一个汽车设计师，对汽车的各个子系统都了如指掌这样才能造出好车，而不是一个只会开汽车的人就是汽车设计师了，要想了解软件的原理，数据结构是基础中的基础。
我仅仅想发表一下自己对中国软件行业的现状的一些感慨，中国有太多的程序员是应用软件程序员，中国已经不缺乏这样的人了，不缺会开车的人，缺的是能造车的人，我认为一个老司机对汽车的原理多少都会有些认识，但是离造车还相距甚远，一个程序员也一样，不能忽略基础，否则即使做了多年软件充其量也就是一个coder。谈架构的资本也是建立在对原理的理解和掌握上的。

[该贴被zzxsky1986于2011-07-20 14:31修改过]

个人大致是这么划分的，只能大致区分，因为它们之间有相通或交叉的部分。

领域建模是从“事”的角度来描述领域，侧重探求与刻画领域本身的规律，相对独立于“人”（用户）与“物”（机器）。

数据结构、算法、数据库、缓存、分布是从“物”的角度来描述领域，侧重于发挥机器的潜力。

界面设计是从“人”的角度来描述领域，侧重于构建良好的人机交互体验。

架构分为两种：一种是将“事”的来龙去脉打理清楚，整体统筹、规划好，与领域建模的目标相近；一种是从“人”和“物”的角度进行考虑，代码组织、数据组织、交互设计等等，这后面一种可以细分为两种。

看了各位的回帖，我稍做一个总结吧。架构师这个词语似乎讲的有点泛泛了，从大家的思维角度来讲，架构师起码可以分为，应用程序架构师，系统程序架构师，这确实是两个方向，应用程序架构师更关心业务领域。
那么想引发另一个话题，应用程序架构师和系统程序架构师在中国的大环境下哪个会更有前途呢？希望说一下各自的看法，毕竟咱们咱们来自不同的领域，视角肯定会不尽相同。

哦，顺便在补充一点，我看到论坛里有很多人提的问题，似乎多是做应用软件的，我建议寻求答案的途径还是进一步熟悉你涉足的业务领域，找出你领域的业务范围，否则不会有最优答案的。

不同角度看同一事物，会有两种截然不同的观点，他们并不相斥。

架构师：
架构师这个词其实可以很广，可大致分为两种：1、创造架构者（架构为名词，狭义的架构师）；2、架构软件者（架构为动词，即广义的设计师）。

这两者都是以思想来驱动，架构软件者用什么某种思想，创造架构者就创建一个支持该思想的架构。在OO上，这种思想大多是对领域事实的分解，也就是领域分解范式，如原DDD，DCI等。（过去老是说的MVC，只是一种纯粹系统分层，完全不是领域分解范式，连客户心智模型都谈不上。）

思考角度：
软件=数据结构+算法，那是从计算机角度思考，人是计算机吗？从人的角度是什么？软件=解决“现实问题”程序。过去思考数据结构+算法的时候，是硬件紧张的年代，良好的数据结构和算法，能够充分利用计算机资源和提高计算效率。现在的软件更多是从可用性出发，就算如何慢（当然不是慢得受不了），也必须保证逻辑正确，这个逻辑正确正表现为领域中的规律。

抽象思想：
关于抽象的概念，LZ完全想错了，不是把现实想成数，叫做抽象，那是转化过程，抽象过程不是转化过程，抽象是对众多事物抽取共同的，本质的特征。可见抽象本来就在自然思想当中，别以为那是计算机独有。我们想苹果，雪梨是水果，这就是抽象，把苹果雪梨写成类，把水果写成接口，那是落实，是一种转化过程，抽象就是纯粹的思考。

数据与算法：
关于架构是否需要掌握数据和算法，架构使用者，基本上可以说不需要，架构创建者是需要的，但不是主要的，如何用各种API来支撑起思想才是首要问题，如考虑消息总线、注入方式、切入方式、缓存等来撑起某种DCI等，数据结构和算法成为优化的重要手段。

[该贴被zzxsky1986于2011-07-21 16:39修改过]

[该贴被SpeedVan于2011-07-21 17:45修改过]

这个建议我比较赞同，作为一个架构者，对待系统的态度应该是知其然知其所以然，而不应该是用过各种各样的开源框架，了解一些设计模式就可以称之为架构了，万不可忽略软件的基础知识。

[该贴被zzxsky1986于2011-07-23 10:19修改过]

我认为模式框架是架构的基础，就像字母是英文的基础一样，如果你想追求字母是怎么来的这样的所以然，也不是坏事。
刚看过变形金刚三有感想，老外是把科技当做玩，我们把科技工程当学问搞，人活得不累吗？因为我们的价值标准过于苛刻，让人没劲，何来创新呢？

相关文章：

软件架构: 质量要素

[该贴被banq于2011-07-26 15:09修改过]