架构离不开数据结构

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

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

是的，zzxsky1986 谈的属于两种不同边界内的东西，“计算机是冯诺依曼计算”是说明事物内部原理，而架构是指如何使用这个事物，是从事物外部来看的。

一个是事物内部，一个是事物外部，完全不同领域的。

再打一个例子，汽车内部原理和我们如何使用汽车完全是两码事；自行车内部原理和我们如何骑自行车是两码事，骑自行车的基础和自行车自身结构基础不是一回事。

请问有考驾驶执照时，有考你汽车内部原理的吗？我们知道汽车内部原理那是修理汽车和制造汽车专业的事情。

再回到计算机软件，计算机软件使用基础与软件是如何在计算机内部运行的内部机制是两码事。所以，楼主作为面试官，要求程序员知识广泛是好的，但是切不可随便跨越边界，让应聘者无法定位你们是找使用软件的，还是找修理软件或制造发明新软件语言的人。

不过话说回来，尽管架构是指应用架构，但是应用架构中数据结构知识有时还是需要的。

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

可能你还没有敏感到我前面谈的边界问题。你是认为：架构师=汽车设计师，我认为：架构师=赛车手。

赛车手和汽车设计师是完全不同的职业，泾渭分明的边界。赛车手的基础是什么？是会开车，架构师的基础是什么？是会用软件。但是赛车手和架构师不只是会，而是要深入，但是赛车手深入的方向和汽车设计师深入方向是不一样的。

架构师深入的方向是什么？是如何结合当然业务应用场景和当前软件技术水平给出一个合适的解决方案。

方向既然知道了，那么架构师的基础是什么就应该很清楚，从两个方面衡量：业务应用场景的了解程度和分析方法(领域建模)；当前软件技术水平(REST JavaEE 多层架构这些特点和优缺点等等)。

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

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

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

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

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

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

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

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

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

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

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

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

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

这样的说法，早在多年已经看多了。我说明以下几点：

1、“软件=”是思考角度决定的，并不是谈论本质，要谈论本质，数据结构和算法不就是“0”和“1”，那岂不是“01”本质。确定从什么角度切入思考，才有所谓的本质。

2、面向对象与面向类有着很大不同，面向类是面向对象的一种实现方式而已。请彻底醒悟对OO的思考，可以先从何为对象开始。（可以参阅过去的帖子）

3、算法为方法论的说法我看多了。象数问题，已经讨论多次了。可以去回顾以前的帖子，认清楚各自的地位。一切解决方法就在自然当中，不需硬要用算法来代替。
[该贴被SpeedVan于2011-07-21 17:45修改过]

另外，深受《人月神话》影响，理想状态下的软件团队应当像外科手术团队一样。架构者不要只架构不实施，给其他人员感觉高高在上。架构者还应当具体承担某项实施工作，比如编码、测试，甚至文档。否则，很容易放大架构者与其他实施者的天然抵触因素，导致团队意见不一、模糊愿景、沟通不畅、效率底下。
所以，招聘程序员，你可以细谈算法和数据结构，这样很合适。招聘软件架构者，应当将重点放在编程思想、建模经验上，而不当舍本取末。

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

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

相关文章：
软件架构: 质量要素

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