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

话题远了，回题：

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

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

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

可能你迷失方向后，只能回到起点，关键问题是：没有脱离业务场景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修改过]

架构来自实践。但是也容易发生实践这个屁股影响脑袋，比如如果你是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修改过]