我不是很同意banq的观点，外国人拿科技当玩是因为已经有很强的基础，中国人往往抓不到问题的本质就是因为干什么事情都是适可而止，这种传统思想影响了整个中华民族。为什么中国优秀的程序员很少，值得深思。

缺少不是因为适可而止，是因为学而不思。中国教育在于灌输知识，而不是培养思考。学得再多再广，不思，还会怀疑过去的思想么？何来独到的观点，何来创新呢？试问中国这么多程序员，有多少是把编程当做自己的乐趣，不断思考，不断发展的？在我看来有很多已把编程沦为生活的工具了。

话题远了，回题：

“外国人拿科技当玩是因为已经有很强的基础”，那么你可以去问问看，架构所谓的基础是不是“数据结构”和“算法”。我承认程序的基础是数据结构和算法，但到达软件这样的高度，我就不认同了。架构是一种综合考量，不但考虑软硬件平台，还有各种设计思想等等（PS：我个人暂时还停留在软件阶段，硬件补充中）。云，集群，热备，单点风险，四色模型，DDD，DCI，IOC，AOP，REST……我根本不敢想象这些概念的基础是数据结构和算法。或者可以说说那个算法大牛基于数据结构和算法提出了这些东西？很好有用的东西!=基础。
[该贴被SpeedVan于2011-07-27 17:21修改过]

你能知道这么多概念还是很值得肯定的，但是就差往深了多想一步。每一个概念的基础都是数据结构和算法。

云： 这个技术是一个概念，其本质就是分布式计算，，分布式计算的基础是图论和并行算法。
集群： 这个是一种多虚一的特例，依然离不开图论与并行算法。
单点风险：主要依靠无状态和负载均衡，如何实现负责均衡呢？你自己去想，不用我说你自己就想数据结构和算法了。
DDD： 就是在定义特定领域的数据结构。
如果你想做架构，没有数据结构和算法这些基础理论的支持，只能说永远使用别人的架构别人思想的成果，甚至有时候你都无法理解别人为什么这么设计，你只能做做应用，仅此而已。
[该贴被zzxsky1986于2011-07-27 17:51修改过]

现在基本能看清软件的发展趋势了，组件(object)是肯定的，问题是组件相互叠加的组件就显得高耦合了，组件也应该非常简单，就是一个简单的功能，一般人都能使用，开发的时候就是简单组合，你需要啥子，我脑子都不用动，直接装配实现，再简单，我加入一点点能思考的软件，你提需求，让软件自己组合，不合适？你可以自己找组件装配，这种编程，小孩子都会了！而且这种组合本身就是一种乐趣！我只是简单的告诉你，组件就这个功能，如何组装就是发挥想象力的事了

基于组建的开发，这个是不是的未来的趋势不好说，我之前接触过普元公司的产品，号称是基于构件的思想，但是对复杂的业务逻辑面前这堆东西就是一个非常庞大的垃圾，你会体会到什么叫痛苦，我曾经也想抽象出一套适合大部分业务逻辑的类库，但是想着想着发现我去看eclipse的插件开发去了，后来我发现金蝶的开发产品比自己想的更完善，直到现在我又回到了起点，才发现数据结构和算法对软件的重要性，我觉的开源的思想，框架，这些技术的出现都少不了对软件基础知识的深刻理解，当你去真正研究计算机的时候你就会发现一些真正有趣的东西。
中国的程序员都是等到外国人发明出来了以后再去使用，也许将来有一天外国人发明了高智能机器人（跟科幻片里的一样）那就不需要编程了，直接语音发布命令程序自己就可以开发程序。试问中国人有潜力造出这样的东西来吗？
[该贴被zzxsky1986于2011-08-01 10:32修改过]

可能你迷失方向后，只能回到起点，关键问题是：没有脱离业务场景Context的可重用组件。

如果你想寻找脱离背景环境的纯技术组件的话，那么只有回到数学 数据结构算法上了，发明出一套算法能够应付所有情况。这个研究领域应该属于图灵数学边界，不属于我们讨论的软件工程应用领域了。

软件工程领域就如同造房子，尽管各种各样房子都有相通之处，但是每个房子还是要老老实实地一个个去设计去造。

这里有一份老外的程序员能力矩阵图，在计算机科学这项基础中，数据结构也就不过是集合数组Arrays vs LinkedLists这些使用和内部原理，我想这些是了解程序运行基础(只会用Collection而不知其原理的人也大有所在，不是他们不能掌握，而是没有时间去掌握)，恐怕不是架构基础：

http://www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htm?

[该贴被banq于2011-08-01 15:10修改过]

我所看到的，过去的程序员都是搞数据结构和算法的多，那时创新与创造真是十里不见一毛。我不是说数据结构和算法本身问题，而是造成“等到外国人发明出来了以后再去使用”这样的情况是教育问题，“学而不思则罔”，不要把这样的情况与学数据结构与算法关联起来，两者是风马牛不相及。

对于程序员和建模者，业务领域，或者说客观领域，是事实的存在。其存在的复杂性也正是要面对的东西，而不是回避。抽象出一套适合某领域大多数业务逻辑的类库，是需要掌握领域的核心，而往往这些是重构出来的，没有强硬的领域知识，不可能抽象出来，你可以问问金蝶的核心编程人员：你懂财务否？另外，若果想抽象出一套适合所有领域的业务逻辑类库，在现实中各领域还没大同之前，这是不可能的。现在有地所谓通用类库，不是面对业务的，而是面对功能的，如StringUtils，js功能函数库，脚本等。

“当你去真正研究计算机的时候你就会发现一些真正有趣的东西。”

对嘛，研究计算机，所以说你才会回到起点。做应用软件，应用系统，是面对领域，是客观事实，或者说是在研究世界，而不是慢慢地等你研究计算机。我们需要发现领域中的各种概念，需要发现领域中的相互约束，需要研究领域中逻辑的严谨性，需要探讨如何把现实投影到系统上等等。

println(软件工程==计算机?true:false);

个人观点是支持楼主的.

架构服务的最终目的还是数据 架构主要是规定数据的流向

其实 从成品的角度上看 不过是从作坊到工厂的进化...
[该贴被withmemores于2011-08-12 17:34修改过]

空谈架构和设计模式一点意义都没有，再好的架构，没有良好的数据库设计都是扯淡。从某种意义上上说，数据库设计决定了软件设计。

数据结构这些基础的东西固然重要，在战术上要重视。如果要做架构，就要上升到战略的高度，一味的关注基础可能就会一叶障目，不见泰山。

不错，架构是要考虑数据，关键是以什么方式考虑数据组织和流向？

如是以关系数据库方式？还是以对象方式？还是以事件(EDA)方式？

这篇如何学习NoSQL文章是一个有着关系数据库背景的老外写的，从它的文章来看，让他重新考虑数据模型是一种麻烦，特别是他的这篇文章：Rethink your Data Model:

作者发现关系数据库能够过滤字段，而Redis限制你查询数据的方式。Key-value意味着只能关注Key，其他都放入value中。作者认为这和愚蠢，差点放弃NoSQL，我觉得作者有些愚蠢，将Value理解成一个对象即可，而对象是数据的集合，在OO中我们经常用Map这么干，结果在文章后面他开始沿着这个思路实现了。

[该贴被banq于2011-08-19 09:25修改过]

其实我认为不管数据如何存储都只是将某种数据结构进行持久化。是使用关系型数据库存还是使用key-value的数据库存都没关系，是使用B-Tree还是使用hash关键点还是这两种数据结构的适用场景，数据结构不一定就是微观的东西，不一定就是实现细节，也可以指导思想，架构和数据结构相辅相成，做架构是需要数据结构做支撑的。

架构来自实践。

架构来自实践。但是也容易发生实践这个屁股影响脑袋，比如如果你是DBA用关系数据库一路成长过来，那么做架构时就会对高一致性有一种无法意识到的倾向，会影响你的平衡判断：

以一个案例说：
据我所知，淘宝网两年前选择了HBase做数据库，见淘宝介绍，当时我在贴了一篇HBase和Cassandra比较文章，这篇文章中文翻译地址见：http://wangxu.me/blog/p/371

文中明确倾向于Cassandra，并说：严肃地说，如果你是一个希望学习 NoSQL 系统的高级 DB 管理员的话，那么选择 HBase。这个系统超级复杂，有灵巧双手的管理员肯定能拿到高薪。

淘宝网选择HBase，和他们的DBA实践是有关系的。

在InfoQ对淘宝网采访文章中：林昊谈HBase技术在淘宝中的应用：
第一：误解Cassandra只有弱一致性，其实也可以设置为高一致性，Cassandra可以灵活设置CAP中的CP。

第二：“主要是HBase对于很多Online的场景支持的不够”，如果此前他们好好做一下抛开自己屁股对脑袋影响，对架构进行一个好的比较，就会发现HBase只适合数据挖掘和分析场合，隐含意思是实时性差，不适合做Online项目，而Cassandra优点是支持实时，当然Brisk更是用Cassandra既做数据仓库又做实时支持。

http://koven2049.iteye.com/是他们记录HBase运维日志，我个人从这些现象来判断：已经显示HBase运维的复杂性(Cassandra采取P2P Gossip相对简单);误用HBase，把非实时的产品用在实时性上，并发问题会很突出。

也就是说，架构上往往屁股决定脑袋，DBA如同恋母情结一样有高一致性情结。

相关主题：
闲话淘宝网和新浪微博架构
[该贴被banq于2011-08-25 10:15修改过]

本人认为数据结构在某种层面也是架构的一种体现，架构是一种方案，一种途径，采用哪种方案的决策者，在软件领域较架构师、体育比赛中叫教练、赛车比赛中是决策者(什么时候换轮胎、换硬胎还是软胎)、在战场上叫统帅、在音乐会上叫指挥官。在国内软件行业中大都认识不到架构师的真正作用，但不是没有架构师，技术层面的架构师往往由开源框架的架构师做了’兼职’，至于领域层面开发者兼了多职（架构、设计、程序员），系统的实现可以说是八仙过海，各显神通。系统的弊端可想而知。什么样的环境造就什么样的人才，什么样的人才造就什么样的系统。真如Banq老师说所，屁股决定了脑袋。