Jun
1
一、不要过设计：never over design
这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计 大而化一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构Web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做 出最快最有效的响应。
eBay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是eBay架构师的能力有问题，他们 设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架 构。
Web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计， 是不现实的。
二、Web架构生命周期：Web architecture‘s life cycle
既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你。
所设计的架构需要在1－10倍的增长下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下 一个10倍间的增长。
google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然 而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的。
三、缓存：Cache
空间换取时间，缓存永远计算机设计的重中之重，从CPU到IO，到处都可以看到缓存的身影，Web架构设计重，缓存设计必不可少，关于怎样设计合理 的缓 存，JBossCache的创始人，淘宝的创始人是这样说的：其实设计Web缓存和企业级缓存是非常不同的，企业级缓存偏重于逻辑，而Web缓存，简单快 速为好。
缓存带来的问题是什么？是程序的复杂度上升，因为数据散布在多个进程，所以同步就是一个麻烦的问题，加上集群，复杂度会进一步提高，在实际运用中， 采用怎样的同步策略常常需要和业务绑定。
老钱为搜狐设计的帖子设计了链表缓存，这样既可以满足灵活插入的需要，又能够快速阅读，而其他一些大型社区也经常采用类此的结构来优化帖子列 表，MemCache也是一个常常用到的工具。
Cache的常用的策略是：让数据在内存中，而不是在比较耗时的磁盘上。从这个角度讲，My SQL提供的heap引擎（存储方式）也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢?
我们这里只说到了读缓存，其实还有一种写缓存，在以内容为主的社区里比较少用到，因为这样的社区最主要需要解决的问题是读问题，但是在处理能力低于 请求能力时，或者单个希望请求先被缓存形成块，然后批量处理时，写缓存就出现了，在交互性很强的社区设计里我们很容易找到这样的缓存。
四、核心模块一定要自己开发：DIY your core module
这点我们是深有体会。钱宏武和云风也都有谈到，我们经常倾向于使用一些开源模块，如果不涉及核心模块，确实是可以的。如果涉及，那么就要小心了，因 为当访问量达到一定的程度，这些模块往往都有这样那样的问题，当然我们可以把问题归结为对开源的模块不熟悉，但是不管怎样，核心出现问题的时候，不能完全 掌握其代码是非常可怕的。
五、合理选择数据存储方式：reasonable data storage
我们一定要使用数据库吗，不一定，雷鸣告诉我们搜索不一定需要数据库，云风告诉我们，游戏不一定需要数据库，那么什么时候我们才需要数据库呢，为什 么不干脆用文件来代替他呢？
首先我们需要先承认，数据库也是对文件进行操作。我们需要数据库，主要是使用下面这几个功能：一个是数据存储，一个是数据检索。
在关系数据库中，我们其实非常在乎数据库的复杂搜索的能力，看看一个统计用的TSQL就知道了。
select c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select count(Id) from review where Reviewid=a.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id
select a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d,review as e where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id and a.Id=e.Reviewid group by a.Id ……………………………………….
我们可以看出需要数据库关联，排序的能力，这个能力在某些情况下非常重要，但是如果你的网站的常规操作，全是这样复杂的逻辑，那效率一定是非常低 的，所以我们常常在数据库里加入许多冗余字段，来减小简单查询时关联等操作带来的压力，我们看看下面这张图，可以看到数据库的设计重心，和网站(指内容型 社区)需要面对的问题实际是有一些偏差的。
同样其他一些软件产品也遇到同样的问题所以具我了解，有许多特殊的运用都有自己设计的特殊数据存储结构与方法，比如有的大型服务程序采取树形数据存 储结构，Lucene使用文件来存储索引和文件。
从另外一个角度上看，使用数据库，意味着数据和表现是完全分离的（这当然是经典的设计思路），也就是说当需要展示数据时，不得不需要一个转换的过 程，也可以说是绑定的过程，当网站具备一定规模的时候，数据库往往成为效率的瓶颈，所以许多网站也采用直接书写静态文件的方法来避免读取操作时的绑定。
这并不是说我们从今天起就可以把我们亲爱的数据库打入冷宫，而是我们在设计数据的持久化时，需要根据实际情况来选择存储方式，而数据库不过是其中一 个选项。
六、搞清楚谁是最重要的人：Who’s the most important guy?
在用例需求分析的时候常常讲到涉众，就是和你的设计息息相关的人，在Web中我们一定以为最重要的涉众莫过于用户了。在一个传统的互动社区开发中， 最重要的东西是内容，用户产生内容，所以用户就是上帝，至于内容挑选工具，不就是给坐我后面三排的妹妹们用的吗？凑或行了，实在有问题我就在数据里手动帮 你加得了。
这大概是眼下许多小型甚至中型网站技术人员的普遍想法。钱宏武在他的讲座里谈到了这个问题：实际上网站每天产生的内容非常的多，普通人是不可能看完 的，而编辑负责把精华的内容推荐到首页上，所以很多用户读到的内容其实都依赖于编辑的推荐，所以设计让编辑工作方便的工具也是非常重要， 有时甚至是最重要的。
七、不要执着于文档：Don’t be crazy about document
Web开发的文档重要吗？什么文档最重要？我的看法是Web开发中交流>文档，现在大的软件公司比较流行的做法是：
注重产品设计文档，在这种方法里，产品文档非常详尽，并且没有歧义，开发人员基于设计文档开发，测试人员基于设计文档制定测试方案，任何新人都可以 通过阅读产品设计文档来了解项目的概况。
而Web项目从概念到实现的时间是非常短的，而且越短越好，并且由于变化迅速，要想写出完整的产品和需求文档是几乎不可能的，大多数情况是等你写出 完备的文档，项目早就是另外一个样子，但是没有文档的问题是，如果团队发生变化，添加新成员怎样才能了解软件的结构和概念呢?一种是每个人都了解软件的整 个结构，除非你的团队整体消失，否则任何一个人都能够担当培养新人的责任，这种面对面交流比文档有效率很多。
于是就有了前office开发者，现任yahoo中国某产品开发负责人的刘振飞所感觉到的落差，他说：“我们的项目是吵出来的”，我听完会心一笑。
八、团队：team
不要专家团队，而要外科手术式的团队。你的团队里一定要有清道夫，需要有弓箭手，让他们和项目一起成长，才是项目负责人的最大成就。
总 结：架构是一种权衡
Web开发的特点是是：没有太复杂的技术难点，一切在于迅速的把握需求，其实这正式敏捷开发的要旨所在，一切都可以非常快速的建立，非常快速的重 构，我们的开发工具，底层库和框架，包括搜索引擎和web文档提供的帮助，都提我们供给了敏捷的能力。
此外，相应的，最有效率的交流方式必须留给 Web开发，那就是面对面，不要太担心你的设计不能被完备的文档所保留下来，他们会以交流，代码和小卡片的方式保存下来。
人的因素会更加重要，无论是对用户的需求，还是开发人员的素质。
这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计 大而化一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构Web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做 出最快最有效的响应。
eBay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是eBay架构师的能力有问题，他们 设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架 构。
Web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计， 是不现实的。
二、Web架构生命周期：Web architecture‘s life cycle
既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你。
所设计的架构需要在1－10倍的增长下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下 一个10倍间的增长。
google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然 而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的。
三、缓存：Cache
空间换取时间，缓存永远计算机设计的重中之重，从CPU到IO，到处都可以看到缓存的身影，Web架构设计重，缓存设计必不可少，关于怎样设计合理 的缓 存，JBossCache的创始人，淘宝的创始人是这样说的：其实设计Web缓存和企业级缓存是非常不同的，企业级缓存偏重于逻辑，而Web缓存，简单快 速为好。
缓存带来的问题是什么？是程序的复杂度上升，因为数据散布在多个进程，所以同步就是一个麻烦的问题，加上集群，复杂度会进一步提高，在实际运用中， 采用怎样的同步策略常常需要和业务绑定。
老钱为搜狐设计的帖子设计了链表缓存，这样既可以满足灵活插入的需要，又能够快速阅读，而其他一些大型社区也经常采用类此的结构来优化帖子列 表，MemCache也是一个常常用到的工具。
Cache的常用的策略是：让数据在内存中，而不是在比较耗时的磁盘上。从这个角度讲，My SQL提供的heap引擎（存储方式）也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢?
我们这里只说到了读缓存，其实还有一种写缓存，在以内容为主的社区里比较少用到，因为这样的社区最主要需要解决的问题是读问题，但是在处理能力低于 请求能力时，或者单个希望请求先被缓存形成块，然后批量处理时，写缓存就出现了，在交互性很强的社区设计里我们很容易找到这样的缓存。
四、核心模块一定要自己开发：DIY your core module
这点我们是深有体会。钱宏武和云风也都有谈到，我们经常倾向于使用一些开源模块，如果不涉及核心模块，确实是可以的。如果涉及，那么就要小心了，因 为当访问量达到一定的程度，这些模块往往都有这样那样的问题，当然我们可以把问题归结为对开源的模块不熟悉，但是不管怎样，核心出现问题的时候，不能完全 掌握其代码是非常可怕的。
五、合理选择数据存储方式：reasonable data storage
我们一定要使用数据库吗，不一定，雷鸣告诉我们搜索不一定需要数据库，云风告诉我们，游戏不一定需要数据库，那么什么时候我们才需要数据库呢，为什 么不干脆用文件来代替他呢？
首先我们需要先承认，数据库也是对文件进行操作。我们需要数据库，主要是使用下面这几个功能：一个是数据存储，一个是数据检索。
在关系数据库中，我们其实非常在乎数据库的复杂搜索的能力，看看一个统计用的TSQL就知道了。
select c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select count(Id) from review where Reviewid=a.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id
select a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d,review as e where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id and a.Id=e.Reviewid group by a.Id ……………………………………….
我们可以看出需要数据库关联，排序的能力，这个能力在某些情况下非常重要，但是如果你的网站的常规操作，全是这样复杂的逻辑，那效率一定是非常低 的，所以我们常常在数据库里加入许多冗余字段，来减小简单查询时关联等操作带来的压力，我们看看下面这张图，可以看到数据库的设计重心，和网站(指内容型 社区)需要面对的问题实际是有一些偏差的。
同样其他一些软件产品也遇到同样的问题所以具我了解，有许多特殊的运用都有自己设计的特殊数据存储结构与方法，比如有的大型服务程序采取树形数据存 储结构，Lucene使用文件来存储索引和文件。
从另外一个角度上看，使用数据库，意味着数据和表现是完全分离的（这当然是经典的设计思路），也就是说当需要展示数据时，不得不需要一个转换的过 程，也可以说是绑定的过程，当网站具备一定规模的时候，数据库往往成为效率的瓶颈，所以许多网站也采用直接书写静态文件的方法来避免读取操作时的绑定。
这并不是说我们从今天起就可以把我们亲爱的数据库打入冷宫，而是我们在设计数据的持久化时，需要根据实际情况来选择存储方式，而数据库不过是其中一 个选项。
六、搞清楚谁是最重要的人：Who’s the most important guy?
在用例需求分析的时候常常讲到涉众，就是和你的设计息息相关的人，在Web中我们一定以为最重要的涉众莫过于用户了。在一个传统的互动社区开发中， 最重要的东西是内容，用户产生内容，所以用户就是上帝，至于内容挑选工具，不就是给坐我后面三排的妹妹们用的吗？凑或行了，实在有问题我就在数据里手动帮 你加得了。
这大概是眼下许多小型甚至中型网站技术人员的普遍想法。钱宏武在他的讲座里谈到了这个问题：实际上网站每天产生的内容非常的多，普通人是不可能看完 的，而编辑负责把精华的内容推荐到首页上，所以很多用户读到的内容其实都依赖于编辑的推荐，所以设计让编辑工作方便的工具也是非常重要， 有时甚至是最重要的。
七、不要执着于文档：Don’t be crazy about document
Web开发的文档重要吗？什么文档最重要？我的看法是Web开发中交流>文档，现在大的软件公司比较流行的做法是：
注重产品设计文档，在这种方法里，产品文档非常详尽，并且没有歧义，开发人员基于设计文档开发，测试人员基于设计文档制定测试方案，任何新人都可以 通过阅读产品设计文档来了解项目的概况。
而Web项目从概念到实现的时间是非常短的，而且越短越好，并且由于变化迅速，要想写出完整的产品和需求文档是几乎不可能的，大多数情况是等你写出 完备的文档，项目早就是另外一个样子，但是没有文档的问题是，如果团队发生变化，添加新成员怎样才能了解软件的结构和概念呢?一种是每个人都了解软件的整 个结构，除非你的团队整体消失，否则任何一个人都能够担当培养新人的责任，这种面对面交流比文档有效率很多。
于是就有了前office开发者，现任yahoo中国某产品开发负责人的刘振飞所感觉到的落差，他说：“我们的项目是吵出来的”，我听完会心一笑。
八、团队：team
不要专家团队，而要外科手术式的团队。你的团队里一定要有清道夫，需要有弓箭手，让他们和项目一起成长，才是项目负责人的最大成就。
总 结：架构是一种权衡
Web开发的特点是是：没有太复杂的技术难点，一切在于迅速的把握需求，其实这正式敏捷开发的要旨所在，一切都可以非常快速的建立，非常快速的重 构，我们的开发工具，底层库和框架，包括搜索引擎和web文档提供的帮助，都提我们供给了敏捷的能力。
此外，相应的，最有效率的交流方式必须留给 Web开发，那就是面对面，不要太担心你的设计不能被完备的文档所保留下来，他们会以交流，代码和小卡片的方式保存下来。
人的因素会更加重要，无论是对用户的需求，还是开发人员的素质。
May
23
作者：曾宪杰。2002年毕业于浙江大学计算机系。先后在中科院下属企业、先锋电子(中国)就职。积累了丰富的Windows平台、企业级系统设计经验。现任淘宝网平台架构部架构师，主要研究方向为大规模集群环境下的消息中间件设计、分布式数据层和分布式系统。
淘宝网，是一个在线商品数量突破一亿，日均成交额超过两亿元人民币，注册用户接近八千万的大型电子商务网站，是亚洲最大的购物网站。那么对于淘宝 网这样大规模的一个网站，我猜想大家一定会非常关心整个网站都采用了什么样的技术、产品和架构，也会很想了解在淘宝网中是否采用了开源的软件或者是完全采 用的商业软件。那么下面我就简单的介绍一下淘宝网中应用的开源软件。
对于规模稍大的网站来说，其IT必然是一个服务器集群来提供网站服务，数据库也必然要和应用服务分开，有单独的数据库服务器。对于像淘宝网这样规模 的网站而言，就是应用也分成很多组。那么下面，我就从应用服务器操作系统、应用服务器软件、Web Server、数据库、开发框架等几个方面来介绍一下淘宝网中开源软件的应用。
操作系统
我们首先就从应用服务器的操作系统说起。一个应用服务器，从软件的角度来说他的最底层首先是操作系统。要先选择操作系统，然后才是操作系统基础上的 应用软件。在淘宝网，我们的应用服务器上采用的是Linux操作系统。Linux操作系统从1991年第一次正式被公布到现在已经走过了十七个年头，在 PC Server上有广泛的应用。硬件上我们选择PC Server而不是小型机，那么Server的操作系统供我们选择的一般也就是Linux，FreeBSD, windows 2000 Server或者Windows Server 2003。如果不准备采用微软的一系列产品构建应用，并且有能力维护Linux或者FreeBSD，再加上成本的考虑，那么还是应该在Linux和 FreeBSD之间进行选择。可以说，现在Linux和FreeBSD这两个系统难分伯仲，很难说哪个一定比另外一个要优秀很多、能够全面的超越对手，应 该是各有所长。那么在选择的时候有一个因素就是企业的技术人员对于哪种系统更加的熟悉，这个熟悉一方面是系统管理方面，另外一方面是对于内核的熟悉，对内 核的熟悉对于性能调优和对操作系统进行定制剪裁会有很大的帮助。而应用全面的优化、提升性能也是从操作系统的优化开始的。
应用服务器
在确定了服务器的硬件、服务器的操作系统之后，下面我们来说说业务系统的构建。淘宝网有很多业务系统应用是基于JEE规范的系统。还有一些是C C++构建的应用或者是Java构建的Standalone的应用。那么我们要选择一款实现了JEE规范的应用服务器。我们的选择是JBoss Applcation Server。JBoss AS是RedHat的一个开源的支持JEE规范的应用服务器。在几年前，如果采用Java技术构建互联网应用或者企业级应用，在开源软件中的选择一般也就 是Apache组织的Tomcat、JBoss的 JBoss AS和Resin。严格意义上讲，Tomcat和Resin并不能算是一个应用服务器，他们是实现了部分J2EE规范的一个容器。而商业软件的选择就是 IBM的WebSphere和BEA的WebLogic。到了现在，除了JBoss AS外，Apache的Geronimo，Sun的Glassfish也都是很优秀的JEE应用服务器。也给现在的开发人员提供了更多的选择。具体对于目 前JEE应用服务器的比较。这边就不在赘述。
在应用服务器前端，我们采用了Web Server做了一次转发，我们选择的Web服务器是大名鼎鼎的Apache。几年前，Apache几乎是Linux系统上开源Web Server的唯一选择。那个时候虽然也有一些其他的开源的Web Server，但是从功能和稳定性上来说都无法和Apache相对。在今天来说，Lighty也会是一个非常好的选择。Lighty是一个非常轻量级、占 用内存资源也比较少的Web Server。虽然功能上没有Apache强大，但是在不少场景下，性能是非常出色、强于Apache的。而微软的IIS，就只能工作在Windows的 系统上了。并且使用IIS的话，基本上也就是选择了ISAPI、ASP或者ASP.NET进行Web应用的开发了。
数据库
说完了我们采用的操作系统、应用服务器、WebServer后，下面就来谈谈我们的数据库。在淘宝网的应用中，采用了两种关系型数据库管理系统。一 个是 Oracle公司的Oracle 10g，另外一个是Sun MySQL的MySQL。Oracle是一款优秀的、广泛采用的商业数据库管理软件。有很强大的功能和安全性，可以处理相对海量的数据。而MySQL是一 款非常优秀的开源数据库管理软件，非常适合用多台PC Server组成多点的存储节点阵列(这里我所指的不是MySQL自身提供的集群功能)，每单位的数据存储成本也非常的低廉。用多台PC Server安装MySQL组成一个存储节点阵列，通过MySQL自身的Replication或者应用自身的处理，可以很好的保证容错(允许部分节点失 效)，保证应用的健壮性和可靠性。可以这么说，在关系数据库管理系统的选择上，可以考虑应用本身的情况来决定。
一个互联网应用，除了服务器的操作系统，Web Server软件，应用服务器软件，数据库软件外，我们还会涉及到一些其他的系统，比如一些中间件系统、文件存储系统、搜索、分布式框架、缓存系统等等。 在淘宝网，这些系统都是自主开发的，没有采用目前商业的或者开源的产品。有些系统，会存在着一些开源的产品或者商业产品。但是，考虑到淘宝网自己的需求和 大并发量的压力，这些系统都选择了自主开发框架。
前面谈的都是系统级的产品，下面我们说说开发框架的使用。可能有朋友想问，作为一个如此大规模的网站，淘宝网的Web展现层采用的是什么框架，是怎 么实现的呢？曾经也有到淘宝的应聘者问过我这个问题，他问我说是不是用的 struts。我告诉他说不是的。其实淘宝网的Web展现层的框架用的不是struts，不是webwork，不是spring mvc等等。淘宝网的Web展现层的框架用的是集团内部自主开发的一套Web框架。这个框架能够解决一些其他Web框架不能解决的、在淘宝的应用中又会出 现并需要解决的问题。在淘宝的多个应用中，也采用了一些开源的框架，比如Spring、iBatis、jBPM、Hessian、Mina等等。这些开源 软件的采用为我们构建应用系统提供了很大的帮助。
采用开源软件构建系统，我想有两个很大的好处：
一个是降低成本。假设你有1000台应用服务器，如果你每台服务器上采用的不是JBoss AS或者其他开源的软件，而是使用商业的Oracle BEA的Weblogic或者IBM的WebSphere，那么为这1000台机器的应用购买License的费用是非常高的。
另外一个好处(我觉得最大的好处)是你可以看到软件的源码，你可以研究了解软件内部的工作过程、原理。这对于应用设计、开发、查错、优化都是非常有 帮助的。
淘宝网的开源观
对于开源软件的应用，有些人可能担心质量的问题，有些人可能担心软件本身发展更新的问题，等等。对于质量的问题，我想现在很多的开源软件尤其是一些 很著名的开源软件都有很完善的组织，有完善的开发、测试、发布流程。在一个新版本完成前，会有多次的测试版本发布，最后才是正式版。这和商业软件是一样 的。并且因为代码公开，反而更加的容易发现错误，提高质量。至于第二个问题，我想跟第一个问题一样，关键是组织和规划而不在是否开源，并且在很多著名的开 源软件背后，会有厂商在进行支持。软件本身的发展应该是不会成为问题的，不太会出现软件突然停止发展的情况。
在今后的发展中，我们还是会一如既往的关注开源软件的发展，也还会根据需要采用不同的开源软件。在选择一个开源产品的时候，我会考虑以下几点：
1. 这个软件目前的功能和它的RoadMap
2. 软件本身的架构
3. 该软件开发的活跃度
4. 该开源软件是否是遵守该领域内的国际规范的
5. 在同类产品中，要挑选有比较优势的。并且要考虑可能存在的移植代价。这个移植指的是采用了这款开源软件后现有系统的移植，或者是从这个开源软件到其他软件 的移植。
对于企业级系统、互联网应用来说，采用开源软件不仅可以降低成本，更重要的是能够真正了解软件的内部工作机制。还可以在现在的基础上进行增强和定 制，也能够从开源软件中借鉴到很多好的设计和实现。希望国内能有更多的企业在使用开源软件的同时，也能开源自身的一些软件，或者能够成为一些开源软件的贡 献者。而作为淘宝网，我们也会非常积极的参与到开源的活动中，也会努力为开源的发展做出我们应有的贡献。
淘宝网，是一个在线商品数量突破一亿，日均成交额超过两亿元人民币，注册用户接近八千万的大型电子商务网站，是亚洲最大的购物网站。那么对于淘宝 网这样大规模的一个网站，我猜想大家一定会非常关心整个网站都采用了什么样的技术、产品和架构，也会很想了解在淘宝网中是否采用了开源的软件或者是完全采 用的商业软件。那么下面我就简单的介绍一下淘宝网中应用的开源软件。
对于规模稍大的网站来说，其IT必然是一个服务器集群来提供网站服务，数据库也必然要和应用服务分开，有单独的数据库服务器。对于像淘宝网这样规模 的网站而言，就是应用也分成很多组。那么下面，我就从应用服务器操作系统、应用服务器软件、Web Server、数据库、开发框架等几个方面来介绍一下淘宝网中开源软件的应用。
操作系统
我们首先就从应用服务器的操作系统说起。一个应用服务器，从软件的角度来说他的最底层首先是操作系统。要先选择操作系统，然后才是操作系统基础上的 应用软件。在淘宝网，我们的应用服务器上采用的是Linux操作系统。Linux操作系统从1991年第一次正式被公布到现在已经走过了十七个年头，在 PC Server上有广泛的应用。硬件上我们选择PC Server而不是小型机，那么Server的操作系统供我们选择的一般也就是Linux，FreeBSD, windows 2000 Server或者Windows Server 2003。如果不准备采用微软的一系列产品构建应用，并且有能力维护Linux或者FreeBSD，再加上成本的考虑，那么还是应该在Linux和 FreeBSD之间进行选择。可以说，现在Linux和FreeBSD这两个系统难分伯仲，很难说哪个一定比另外一个要优秀很多、能够全面的超越对手，应 该是各有所长。那么在选择的时候有一个因素就是企业的技术人员对于哪种系统更加的熟悉，这个熟悉一方面是系统管理方面，另外一方面是对于内核的熟悉，对内 核的熟悉对于性能调优和对操作系统进行定制剪裁会有很大的帮助。而应用全面的优化、提升性能也是从操作系统的优化开始的。
应用服务器
在确定了服务器的硬件、服务器的操作系统之后，下面我们来说说业务系统的构建。淘宝网有很多业务系统应用是基于JEE规范的系统。还有一些是C C++构建的应用或者是Java构建的Standalone的应用。那么我们要选择一款实现了JEE规范的应用服务器。我们的选择是JBoss Applcation Server。JBoss AS是RedHat的一个开源的支持JEE规范的应用服务器。在几年前，如果采用Java技术构建互联网应用或者企业级应用，在开源软件中的选择一般也就 是Apache组织的Tomcat、JBoss的 JBoss AS和Resin。严格意义上讲，Tomcat和Resin并不能算是一个应用服务器，他们是实现了部分J2EE规范的一个容器。而商业软件的选择就是 IBM的WebSphere和BEA的WebLogic。到了现在，除了JBoss AS外，Apache的Geronimo，Sun的Glassfish也都是很优秀的JEE应用服务器。也给现在的开发人员提供了更多的选择。具体对于目 前JEE应用服务器的比较。这边就不在赘述。
在应用服务器前端，我们采用了Web Server做了一次转发，我们选择的Web服务器是大名鼎鼎的Apache。几年前，Apache几乎是Linux系统上开源Web Server的唯一选择。那个时候虽然也有一些其他的开源的Web Server，但是从功能和稳定性上来说都无法和Apache相对。在今天来说，Lighty也会是一个非常好的选择。Lighty是一个非常轻量级、占 用内存资源也比较少的Web Server。虽然功能上没有Apache强大，但是在不少场景下，性能是非常出色、强于Apache的。而微软的IIS，就只能工作在Windows的 系统上了。并且使用IIS的话，基本上也就是选择了ISAPI、ASP或者ASP.NET进行Web应用的开发了。
数据库
说完了我们采用的操作系统、应用服务器、WebServer后，下面就来谈谈我们的数据库。在淘宝网的应用中，采用了两种关系型数据库管理系统。一 个是 Oracle公司的Oracle 10g，另外一个是Sun MySQL的MySQL。Oracle是一款优秀的、广泛采用的商业数据库管理软件。有很强大的功能和安全性，可以处理相对海量的数据。而MySQL是一 款非常优秀的开源数据库管理软件，非常适合用多台PC Server组成多点的存储节点阵列(这里我所指的不是MySQL自身提供的集群功能)，每单位的数据存储成本也非常的低廉。用多台PC Server安装MySQL组成一个存储节点阵列，通过MySQL自身的Replication或者应用自身的处理，可以很好的保证容错(允许部分节点失 效)，保证应用的健壮性和可靠性。可以这么说，在关系数据库管理系统的选择上，可以考虑应用本身的情况来决定。
一个互联网应用，除了服务器的操作系统，Web Server软件，应用服务器软件，数据库软件外，我们还会涉及到一些其他的系统，比如一些中间件系统、文件存储系统、搜索、分布式框架、缓存系统等等。 在淘宝网，这些系统都是自主开发的，没有采用目前商业的或者开源的产品。有些系统，会存在着一些开源的产品或者商业产品。但是，考虑到淘宝网自己的需求和 大并发量的压力，这些系统都选择了自主开发框架。
前面谈的都是系统级的产品，下面我们说说开发框架的使用。可能有朋友想问，作为一个如此大规模的网站，淘宝网的Web展现层采用的是什么框架，是怎 么实现的呢？曾经也有到淘宝的应聘者问过我这个问题，他问我说是不是用的 struts。我告诉他说不是的。其实淘宝网的Web展现层的框架用的不是struts，不是webwork，不是spring mvc等等。淘宝网的Web展现层的框架用的是集团内部自主开发的一套Web框架。这个框架能够解决一些其他Web框架不能解决的、在淘宝的应用中又会出 现并需要解决的问题。在淘宝的多个应用中，也采用了一些开源的框架，比如Spring、iBatis、jBPM、Hessian、Mina等等。这些开源 软件的采用为我们构建应用系统提供了很大的帮助。
采用开源软件构建系统，我想有两个很大的好处：
一个是降低成本。假设你有1000台应用服务器，如果你每台服务器上采用的不是JBoss AS或者其他开源的软件，而是使用商业的Oracle BEA的Weblogic或者IBM的WebSphere，那么为这1000台机器的应用购买License的费用是非常高的。
另外一个好处(我觉得最大的好处)是你可以看到软件的源码，你可以研究了解软件内部的工作过程、原理。这对于应用设计、开发、查错、优化都是非常有 帮助的。
淘宝网的开源观
对于开源软件的应用，有些人可能担心质量的问题，有些人可能担心软件本身发展更新的问题，等等。对于质量的问题，我想现在很多的开源软件尤其是一些 很著名的开源软件都有很完善的组织，有完善的开发、测试、发布流程。在一个新版本完成前，会有多次的测试版本发布，最后才是正式版。这和商业软件是一样 的。并且因为代码公开，反而更加的容易发现错误，提高质量。至于第二个问题，我想跟第一个问题一样，关键是组织和规划而不在是否开源，并且在很多著名的开 源软件背后，会有厂商在进行支持。软件本身的发展应该是不会成为问题的，不太会出现软件突然停止发展的情况。
在今后的发展中，我们还是会一如既往的关注开源软件的发展，也还会根据需要采用不同的开源软件。在选择一个开源产品的时候，我会考虑以下几点：
1. 这个软件目前的功能和它的RoadMap
2. 软件本身的架构
3. 该软件开发的活跃度
4. 该开源软件是否是遵守该领域内的国际规范的
5. 在同类产品中，要挑选有比较优势的。并且要考虑可能存在的移植代价。这个移植指的是采用了这款开源软件后现有系统的移植，或者是从这个开源软件到其他软件 的移植。
对于企业级系统、互联网应用来说，采用开源软件不仅可以降低成本，更重要的是能够真正了解软件的内部工作机制。还可以在现在的基础上进行增强和定 制，也能够从开源软件中借鉴到很多好的设计和实现。希望国内能有更多的企业在使用开源软件的同时，也能开源自身的一些软件，或者能够成为一些开源软件的贡 献者。而作为淘宝网，我们也会非常积极的参与到开源的活动中，也会努力为开源的发展做出我们应有的贡献。
May
23
经常有一些经验不足的PHP开发人员在Freenode的##php IRC频道上问问题。如果问题很琐碎，或者答案显而易见，或表现得象一个菜鸟，很快他们就会发现会受到如下一些回复的炮轰：“去读该死的手册去吧”，“好 好去学一学PHP吧”，“我们不是你个人的导师”或更直接的“你需要成为一个更好的PHP开发者”。但是，怎样才能成为一个更优秀的PHP开发者呢？在这 篇文章中，我列出了五种成为更优秀的PHP开发者的方法，让你在PHP开发过程中提高效率，用更少的代码来完成更多的事情。在PHP的开发过程中永远会有 更多的内容需要去学习,如新的核心函数，新的框架，新的设计模式，新的编码或文档规范等等。下面就是一些成为更优秀的PHP开发者的最佳途径。
1.阅读手册
没什么比阅读手册更值得强调的事了–仅仅通过阅读手册你就可以学习到很多东西。特别是有关字符串和数组有关的函数。就在这些函数里面包括许多有用的 功能，如果你仔细阅读手册，你会经常发现在以往的项目开发过程中，很多时候你在“重复发明轮子”，而实际上你只需要一个核心函数就可以完成相应的功能。手 册是你的朋友。
2.阅读程序源代码
有很多使用PHP开发的开源程序。为什么不去学习和借鉴呢？下载一份开源的PHP应用程序的源代码，仔细阅读它吧。也许越大的项目越值得去阅读，虽 然它们也许有更复杂的结构和系统，但也有更详细的解释文档。
3.学习一种框架
现在的框架如雨后春笋般纷纷出笼;它们中的大部分都是开源的，可以直接从网上下载，当然你要知道从哪里去下载。可以先选择一些主流的框架 — 网站http://www.phpframeworks.com里有 一个非常好的主流框架的列表。
4.研究
在PHP网站开发过程和讨论中你可能听说过很多术语。从OOP到MVC,KISS到DRY,YAML到INI,甚至REST到XML-RPC，也许 有数百个与你的工作直接相关的技术概念。你也许对它们有了一个基本的了解，但你真的了解它们到底是什么，对你有什么意义吗？花一点时间去做些实实在在的研 究吧。Wikipedia是从事这些研究的很好的起点。你一定会从中学到一些新知识的。
5.学习面向对象程序设计
这也许是上一个方法的继续，但是OOP比你想象的更重要。你真的了解PHP5中OOP是如何实现的吗？例如，你真的了解抽象类，接 口，“implements”关键字，静态方法和静态属性，访问修饰符“protected”吗？甚至许多有经验的开发人员都倒在这些问题的面前。如果你 能充分利用OOP的特征，你就可以节省很多的开发时间。
就是这些。要想成为PHP高手，这是五个最直接而又重要的的方法。
1.阅读手册
没什么比阅读手册更值得强调的事了–仅仅通过阅读手册你就可以学习到很多东西。特别是有关字符串和数组有关的函数。就在这些函数里面包括许多有用的 功能，如果你仔细阅读手册，你会经常发现在以往的项目开发过程中，很多时候你在“重复发明轮子”，而实际上你只需要一个核心函数就可以完成相应的功能。手 册是你的朋友。
2.阅读程序源代码
有很多使用PHP开发的开源程序。为什么不去学习和借鉴呢？下载一份开源的PHP应用程序的源代码，仔细阅读它吧。也许越大的项目越值得去阅读，虽 然它们也许有更复杂的结构和系统，但也有更详细的解释文档。
3.学习一种框架
现在的框架如雨后春笋般纷纷出笼;它们中的大部分都是开源的，可以直接从网上下载，当然你要知道从哪里去下载。可以先选择一些主流的框架 — 网站http://www.phpframeworks.com里有 一个非常好的主流框架的列表。
4.研究
在PHP网站开发过程和讨论中你可能听说过很多术语。从OOP到MVC,KISS到DRY,YAML到INI,甚至REST到XML-RPC，也许 有数百个与你的工作直接相关的技术概念。你也许对它们有了一个基本的了解，但你真的了解它们到底是什么，对你有什么意义吗？花一点时间去做些实实在在的研 究吧。Wikipedia是从事这些研究的很好的起点。你一定会从中学到一些新知识的。
5.学习面向对象程序设计
这也许是上一个方法的继续，但是OOP比你想象的更重要。你真的了解PHP5中OOP是如何实现的吗？例如，你真的了解抽象类，接 口，“implements”关键字，静态方法和静态属性，访问修饰符“protected”吗？甚至许多有经验的开发人员都倒在这些问题的面前。如果你 能充分利用OOP的特征，你就可以节省很多的开发时间。
就是这些。要想成为PHP高手，这是五个最直接而又重要的的方法。
May
23
每个人的学习方式不同，写这篇文章的目的是分享一下自己的学习过程，仅供参考，不要一味的用别人的学习方法，找对自己有用的学习方式
经常在某些论坛和QQ群里看到一些朋友会问“怎样才能学好PHP，怎样才能学好***语言 ”，但别人回答最多的是：从最“简单”的开始。
这个简单也许真的不简单，呵呵。下面我想分享一下自己学习的一些过程。先说些费话，语言组织能力差，说了不少费话，愿意看的就看，不要骂我就行。
其实学习一门新语言并不是太难，重要的是你有没有准备好去学好它，时间的长短和个人的能力和决心有关。黑客界也流行一句话就是“没有入侵不了的计算 机”，这句话大概的意思是说：如果你的技术比维护这台计算机的管理员更胜一筹，那么就能拿下这台计算机甚至能拿下这个管理员管理的所有计算机，如果技不如 人，只能继续学习超过对方。我说这些话的意思就是让准备学习陌生语言朋友一定要下决心去学习，只要你下了决心去学了，就一定能学好，千万不要半途而 废。（退一万步来说，即使是没学好，但你懂的必然比别人多）
了解什么是最简单:
1、网页的基本构成就是html代码,所以必须熟悉HTML/CSS/JS等基本元素
2、熟悉PHP语法，了解PHP和HTML的运行方式，学习将PHP与HTML结合完成简单页面
PHP手册是比较好的入门老师
影响学习进度和程序强大是否的几个可能因素：
1、记忆力
一门语言的强大是否，应该看它的函数库和代码执行效率。每门语言都是有自己强大的函数库，要学好它，就必须得花很多的时间去记忆，良好的记忆力能使 学习达到事半功倍的效果。
2、数学和逻辑思维
这个当然不是绝对影响，因为看开发项目的复杂程度。小的项目不需要太多的数学和逻辑思维能力，但如果是开发类似于财务或大量运算相关项目，这一点就 是非常重要了。
3、有其它语言的基础
“一通百通”，这句话的道理也是不容置疑。都说有C语言基础的人，学习PHP比较容易，我没学过C语言，所以不知道这句话的效果
4、多看别人写的代码
学习别人的长处，补自己的不足，当然不完全为这个我始终相信：一个有组织的团队写出来的程序不会比个人差我PHP入门就是从看代码开始的，我喜欢看 别人写的代码 。(入门是从disucz,PHPWind和国外的phpbb看起，还有就是目前最流行的开源BLOG程序)，我尽可能的收集网络上的 PHP开源程序，到目前为止，我收集并下载的PHP开源程序有2GB大小,包括BBS，BLOG，CMS等。我下载并不是为了收藏他们，是学习他们的编程 方式和实现方法,如果自己想实现的功能不知道怎么去实现，我就会学习他们的实现方法，并不是抄袭代码，最终结果是想通过学习，将技术变成属于自己的ASP 我也是以同样的方式学习的(动易和讯的程序及其它ASP开源程序)
5、实践
理论固然重要，但实践必不可少。你理论知识再好，如果不实践，就不能看到理论所产生的结果或效果，并不能使你的记忆深刻，所以不能纸上谈兵
6、恒心
广告不是有句话是这样说的么：“世界上最高的山是自己”，这句话相信朋友们都能理解
过自己这关，其它的都好办
7、找对自己有用的学习方式
这条可以参照4，我的入门是从看代码开始可能有朋友会问：“一开始看那些强大的代码，你能看懂么？”我的学习方式是从“使用”找“学函数”：PHP 的函数太多，短时间不可能记住所有的函数，因为我相信，一个大的项目肯定会使用常见和必须的函数，找到这些函数，才会有重点的学习这些函数，难道你能说写 BBS的函数会写BLOG用的函数少么？难道会写BBS还不会写BLOG么？找对学习方式是要经过多种学习方式的尝试，所以这个只有自己把握，毕竟每个人 的学习方式不一样
8、尽可能的找视屏教程看
别人说十句，还不如一个操作看的明白，这个相信朋友们都有体会吧
9、从项目开始
一定要”逼”自己从写项目开始。任何一个高手的“成长”都是要经历一个过程，这个过程是一步步走过来的，来之不易很多朋友学习PHP的第一个作品几 乎都是“留言簿”，因为是最简单的程序了会写留言簿，也并不能完全代表你已经入门了，也并不代表就会了PHP，我自己开始想以一个“网络书签”作为自己的 第一个作品，但写了基本功能后就没继续了，感觉没多大意思。现在写一个完全正确针对企业的CMS系统，包括针对企业的一些常用功能，我想以这个作为自己 PHP入门的第一个作品
10、了解并学习和PHP有关的技术
真正的高手必须得学习和PHP关联的技术，要想学好PHP，就必须得学习数据库，PHP+MYSQL被认为是“黄金搭档”所以你必须得接触 MYSQL或你认为比较好的数据库，开始设计比较”合理”的数据库，这里的合理就比较广泛了，包括数据库优化和查询优化等等
最后想说的是：“不要依靠别人”没人愿意理会一个新手的提问，因为新手提问的在他们眼里太简单，不想去解释女性朋友很流行一句话是“男人靠的住，母 猪会上树” 引用这句话没别的意思，只是让朋友们知道这句话的意思
还想说的是：“珍惜别人回答的次数”人的忍耐都是有限度的，一定要珍惜这个限度，不要什么问题都去问，有些问题自己花点时间能找到答案的也去问，每 问一次，别人的耐心就减去一次，等你真正需要帮助的时候，正好是别人不愿意回答你的时候，可以想像一下，你失去的太多了
建议的是：“有问题？baidu一下”相信朋友们都已经注意到了，你问的问题，在搜索引擎里都能找到相关的提问，并且有详细的解决方案，你可以使用 搜索引擎来找到自己的答案，何必去问别人呢
目前最大的中文搜索引擎是 baidu.com ,全球的google,当然还有其它的搜索引擎，一个找不到，多试几个，除非你的问题是第一个提问的 ，那么你是幸运的，也可能是你“长相”问题，呵呵，说笑的，不要介意，不过这句话倒是挺流行
祝正准备入门的PHP的朋友能找到适合自己的学习方式，早日成功！！！
经常在某些论坛和QQ群里看到一些朋友会问“怎样才能学好PHP，怎样才能学好***语言 ”，但别人回答最多的是：从最“简单”的开始。
这个简单也许真的不简单，呵呵。下面我想分享一下自己学习的一些过程。先说些费话，语言组织能力差，说了不少费话，愿意看的就看，不要骂我就行。
其实学习一门新语言并不是太难，重要的是你有没有准备好去学好它，时间的长短和个人的能力和决心有关。黑客界也流行一句话就是“没有入侵不了的计算 机”，这句话大概的意思是说：如果你的技术比维护这台计算机的管理员更胜一筹，那么就能拿下这台计算机甚至能拿下这个管理员管理的所有计算机，如果技不如 人，只能继续学习超过对方。我说这些话的意思就是让准备学习陌生语言朋友一定要下决心去学习，只要你下了决心去学了，就一定能学好，千万不要半途而 废。（退一万步来说，即使是没学好，但你懂的必然比别人多）
了解什么是最简单:
1、网页的基本构成就是html代码,所以必须熟悉HTML/CSS/JS等基本元素
2、熟悉PHP语法，了解PHP和HTML的运行方式，学习将PHP与HTML结合完成简单页面
PHP手册是比较好的入门老师
影响学习进度和程序强大是否的几个可能因素：
1、记忆力
一门语言的强大是否，应该看它的函数库和代码执行效率。每门语言都是有自己强大的函数库，要学好它，就必须得花很多的时间去记忆，良好的记忆力能使 学习达到事半功倍的效果。
2、数学和逻辑思维
这个当然不是绝对影响，因为看开发项目的复杂程度。小的项目不需要太多的数学和逻辑思维能力，但如果是开发类似于财务或大量运算相关项目，这一点就 是非常重要了。
3、有其它语言的基础
“一通百通”，这句话的道理也是不容置疑。都说有C语言基础的人，学习PHP比较容易，我没学过C语言，所以不知道这句话的效果
4、多看别人写的代码
学习别人的长处，补自己的不足，当然不完全为这个我始终相信：一个有组织的团队写出来的程序不会比个人差我PHP入门就是从看代码开始的，我喜欢看 别人写的代码 。(入门是从disucz,PHPWind和国外的phpbb看起，还有就是目前最流行的开源BLOG程序)，我尽可能的收集网络上的 PHP开源程序，到目前为止，我收集并下载的PHP开源程序有2GB大小,包括BBS，BLOG，CMS等。我下载并不是为了收藏他们，是学习他们的编程 方式和实现方法,如果自己想实现的功能不知道怎么去实现，我就会学习他们的实现方法，并不是抄袭代码，最终结果是想通过学习，将技术变成属于自己的ASP 我也是以同样的方式学习的(动易和讯的程序及其它ASP开源程序)
5、实践
理论固然重要，但实践必不可少。你理论知识再好，如果不实践，就不能看到理论所产生的结果或效果，并不能使你的记忆深刻，所以不能纸上谈兵
6、恒心
广告不是有句话是这样说的么：“世界上最高的山是自己”，这句话相信朋友们都能理解
过自己这关，其它的都好办
7、找对自己有用的学习方式
这条可以参照4，我的入门是从看代码开始可能有朋友会问：“一开始看那些强大的代码，你能看懂么？”我的学习方式是从“使用”找“学函数”：PHP 的函数太多，短时间不可能记住所有的函数，因为我相信，一个大的项目肯定会使用常见和必须的函数，找到这些函数，才会有重点的学习这些函数，难道你能说写 BBS的函数会写BLOG用的函数少么？难道会写BBS还不会写BLOG么？找对学习方式是要经过多种学习方式的尝试，所以这个只有自己把握，毕竟每个人 的学习方式不一样
8、尽可能的找视屏教程看
别人说十句，还不如一个操作看的明白，这个相信朋友们都有体会吧
9、从项目开始
一定要”逼”自己从写项目开始。任何一个高手的“成长”都是要经历一个过程，这个过程是一步步走过来的，来之不易很多朋友学习PHP的第一个作品几 乎都是“留言簿”，因为是最简单的程序了会写留言簿，也并不能完全代表你已经入门了，也并不代表就会了PHP，我自己开始想以一个“网络书签”作为自己的 第一个作品，但写了基本功能后就没继续了，感觉没多大意思。现在写一个完全正确针对企业的CMS系统，包括针对企业的一些常用功能，我想以这个作为自己 PHP入门的第一个作品
10、了解并学习和PHP有关的技术
真正的高手必须得学习和PHP关联的技术，要想学好PHP，就必须得学习数据库，PHP+MYSQL被认为是“黄金搭档”所以你必须得接触 MYSQL或你认为比较好的数据库，开始设计比较”合理”的数据库，这里的合理就比较广泛了，包括数据库优化和查询优化等等
最后想说的是：“不要依靠别人”没人愿意理会一个新手的提问，因为新手提问的在他们眼里太简单，不想去解释女性朋友很流行一句话是“男人靠的住，母 猪会上树” 引用这句话没别的意思，只是让朋友们知道这句话的意思
还想说的是：“珍惜别人回答的次数”人的忍耐都是有限度的，一定要珍惜这个限度，不要什么问题都去问，有些问题自己花点时间能找到答案的也去问，每 问一次，别人的耐心就减去一次，等你真正需要帮助的时候，正好是别人不愿意回答你的时候，可以想像一下，你失去的太多了
建议的是：“有问题？baidu一下”相信朋友们都已经注意到了，你问的问题，在搜索引擎里都能找到相关的提问，并且有详细的解决方案，你可以使用 搜索引擎来找到自己的答案，何必去问别人呢
目前最大的中文搜索引擎是 baidu.com ,全球的google,当然还有其它的搜索引擎，一个找不到，多试几个，除非你的问题是第一个提问的 ，那么你是幸运的，也可能是你“长相”问题，呵呵，说笑的，不要介意，不过这句话倒是挺流行
祝正准备入门的PHP的朋友能找到适合自己的学习方式，早日成功！！！
May
23
你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原 则看成警铃，若违背了其中的一条，那么警铃就会响起 。 —– Arthur J.Riel
(1)所有数据都应该隐藏在所在的类的内部。
(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。
(3)尽量减少类的协议中的消息。
(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。
(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。
如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。
(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。
(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。
(8)类应该只表示一个关键抽象。
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 .
(9)把相关的数据和行为集中放置。
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。
(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。
朝着稳定的方向进行依赖.
(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。
(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。
(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。
规划一个接口而不是实现一个接口。
(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。
(15)对包含太多互不沟通的行为的类多加小心。
这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。
(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。
(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。
(18)从你的设计中去除不需要的类。
一般来说，我们会把这个类降级成一个属性。
(19)去除系统外的类。
系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。
(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存 在或者尚未发现的某个类中。
(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。
(22)尽量减少类的协作者的数量。
一个类用到的其他类的数目应当尽量少。
(23)尽量减少类和协作者之间传递的消息的数量。
(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。
(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。
(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。
(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。
(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。
当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。
(29)让系统功能在窄而深的继承体系中垂直分布。
(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但 不是必须如此。
(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。
(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。
(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。
(34)类必须知道它包含什么，但是不能知道谁包含它。
(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。
(36)继承只应被用来为特化层次结构建模。
(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。
(38)基类中的所有数据都应当是私有的，不要使用保护数据。
类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。
(39)在理论上，继承层次体系应当深一点，越深越好。
(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。
(41)所有的抽象类都应当是基类。
(42)所有的基类都应当是抽象类。
(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。
(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。
(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。
(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。
(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。
(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。
(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。
(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。
(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。
(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。
(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。
(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。
(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。
(56)只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是不是派生类的一部分？
(57)如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。
(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。
(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。
(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。
(61)不要绕开公共接口去修改对象的状态。
(1)所有数据都应该隐藏在所在的类的内部。
(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。
(3)尽量减少类的协议中的消息。
(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。
(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。
如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。
(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。
(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。
(8)类应该只表示一个关键抽象。
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 .
(9)把相关的数据和行为集中放置。
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。
(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。
朝着稳定的方向进行依赖.
(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。
(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。
(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。
规划一个接口而不是实现一个接口。
(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。
(15)对包含太多互不沟通的行为的类多加小心。
这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。
(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。
(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。
(18)从你的设计中去除不需要的类。
一般来说，我们会把这个类降级成一个属性。
(19)去除系统外的类。
系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。
(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存 在或者尚未发现的某个类中。
(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。
(22)尽量减少类的协作者的数量。
一个类用到的其他类的数目应当尽量少。
(23)尽量减少类和协作者之间传递的消息的数量。
(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。
(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。
(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。
(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。
(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。
当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。
(29)让系统功能在窄而深的继承体系中垂直分布。
(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但 不是必须如此。
(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。
(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。
(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。
(34)类必须知道它包含什么，但是不能知道谁包含它。
(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。
(36)继承只应被用来为特化层次结构建模。
(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。
(38)基类中的所有数据都应当是私有的，不要使用保护数据。
类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。
(39)在理论上，继承层次体系应当深一点，越深越好。
(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。
(41)所有的抽象类都应当是基类。
(42)所有的基类都应当是抽象类。
(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。
(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。
(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。
(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。
(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。
(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。
(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。
(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。
(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。
(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。
(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。
(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。
(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。
(56)只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是不是派生类的一部分？
(57)如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。
(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。
(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。
(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。
(61)不要绕开公共接口去修改对象的状态。
