正好我一个月前看到一个视频，这个演讲视频还比较著名，这个演讲者是Exceptional C++ 和 C++ Coding Standards 的作者，还是ISO C++ 委员会的Chair，C++/CLI首席架构师，还是Microsoft的软件架构师，他叫Herb Sutter，他的这个演讲视频是 C++ and Beyond 2011上的一次公开演讲，题目是——Why C++? （如果你觉得那里的视频比较慢，你可以看优酷上的视频）（英文听力好的同学可以看一样，因为都没有中文字幕）

我觉得这篇文章就足够可以说明很多问题了，所以，我把Herb的演讲幻灯片截了几页放到这里，并做上一些注释，算是一个演讲内容摘要吧。

1） 为什么C++？因为 Performance per $，也就是说performance 就是钱，这个分成三个方面，

• 耗电，芯片的耗电量，移动设备的耗电量，家用电脑的耗电量都和钱有关系。
• 资源，家用电脑和移动设备上的处理器资源有限，因为要让一般消费者买的起。
• 体验，在更小的设备上会有更好的体验，有更好的体验就可以挣更多的钱。

移动设备上的耗电量相信用过智能手机的人都知道吧，Android手机的耗电量实在是太大了。就算是iPhone在开启Wifi和3G的情况下耗电量也很快。

2）C++的进化分成三个时代：

• 1979 – 1989：研究C的对象能力。主要是为C++做准备
• 1989 – 1999：C++成了主流。
• 1999 – 2009：Coffee-based语言（Java, .NET）出现了，极大的提高了开发生产力。

对于第三个时代，Herb说了很多，他说这个并没有什么错，因为这个时候我们非常关注开发的生产力，这个非常重要，这就是为什么C++一下就失去优势的地方。但是是否这些Coffee-Based的语言可以做任重要的事呢？不行，很多时候，这是一个Trade-Off的事，也就是生产力不是免费的是需要你用别的东西去交换的。

3）第四个时期。

Herb认为，2009-2019是第四个时期，因为我们又喜欢Native Code了，C++从被驱逐后又被请回来了。因为网站的性能越来越是个问题，移动端的设备非常流行。但主要是因为Performance就是钱，因为前面的三个因素，性能影响的是dollar，不尊重性能的公司都会发现花钱的速度太快了。（比如去年大家热炒的京东促销和12306.cn的问题，12306给整个社会造成了巨大的金钱浪费）

Herb把这个时期比做 The Return of the King。（指环王的第三部：王者归来） 性能为王！

这就好像我在“软件开发的三重门”里说的，开垦时代需要的是快和生产力，而开垦完后就得保证其稳定性。

4）Herb还给了一张幻灯片问，“The World is built on ….”，后面例出了多个语言。然后Herb说，世界是由C和C++构成的。

5）Herb给了一张表格，这张表可相当形像。如果把我们的对编程语言的需求总结为四个：效率，灵活，抽象，生产率。那么，C语言玩的是前两个，而C++玩的是前三个，Java和C#玩的是后两个（抽象和生产率）

任保一种设计都不可能让你什么都要的，这就是Trade-Off——什么事都需要交换的。

6）Herb举了一个微软内的例子，用C++ 和 ATL 来开发IE工具条的报告，意思是你可以用脚本在IE的工具条上加按钮，但是作者建议使用C++，因为用.NET或是脚本有重大的limitation，尤其是性能上的问题。

7）接下来，我们来看看移动设备。

下图中，第一个是iOS，第二个是Android，第三个是WinPhone。Herd说了几个事：

a）比Web APP，人们更喜欢Native的APP，这个在用移动设备上可以得到验证。

b）iOS也好，Android也好，WinPhone也好，他们不是在搞操作系统，而是在搞应用，为的是让智能手机更好。手机就是一个App。

c）这三个手机在第一版出来时都不支持C++，而第二版出来时都支持C++了。因为他们要兼顾性能和一定程度上的开发效率。WinPhone还没有到第二版，让我们拭目以待。（我以前写过一篇调侃Android支持C++开发的文章，这也只是一年前的事，说明C++全面回归了）

8）如果你还是不相信的话，我们可以看看为什么Apple和Google都在搞C++的编译器，因为他们觉得g++性能不行。所以，基于LLVM的编译器正在领导潮流，因为我们关注Natvie Code的性能优化。

9）接下来，Herb说了一下数据中心，你知道数据中心最花钱的是什么吗？三个事：

• 57% 花在了硬件上。
• 18% 花在了配电和降温上。
• 13% 花在了耗电上。

88%的钱花在了硬件和电力上。这可是很大一笔费用啊。（还有人说硬件比软件便宜吗？）我记得我上一个公司的数据中心每年要花的电费就在百万美元以上。

10）昨天在微博上有个笑话，说是某咨询师要求程序员把代码打印出来走查，程序员问是不是要用彩打？哈哈。我说，这至少不环保嘛。消耗太大了。是的，C++是可以省电的，以及于C++之父都在YouTube 说C++是可以减轻全球变暖的问题。哇，C++开始真正造福人类了。

11）我还需要重温一下老大的这句话——

My contribution to the fight against global warming is C++’s efficiency: Just think if Google had to have twice as many server farms! Each uses as much energy as a small town. And it’s not just a factor of two… Efficiency is not just running fast or running bigger programs, it’s also running using less resources.

Bjarne Stroustrup, June 2011

最后一句说的非常好！效率不仅仅只是跑得，跑得多，更是可以使用更少的资源。

12）下面让我们再来看一张表，一张把钱投到哪里的表格，这样我们可以看到一些趋势。

• 70年代80年代，资源不够，主要是把钱投在性能上。
• 80年代到90代，主要是90年代开始有一半的投次到了抽象和生产率上。
• 00年代，完全都在抽象和生产率上。
• 10年代，80%的钱都要回头来解决性能问题。这就是C/C++的王者归来。

13）当然，不是C++不注重 开发效率，看看C++0X的标准引入了多少东西我们就知道了。但是本质上，C++还是致力于性能和抽象的完全平衡。

那么，我们还会觉得C++要被淘汰了，不适合进入了吗？看完这个演讲，你应该有答案的。

后面讲了C++的文艺复兴，你可以在Google 搜索 “C++ Renaissance”看看。另外，该视频的讲议可以在这里下载。

（全文完）

您可能也喜欢：
我有一个Hello World的C++程序编译不过	恐怖的C++语言	如何加密/混乱C源代码	6个变态的C语言Hello World程序	如何学好C++语言
无觅

相关文章

• 2012年01月16日 -- 由12306.cn谈谈网站性能技术
• 2011年11月29日 -- 一些有意思的算法代码
• 2011年11月01日 -- 深入理解C语言
• 2011年10月14日 -- 那些曾伴我走过编程之路的软件
• 2011年09月20日 -- 一些文章和各种资源
• 2011年08月26日 -- C语言中史上最愚蠢的Bug
• 2011年08月19日 -- C++11 中值得关注的几大变化（详解）

前言

这篇文章必然是通过我的个人经历来写的。所以，我先说说个人经历吧。我的经历基本分成三个阶段。

第一阶段：我 刚毕业时在家乡的某银行工作，做些银行的业务系统，还搞些网络，电子邮件系统，OA什么的，因为大四的时候在老师的公司里实习，银行里的人际关系太复杂， 而且技术都包给了产商，所以在银行的每一天都觉得不能适应里面的工作环境。两年后离职，单位分的房也不要了，直接去了上海，在上海呆了两年，本来想做互联 网的，但是泡沫来了，最终去了一家做系统集成的国企公司还是继续做银行业务。这四年来，主要解决的都是一些业务上的问题，银行里的会计业务，OA业务，国 际业务，中间对公业务都非常地复杂，而且因为当时的软件开发相当的不规范，所以基本上是在一种比较混乱的状态下度过的，而银行方面又很强势，所以，这段时 间主要是做业务。所以，技术上主要是积累了如何使用那些技术。C+/Java， Windows编程，Unix编程，网络编程主要是这段时间学的，看了太多的书（我大学课程里没有C++和Java，也没有Windows/Unix和网 络编程，所以，只能拼命地看书和自学）。

第二阶段：然后，我来了北京，到了一家做分布式计算系统的公 司，整天和一个高性能技术高可用性的企业级的集群式的软件产品打交道（这家公司去年被IBM收购了），在这家公司把Windows/Unix和网络编程有 了更深入的了解，对我长进比较大的是明白了怎么做一个性能高，可用性高的集群式的系统，天天和底层打交道，干了4年多。然后去了一家金融信息公司，这家金 融公司主要做全球的金融信息数据处理，而我主要还是做核心数据发布系统的性能调优的项目，金融数据的实时性要求的高，数据量非常地大，高可用性要求得高， 得想尽一切办法省网络带宽，增加系统性能，还要保持高的可用性，不当机，不丢包。又干了4年多，入职的时候从国外接过来两个系统，其性能单机每秒可处理 120K message，我走的时候，我和团队把其优化到了每秒1.4M messages 的吞吐，另一个系统，从接手时的100k message/s优化到了500k message/s。这八年多的时候，全是在和这些高计算高性能的项目打交量，几乎没有什么业务，都是纯技术，积累到了很多和性能有关的高并发高计算系统 架构级的知识。

第三阶段：两 年前来到了现在的做电子商务的互联网公司，还是在做一个数据处理量很大的业务系统，因为要干的是要把电子商务全球化的东西。但是，因为电子商 务的特殊性，必需要去兼顾业务的特点，而且在这家电商公司，耳读目染了很多有趣的业务难题，比如，库存计划，配送优化，等等。虽然很多东西还不明白，但发 现，用技术来解决业务难题真是太有意思了。

我的这三个阶段，第一个阶段花了4年，第二个阶段花了8年，第三阶段刚刚开始2年不到，有时候我也去别的公司讲课，所以，我很有幸经历了中国软件开发的进化过程。我的经历可以说是中国软件行业进程的一个缩影，而我把这三个阶段称为——软件开发的三重门。它们分别是：

• 业务功能 – 粗放地开垦
  
• 业务性能 – 扩大化生产
  
• 业务智能 – 精耕细作
  

之所以加上“业务”二字，是因为我以为计算机是一个工具，其用来解决实际问题，所以，什么都离不开业务，就算是性能优化也一样，通过之前那篇“12306.cn的性能优化”中的“业务分析”段落，我们可以知道业务的不同，系统的难度和解决方法就可以不同。所以，我们总是用技术在解决业务问题。业务的形态对软件的开发有决定性的作用。

下面让我具体描述一下。

一重门：业务功能

这 是软件开发的第一重门，也就是掌握可以实现业务功能的技术。通常分成三块：语言+系统+数据处理。在这个阶段，主要是能掌握各种技术，比如：开发用的各种 工具（如：IDE，XUnit，Debugger，等），各种代码库和框架（如：C++的STL，ACE，Boost，等，Java的 Spring，Hibernate等），各种系统知识（如：Windows API，Unix/Linux API，TCP/IP，Socket，多线程多进程间的同步、互斥，并发安全，还包括Web平台，移动平台，等等），还需要掌握数据处理的知识（如：数据 结构，基本算法，数据库设计，数据库引擎 ，SQL等），等等……

这个阶段主要是把这些不同的技术组织成可以实现业务功能的解决方案。重点是能掌握和使用技术。很多流程和方法论的东西基本上就在这一重门里。这重门主要解决的是业务实现问题。

二重门：业务性能

业务的功能搞定了以后，就是业务的性能问题了。搞定功能并不难，搞定性能是有点技术含量的事。有句话不是那么说的吗——每个人都可以搞一个网站出来，但不是每个人都能搞出能支持百万级访问量的网站。但是，我看到很多技术团队或是工程师脱离了业务，只单纯地搞性能，比如：单台服务器支持10万个TCP链接的并发，等等。这些东西虽然在技术上有点意思，但是没有业务的环境，也只能是自娱自乐了。

我们可以看到一些企业开始注重这个问题了，性能问题也是最近被大家讨论得最多的问题，京东商场的性能问题，12306的性能问题，等等。

当然，所谓性能不并单单指系统的吞吐力，还指系统运行时的总体性能，比如，系统安全性能，易用性能，系统的Accessbility的性能，系统的扩展性性能，等等，就像是前段时间“Web开发中需要注意的问题”一文中谈到的那些事一样。这表明着你对系统的全面和深入的了解。

在 这个阶段，需要对业务模型，数据流，业务流，系统架构，算法，和各种技术有深入的了解，要了解到本质上来。比如，在第一重门中，我们只需同要知 道，Java有同步关键字，在这一重门中，我们还要知道同步或互斥对性能的巨大伤害性，在第一重门中，我们只需要知道STL中的智能指针或是STL的用 法，这一重门中，我们还要知道智能指针中的refcnt的同步加锁对性能的损害，还需要知道STL中容器的size()方法在某些时候是性能很差的。在第 一重门中，我们需要知道hash表的效率，在这一重门中，我们还需要知道hash表的碰撞问题。

最重要的是，在这重门重点是软件的设计问题。你需要有足够多的经验能比较不同设计方案的优缺点，比如TCP和UDP，同步和异步，epoll和select，push和pull，水平扩展的各种方案…… 还记得本站的那篇“程序员的谎谬之言还是至理名言”，广度是你深度的副产品。所以，这重门是看你的技术视野有多深有多广。

三重门：业务智能

这 重门可能是最难的一重门了，如果你能进到这重门里，你应该是科学家级的程序员了。让你有智能的业务，这个事可能是顶级的技术难题了。第一和第二重门都不算 难，这重门是最难的。参看Amazon的个性化推荐系统，或是Google搜索引擎的结果个性化推荐等等（比如我输入“黑天鹅”关键字，你怎么知道我要找 的是动物，电影，音乐，还是本书？怎么让搜索出来的结果排名即公正又可个性？），你就知道，用技术来解决这种类似的问题难度可想而知，不然就不会出现如 Hadoop之类的技术了。

我再举两个这重门里的业务方面的例子。

• 一个例子是关于库存计划的，需要像天气预报一样 预测未来的销售量从而决定库存，所以，最简单的做法是，监测各个商品的销售统计，然后看一下最近的销售趋势，还要看一下往年的销售趋势（因为某些节假日会 是一个高峰期），还要分析一下大众的喜好变化，比如，在某影评网站上的某电影的热度其会告诉我哪个电影的DVD要滞销了，得打折卖，哪个电影的DVD要畅 销了，得多进货了。还可能需要监控新闻评论，比如某权威人士推荐了某个商品，那么我得赶快进货了。等等。这完全就是一门科学。

• 还有一个例子是配送问题。我有一辆卡车要处理我仓库和配送站间的物流问题，我需要找到一条最经济的路线来在有限的时间内处理最多的物流。这个不是最短路径问题，这是个计划统筹学的东西。也是一门科学。

还有近期“方韩之争”里有很多人来分析文章相似度的技术，这些东西都属于三重门里的东西。

到了这重门里，可能技术反而不是重要的了，而是数学模型。这重门里主要是业务模型，数据模型和算法问题。这些东西和你的业务模型密切相关。能解决这样的问题，是真正的大牛。对于我来说，可能是高山仰止了。

后记

通过上面的说明，我们可以看到下面这些东西，

• 我的那篇“程序员技术练级攻略”里的东西只能让我们最多达到1.1 到 1.2重门。

• 一重门像是开垦荒地，二重门像是扩大生产，三重门像是精耕细作。

• 一重门（业务实现）里聚集着大量的劳动密集型的企业，劳动密集型的企业通常都需要流程和方法论。敏捷过程改进这类的东西只在一重门里。

• 二重门和三重门里只有少数不多的技术型的公司。这类的公司通常非常注重技术，并且是企业文化是工程师的文化。

• 三重门里可以产生的创新和那些可以用来改变世界的技术。

• 国内现在的情况是，一重门优化阶段 + 二重门的学习阶段。三重门里似乎还没有什么见术。不过，我看到一些公司已在尝试三重门的东西了。

• 作为技术人员的你，如果你想跟上时代，让自己有价值的话，你至少要达到二重门。

• 因 为国内的技术环境等不良因素，导致大量的程序员在一重门的时候就已经失去信心，或被大浪淘沙淘掉了，所以，二重门里的程序员比较少了，但是随着年轻的一代 和技术的日趋成熟，也会慢慢多起来的，我现在已经看到这个趋势了。而三重门里的程序员成了稀缺的大熊猫。因为大量的二重门程序员干到那个时候都转管理了。

我的这些言论不一定对，但希望能让大家有启发，有所思考。

注：本来这篇文章的标题想取成“程序员要解决的三种问题”， 但是因为过年都在关注 “方韩之争”，所以，干脆取成了这个名字。你可以认为我比较调皮，也可以认为我爱ZB，还可以认为我标题党，反正，请随意理解。（这篇文章是我的自己写 的，没有代笔，因为你一定会在这篇文章中看到属于我的用五笔打出来的错别字，当然，我无法自证，哈哈）

（转载时请注明作者和出处，请勿用于商业用途）

您可能也喜欢：
漫画：程序员的一生	程序员的八个级别	程序员因为女孩而美丽！	我是怎么招聘程序员的	程序员惯用的解释(Top 25)
无觅

相关文章

• 2012年01月04日 -- 程序员因为女孩而美丽！
• 2011年12月30日 -- 一个女程序员的故事
• 2011年12月20日 -- 三个事和三个问题
• 2011年11月15日 -- 来信， 创业 和 移动互联网
• 2011年10月25日 -- 多些时间能少写些代码
• 2011年10月20日 -- Stay Hungry, Stay Foolish ！！
• 2011年09月21日 -- 如果你看不见你还能编程吗？

业务

任何技术都离不开业务需求，所以，要说明性能问题，首先还是想先说说业务问题。

• 其一，有人可能把这个东西和QQ或是网游相比。但我觉得这两者是不一样的，网游和QQ在线或是登录时访问的更多的是用户自己的数据，而订票系统访问的是中心的票量数据，这是不一样的。不要觉得网游或是QQ能行你就以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。

• 其二，有人说春节期间订火车的这个事好像网站的秒杀活动。的确很相似，但是如果你的思考不在表面的话，你会发现这也有些不一样。火车票这个事，还有很多查询操作，查时间，查座位，查铺位，一个车次不 行，又查另一个车次，其伴随着大量的查询操作，下单的时候需要对数据库操作。而秒杀，直接杀就好了。另外，关于秒杀，完全可以做成只接受前N个用户的请求（完全不操作后端的任何数据， 仅仅只是对用户的下单操作log），这种业务，只要把各个服务器的时间精确同步了就可以了，无需在当时操作任何数据库。可以订单数够后，停止秒杀，然后批量写数据库。火车票这个岂止是秒杀那么简单。能不能买到票得当时告诉用户啊。

• 其三，有人拿这个系统和奥运会的票务系统比较。我觉得还是不一样。虽然奥运会的票务系统当年也一上线就废了。但是奥运会用的是抽奖的方式，也就是说不存在先来先得的抢的方式，而且，是事后抽奖，事前只需要收信息，事前不需要保证数据一致性，没有锁，很容易水平扩展。

• 其四，订票系统应该和电子商务的订单系统很相似，都是需要对库存进行：1）占住库存，2）支付（可选），3）扣除库存的操作。这个是需要有一致性的检查的，也就是在并发时需要对数据加锁的。B2C的电商基本上都会把这个事干成异步的，也就是说，你下的订单并不是马上处理的，而是延时处理的，只有成功处理了，系统才会给你一封确认邮件说是订单成功。我相信有很多朋友都收到认单不成功的邮件。这就是说，数据一致性在并发下是一个瓶颈。

• 其五，铁路的票务业务很变态，其采用的是突然放票，而有的票又远远不够大家分，所以，大家才会有抢票这种有中国特色的业务的做法。于是当票放出来的时候，就会有几百万人甚至上千万人杀上去，查询，下单。几十分钟内，一个网站能接受几千万的访问量，这个是很恐怖的事情。据说12306的高峰访问是10亿PV，集中在早8点到10点，每秒PV在高峰时上千万。

多说几句：

• 库存是B2C的恶梦，库存管理相当的复杂。不信，你可以问问所有传统和电务零售业的企业，看看他们管理库存是多么难的一件事。不然，就不会有那么多人在问凡客的库存问题了。（你还可以看看《乔布斯传》，你就知道为什么Tim会接任Apple的CEO了，因为他搞定了苹果的库存问题）

• 对于一个网站来说，浏览网页的高负载很容易搞定，查询的负载有一定的难度去处理，不过还是可以通过缓存查询结果来搞定，最难的就是下单的负载。因为要访问库存啊，对于下单，基本上是用异步来搞定的。去年双11节，淘宝的每小时的订单数大约在60万左右，京东一天也才能支持40万（居然比12306还差），亚马逊5年前一小时可支持70万订单量。可见，下订单的操作并没有我们相像的那么性能高。

• 淘宝要比B2C的网站要简单得多，因为没有仓库，所以，不存在像B2C这样有N个仓库对同一商品库存更新和查询的操作。下单的时候，B2C的 网站要去找一个仓库，又要离用户近，又要有库存，这需要很多计算。试想，你在北京买了一本书，北京的仓库没货了，就要从周边的仓库调，那就要去看看沈阳或 是西安的仓库有没有货，如果没有，又得看看江苏的仓库，等等。淘宝的就没有那么多事了，每个商户有自己的库存，库存分到商户头上了，反而有利于性能。

• 数据一致性才是真正的性能瓶颈。有 人说nginx可以搞定每秒10万的静态请求，我不怀疑。但这只是静态请求，理论值，只要带宽、I/O够强，服务器计算能力够，并支持的并发连接数顶得住10万TCP链接的建立 的话，那没有问题。但在数据一致性面前，这10万就完完全全成了一个可望不可及的理论值了。

我说那么多，我只是想从业务上告诉大家，我们需要从业务上真正了解春运铁路订票这样业务的变态之处。

前端性能优化技术

要解决性能的问题，有很多种常用的方法，我在下面列举一下，我相信12306这个网站使用下面的这些技术会让其性能有质的飞跃。

一、前端负载均衡

通过DNS的负载均衡器（一般在路由器上根据路由的负载重定向）可以把用户的访问均匀地分散在多个Web服务器上。这样可以减少Web服务器的请求负载。因为http的请求都是短作业，所以，可以通过很简单的负载均衡器来完成这一功能。最好是有CDN网络让用户连接与其最近的服务器（CDN通常伴随着分布式存储）。（关于负载均衡更为详细的说明见“后端的负载均衡”）

二、减少前端链接数

我看了一下12306.cn，打开主页需要建60多个HTTP连接，车票预订页面则有70多个HTTP请求，现在的浏览器都是并发请求的。所以，只要有100万个用户，就会有6000万个链接，太多了。一个登录查询页面就好了。把js打成一个文件，把css也打成一个文件，把图标也打成一个文件，用css分块展示。把链接数减到最低。

三、减少网页大小增加带宽

这个世界不是哪个公司都敢做图片服务的，因为图片太耗带宽了。现在宽带时代很难有人能体会到当拨号时代做个图页都不敢用图片的情形（现在在手机端浏览也是这个情形）。我查看了一下12306首页的需要下载的总文件大小大约在900KB左右，如果你访问过了，浏览器会帮你缓存很多，只需下载10K左右的文件。但是我们可以想像一个极端一点的案例，1百万用户同时访问，且都是第一次访问，每人下载量需要1M，如果需要在120秒内返回，那么就需要，1M * 1M /120 * 8 = 66Gbps的带宽。很惊人吧。所以，我估计在当天，12306的阻塞基本上应该是网络带宽，所以，你可能看到的是没有响应。后面随着浏览器的缓存帮助12306减少很多带宽占用，于是负载一下就到了后端，后端的数据处理瓶颈一下就出来。于是你会看到很多http 500之类的错误。这说明服务器垮了。

四、前端页面静态化

静态化一些不常变的页面和数据，并gzip一下。还有一个并态的方法是把这些静态页面放在/dev/shm下，这个目录就是内存，直接从内存中把文件读出来返回，这样可以减少昂贵的磁盘I/O。

五、优化查询

很多人查询都是在查一样的，完全可以用反向代理合并这些并发的相同的查询。这样的技术主要用查询结果缓存来实现，第一次查询走数据库获得数据，并把数据放到缓存，后面的查询统统直接访问高速缓存。为每个查询做Hash，使用NoSQL的技术可以完成这个优化。（这个技术也可以用做静态页面）

对于火车票量的查询，个人觉得不要显示数字，就显示一个“有”或“无”就好了，这样可以大大简化系统复杂度，并提升性能。

六、缓存的问题

缓存可以用来缓存动态页面，也可以用来缓存查询的数据。缓存通常有那么几个问题：

1）缓存的更新。也叫缓存和数据库的同步。有这么几种方法，一是缓存time out，让缓存失效，重查，二是，由后端通知更新，一量后端发生变化，通知前端更新。前者实现起来比较简单，但实时性不高，后者实现起来比较复杂 ，但实时性高。

2）缓存的换页。内存可能不够，所以，需要把一些不活跃的数据换出内存，这个和操作系统的内存换页和交换内存很相似。FIFO、LRU、LFU都是比较经典的换页算法。相关内容参看Wikipeida的缓存算法。

3）缓存的重建和持久化。缓存在内存，系统总要维护，所以，缓存就会丢失，如果缓存没了，就需要重建，如果数据量很大，缓存重建的过程会很慢，这会影响生产环境，所以，缓存的持久化也是需要考虑的。

诸多强大的NoSQL都很好支持了上述三大缓存的问题。

后端性能优化技术

前面讨论了前端性能的优化技术，于是前端可能就不是瓶颈问题了。那么性能问题就会到后端数据上来了。下面说几个后端常见的性能优化技术。

一、数据冗余

关于数据冗余，也就是说，把我们的数据库的数据冗余处理，也就是减少表连接这样的开销比较大的操作，但这样会牺牲数据的一致性。风险比较大。很多人把NoSQL用做数据，快是快了，因为数据冗余了，但这对数据一致性有大的风险。这需要根据不同的业务进行分析和处理。（注意：用关系型数据库很容易移植到NoSQL上，但是反过来从NoSQL到关系型就难了）

二、数据镜像

几乎所有主流的数据库都支持镜像，也就是replication。数据库的镜像带来的好处就是可以做负载均衡。把一台数据库的负载均分到多台上，同时又保证了数据一致性（Oracle的SCN）。最重要的是，这样还可以有高可用性，一台废了，还有另一台在服务。

数据镜像的数据一致性可能是个复杂的问题，所以我们要在单条数据上进行数据分区，也就是说，把一个畅销商品的库存均分到不同的服务器上，如，一个畅销商品有1万的库存，我们可以设置10台服务器，每台服务器上有1000个库存，这就好像B2C的仓库一样。

三、数据分区

数据镜像不能解决的一个问题就是数据表里的记录太多，导致数据库操作太慢。所以，把数据分区。数据分区有很多种做法，一般来说有下面这几种：

1）把数据把某种逻辑来分类。比如火车票的订票系统可以按各铁路局来分，可按各种车型分，可以按始发站分，可以按目的地分……，反正就是把一张表拆成多张有一样的字段但是不同种类的表，这样，这些表就可以存在不同的机器上以达到分担负载的目的。

2）把数据按字段分，也就是竖着分表。比如把一些不经常改的数据放在一个表里，经常改的数据放在另外多个表里。把一张表变成1对1的关系，这样，你可以减少表的字段个数，同样可以提升一定的性能。另外，字段多会造成一条记录的存储会被放到不同的页表里，这对于读写性能都有问题。但这样一来会有很多复杂的控制。

3）平均分表。因为第一种方法是并不一定平均分均，可能某个种类的数据还是很多。所以，也有采用平均分配的方式，通过主键ID的范围来分表。

4）同一数据分区。这个在上面数据镜像提过。也就是把同一商品的库存值分到不同的服务器上，比如有10000个库存，可以分到10台服务器上，一台上有1000个库存。然后负载均衡。

这三种分区都有好有坏。最常用的还是第一种。数据一旦分区，你就需要有一个或是多个调度来让你的前端程序知道去哪里找数据。把火车票的数据分区，并放在各个省市，会对12306这个系统有非常有意义的质的性能的提高。

四、后端系统负载均衡

前面说了数据分区，数据分区可以在一定程度上减轻负载，但是无法减轻热销商品的负载，对于火车票来说，可以认为是大城市的某些主干线上的车票。这就需要使用数据镜像来减轻负载。使用数据镜像，你必然要使用负载均衡，在后端，我们可能很难使用像路由器上的负载均衡器，因为那是均衡流量的，因为流量并不代表服务器的繁忙程度。因此，我们需要一个任务分配系统，其还能监控各个服务器的负载情况。

任务分配服务器有一些难点：

• 负载情况比较复杂。什么叫忙？是CPU高？还是磁盘I/O高？还是内存使用高？还是并发高？还是内存换页率高？你可能需要全部都要考虑。这些信息要发送给那个任务分配器上，由任务分配器挑选一台负载最轻的服务器来处理。

• 任务分配服务器上需要对任务队列，不能丢任务啊，所以还需要持久化。并且可以以批量的方式把任务分配给计算服务器。

• 任务分配服务器死了怎么办？这里需要一些如Live-Standby或是failover等高可用性的技术。我们还需要注意那些持久化了的任务的队列如何转移到别的服务器上的问题。

我看到有很多系统都用静态的方式来分配，有的用hash，有的就简单地轮流分析。这些都不够好，一个是不能完美地负载均衡，另一个静态的方法的致命缺陷是，如果有一台计算服务器死机了，或是我们需要加入新的服务器，对于我们的分配器来说，都需要知道的。

还有一种方法是使用抢占式的方式进行负载均衡，由下游的计算服务器去任务服务器上拿任务。让这些计算服务器自己决定自己是否要任务。这样的好处是可以简化系统的复杂度，而且还可以任意实时地减少或增加计算服务器。但是唯一不好的就是，如果有一些任务只能在某种服务器上处理，这可能会引入一些复杂度。不过总体来说，这种方法可能是比较好的负载均衡。

五、异步、 throttle 和 批量处理

异步、throttle（节流阀） 和批量处理都需要对并发请求数做队列处理的。

• 异步在业务上一般来说就是收集请求，然后延时处理。在技术上就是可以把各个处理程序做成并行的，也就可以水平扩展了。但是异步的技术问题大概有这些，a）被调用方的结果返回，会涉及进程线程间通信的问题。b）如果程序需要回滚，回滚会有点复杂。c）异步通常都会伴随多线程多进程，并发的控制也相对麻烦一些。d）很多异步系统都用消息机制，消息的丢失和乱序也会是比较复杂的问题。

• throttle 技术其实并不提升性能，这个技术主要是防止系统被超过自己不能处理的流量给搞垮了，这其实是个保护机制。使用throttle技术一般来说是对于一些自己无法控制的系统，比如，和你网站对接的银行系统。

• 批量处理的技术，是把一堆基本相同的请求批量处理。比如，大家同时购买同一个商品，没有必要你买一个我就写一次数据库，完全可以收集到一定数量的请求，一次操作。这个技术可以用作很多方面。比如节省网络带宽，我们都知道网络上的MTU（最大传输单元），以态网是1500字节，光纤可以达到4000多个字节，如果你的一个网络包没有放满这个MTU，那就是在浪费网络带宽，因为网卡的驱动程序只有一块一块地读效率才会高。因此，网络发包时，我们需要收集到足够多的信息后再做网络I/O，这也是一种批量处理的方式。批量处理的敌人是流量低，所以，批量处理的系统一般都会设置上两个阀值，一个是作业量，另一个是timeout，只要有一个条件满足，就会开始提交处理。

所以，只要是异步，一般都会有throttle机制，一般都会有队列来排队，有队列，就会有持久化，而系统一般都会使用批量的方式来处理。

云风同学设计的“排队系统” 就是这个技术。这和电子商务的订单系统很相似，就是说，我的系统收到了你的购票下单请求，但是我还没有真正处理，我的系统会跟据我自己的处理能力来throttle住这些大量的请求，并一点一点地处理。一旦处理完成，我就可以发邮件或短信告诉用户你来可以真正购票了。

在这里，我想通过业务和用户需求方面讨论一下云风同学的这个排队系统，因为其从技术上看似解决了这个问题，但是从业务和用户需求上来说可能还是有一些值得我们去深入思考的地方：

1）队列的DoS攻击。首先，我们思考一下，这个队是个单纯地排队的吗？这样做还不够好，因为这样我们不能杜绝黄牛，而且单纯的ticket_id很容易发生DoS攻击，比如，我发起N个 ticket_id，进入购票流程后，我不买，我就耗你半个小时，很容易我就可以让想买票的人几天都买不到票。有人说，用户应该要用身份证来排队， 这样在购买里就必需要用这个身份证来买，但这也还不能杜绝黄牛排队或是号贩子。因为他们可以注册N个帐号来排队，但就是不买。黄牛这些人这个时候只需要干一个事，把网站搞得正常人不能访问，让用户只能通过他们来买。

2）对列的一致性？对这个队列的操作是不是需要锁？只要有锁，性能一定上不去。试想，100万个人同时要求你来分配位置号，这个队列将会成为性能瓶颈。你一定没有数据库实现得性能好，所以，可能比现在还差

3）队列的等待时间。购票时间半小时够不够？多不多？要是那时用户正好不能上网呢？如果时间短了，用户不够时间操作也会抱怨，如果时间长了，后面在排队的那些人也会抱怨。这个方法可能在实际操作上会有很多问题。另外，半个小时太长了，这完全不现实，我们用15分钟来举例：有1千万用户，每一个时刻只能放进去1万个，这1万个用户需要15分钟完成所有操作，那么，这1千万用户全部处理完，需要1000*15m = 250小时，10天半，火车早开了。（我并非乱说，根据铁道部专家的说明：这几天，平均一天下单100万，所以，处理1000万的用户需要十天。这个计算可能有点简单了，我只是想说，在这样低负载的系统下用排队可能都不能解决问题）

4）队列的分布式。这个排队系统只有一个队列好吗？还不足够好。因为，如果你放进去的可以购票的人如果在买同一个车次的同样的类型的票（比如某动车卧铺），还是等于在抢票，也就是说系统的负载还是会有可能集中到其中某台服务器上。因此，最好的方法是根据用户的需求——提供出发地和目的地，来对用户进行排队。而这样一来，队列也就可以是多个，只要是多个队列，就可以水平扩展了。

我觉得完全可以向网上购物学习。在排队（下单）的时候，收集好用户的信息和想要买的票，并允许用户设置购票的优先级，比如，A车次卧铺买 不到就买 B车次的卧铺，如果还买不到就买硬座等等，然后用户把所需的钱先充值好，接下来就是系统完全自动地异步处理订单。成功不成功都发短信或邮件通知用户。这样，系统不仅可以省去那半个小时的用户交互时间，自动化加快处理，还可以合并相同购票请求的人，进行批处理（减少数据库的操作次数）。这种方法最妙的事是可以知道这些排队用户的需求，不但可以优化用户的队列，把用户分布到不同的队列，还可以像亚马逊的心愿单一样，让铁道部做车次统筹安排和调整（最后，排队系统（下单系统）还是要保存在数据库里的或做持久化，不能只放在内存中，不然机器一down，就等着被骂吧）。

小结

写了那么多，我小结一下：

0）无论你怎么设计，你的系统一定要能容易地水平扩展。也就是说，你的整个数据流中，所有的环节都要能够水平扩展。这样，当你的系统有性能问题时，“加3倍的服务器”才不会被人讥笑。

1）上述的技术不是一朝一夕能搞定的，没有长期的积累，基本无望。我们可以看到，无论你用哪种都会引发一些复杂性。

2）集中式的卖票很难搞定，使用上述的技术可以让订票系统能有几佰倍的性能提升。而在各个省市建分站，分开卖票，是能让现有系统性能有质的提升的最好方法。

3）春运前夕抢票且票量供远小于求这种业务模式是相当变态的，让几千万甚至上亿的人在某个早晨的8点钟同时登录同时抢票的这种业务模式是变态中的变态。业务形态的变态决定了无论他们怎么办干一定会被骂。

4）为了那么一两个星期而搞那么大的系统，而其它时间都在闲着，有些可惜了，这也就是铁路才干得出来这样的事了。

（本文转载时请注明作者和出处，请勿于记商业目的）

您可能也喜欢：
Why C++ ? 王者归来	酷壳 – CoolShell.cn	Amazon的书为什么卖到了$2000万	35个强大的UI设计教程	酷壳完成迁移 感谢网友“知秋一叶”
无觅

相关文章

• 2012年02月02日 -- Why C++ ? 王者归来
• 2011年10月25日 -- 多些时间能少写些代码
• 2011年09月20日 -- 一些文章和各种资源
• 2011年09月08日 -- 千万不要把 bool 设计成函数参数
• 2011年06月10日 -- 软件真的好难做啊
• 2011年05月03日 -- 读书笔记：对线程模型的批评
• 2011年04月28日 -- Amazon的书为什么卖到了$2000万

另，这篇文章主要基于 ECMAScript 5， 旨在介绍新技术。关于兼容性的东西，请看最后一节。

初探

我们知道Javascript中的变量定义基本如下：

var name = 'Chen Hao';;
var email = 'haoel(@)hotmail.com';
var website = 'http://coolshell.cn';

如果要用对象来写的话，就是下面这个样子：

var chenhao = {
    name :'Chen Hao',
    email : 'haoel(@)hotmail.com',
    website : 'http://coolshell.cn'
};

于是，我就可以这样访问：

//以成员的方式
chenhao.name;
chenhao.email;
chenhao.website;

//以hash map的方式
chenhao["name"];
chenhao["email"];
chenhao["website"];

关于函数，我们知道Javascript的函数是这样的：

var doSomething = function(){
   alert('Hello World.');
};

于是，我们可以这么干：

var sayHello = function(){
   var hello = "Hello, I'm "+ this.name
                + ", my email is: " + this.email
                + ", my website is: " + this.website;
   alert(hello);
};

//直接赋值，这里很像C/C++的函数指针
chenhao.Hello = sayHello;

chenhao.Hello();

相信这些东西都比较简单，大家都明白了。 可以看到javascript对象函数是直接声明，直接赋值，直接就用了。runtime的动态语言。

还有一种比较规范的写法是：

//我们可以看到， 其用function来做class。
var Person = function(name, email, website){
    this.name = name;
    this.email = email;
    this.website = website;

    this.sayHello = function(){
        var hello = "Hello, I'm "+ this.name  + ", \n" +
                    "my email is: " + this.email + ", \n" +
                    "my website is: " + this.website;
        alert(hello);
    };
};

var chenhao = new Person("Chen Hao", "haoel@hotmail.com",
                                     "http://coolshell.cn");
chenhao.sayHello(); 

顺便说一下，要删除对象的属性，很简单：

delete chenhao['email']

上面的这些例子，我们可以看到这样几点：

1. Javascript的数据和成员封装很简单。没有类完全是对象操作。纯动态！
2. Javascript function中的this指针很关键，如果没有的话，那就是局部变量或局部函数。
3. Javascript对象成员函数可以在使用时临时声明，并把一个全局函数直接赋过去就好了。
4. Javascript的成员函数可以在实例上进行修改，也就是说不同实例相同函数名的行为不一定一样。

属性配置 – Object.defineProperty

先看下面的代码：

//创建对象
var chenhao = Object.create(null);

//设置一个属性
 Object.defineProperty( chenhao,
                'name', { value:  'Chen Hao',
                          writable:     true,
                          configurable: true,
                          enumerable:   true });

//设置多个属性
Object.defineProperties( chenhao,
    {
        'email'  : { value:  'haoel@hotmail.com',
                     writable:     true,
                     configurable: true,
                     enumerable:   true },
        'website': { value: 'http://coolshell.cn',
                     writable:     true,
                     configurable: true,
                     enumerable:   true }
    }
);

下面就说说这些属性配置是什么意思。

• writable：这个属性的值是否可以改。
• configurable：这个属性的配置是否可以改。
• enumerable：这个属性是否能在for…in循环中遍历出来或在Object.keys中列举出来。
• value：属性值。
• get()/set(_value)：get和set访问器。

Get/Set 访问器

关于get/set访问器，它的意思就是用get/set来取代value（其不能和value一起使用），示例如下：

var  age = 0;
Object.defineProperty( chenhao,
            'age', {
                      get: function() {return age+1;},
                      set: function(value) {age = value;}
                      enumerable : true,
                      configurable : true
                    }
);
chenhao.age = 100; //调用set
alert(chenhao.age); //调用get 输出101（get中+1了）;

我们再看一个更为实用的例子——利用已有的属性(age)通过get和set构造新的属性(birth_year)：

Object.defineProperty( chenhao,
            'birth_year',
            {
                get: function() {
                    var d = new Date();
                    var y = d.getFullYear();
                    return ( y - this.age );
                },
                set: function(year) {
                    var d = new Date();
                    var y = d.getFullYear();
                    this.age = y - year;
                }
            }
);

alert(chenhao.birth_year);
chenhao.birth_year = 2000;
alert(chenhao.age);

这样做好像有点麻烦，你说，我为什么不写成下面这个样子：

var chenhao = {
    name: "Chen Hao",
    email: "haoel@hotmail.com",
    website: "http://coolshell.cn",
    age: 100,
    get birth_year() {
        var d = new Date();
        var y = d.getFullYear();
        return ( y - this.age );
    },
    set birth_year(year) {
        var d = new Date();
        var y = d.getFullYear();
        this.age = y - year;
    }

};
alert(chenhao.birth_year);
chenhao.birth_year = 2000;
alert(chenhao.age);

是的，你的确可以这样的，不过通过defineProperty()你可以干这些事：
1）设置如 writable，configurable，enumerable 等这类的属性配置。
2）动态地为一个对象加属性。比如：一些HTML的DOM对像。

查看对象属性配置

如果查看并管理对象的这些配置，下面有个程序可以输出对象的属性和配置等东西：

//列出对象的属性.
function listProperties(obj)
{
    var newLine = "<br />";
    var names = Object.getOwnPropertyNames(obj);
    for (var i = 0; i < names.length; i++) {
        var prop = names[i];
        document.write(prop + newLine);

        // 列出对象的属性配置（descriptor）动用getOwnPropertyDescriptor函数。
        var descriptor = Object.getOwnPropertyDescriptor(obj, prop);
        for (var attr in descriptor) {
            document.write("..." + attr + ': ' + descriptor[attr]);
            document.write(newLine);
        }
        document.write(newLine);
    }
}

listProperties(chenhao);

call，apply， bind 和 this

关于Javascript的this指针，和C++/Java很类似。 我们来看个示例：（这个示例很简单了，我就不多说了）

function print(text){
    document.write(this.value + ' - ' + text+ '<br>');
}

var a = {value: 10, print : print};
var b = {value: 20, print : print};

print('hello');// this => global, output "undefined - hello"

a.print('a');// this => a, output "10 - a"
b.print('b'); // this => b, output "20 - b"

a['print']('a'); // this => a, output "10 - a"

我们再来看看call 和 apply，这两个函数的差别就是参数的样子不一样，另一个就是性能不一样，apply的性能要差很多。（关于性能，可到 JSPerf 上去跑跑看看）

print.call(a, 'a'); // this => a, output "10 - a"
print.call(b, 'b'); // this => b, output "20 - b"

print.apply(a, ['a']); // this => a, output "10 - a"
print.apply(b, ['b']); // this => b, output "20 - b"

但是在bind后，this指针，可能会有不一样，但是因为Javascript是动态的。如下面的示例

var p = print.bind(a);
p('a');             // this => a, output "10 - a"
p.call(b, 'b');     // this => a, output "10 - b"
p.apply(b, ['b']);  // this => a, output "10 - b"

继承 和 重载

通过上面的那些示例，我们可以通过Object.create()来实际继承，请看下面的代码，Student继承于Object。

var Person = Object.create(null);

Object.defineProperties
(
    Person,
    {
        'name'  : {  value: 'Chen Hao'},
        'email'  : { value : 'haoel@hotmail.com'},
        'website': { value: 'http://coolshell.cn'}
    }
);

Person.sayHello = function () {
    var hello = "<p>Hello, I am "+ this.name  + ", <br>" +
                "my email is: " + this.email + ", <br>" +
                "my website is: " + this.website;
    document.write(hello + "<br>");
}

var Student = Object.create(Person);
Student.no = "1234567"; //学号
Student.dept = "Computer Science"; //系

//使用Person的属性
document.write(Student.name + ' ' + Student.email + ' ' + Student.website +'<br>');

//使用Person的方法
Student.sayHello();

//重载SayHello方法
Student.sayHello = function (person) {
    var hello = "<p>Hello, I am "+ this.name  + ", <br>" +
                "my email is: " + this.email + ", <br>" +
                "my website is: " + this.website + ", <br>" +
                "my student no is: " + this. no + ", <br>" +
                "my departent is: " + this. dept;
    document.write(hello + '<br>');
}
//再次调用
Student.sayHello();

//查看Student的属性（只有 no 、 dept 和 重载了的sayHello）
document.write('<p>' + Object.keys(Student) + '<br>');

通用上面这个示例，我们可以看到，Person里的属性并没有被真正复制到了Student中来，但是我们可以去存取。这是因为Javascript用委托实现了这一机制。其实，这就是Prototype，Person是Student的Prototype。

当我们的代码需要一个属性的时候，Javascript的引擎会先看当前的这个对象中是否有这个属性，如果没有的话，就会查找他的Prototype对象是否有这个属性，一直继续下去，直到找到或是直到没有Prototype对象。

为了证明这个事，我们可以使用Object.getPrototypeOf()来检验一下：

Student.name = 'aaa';

//输出 aaa
document.write('<p>' + Student.name + '</p>');

//输出 Chen Hao
document.write('<p>' +Object.getPrototypeOf(Student).name + '</p>');

于是，你还可以在子对象的函数里调用父对象的函数，就好像C++里的 Base::func() 一样。于是，我们重载hello的方法就可以使用父类的代码了，如下所示：

//新版的重载SayHello方法
Student.sayHello = function (person) {
    Object.getPrototypeOf(this).sayHello.call(this);
    var hello = "my student no is: " + this. no + ", <br>" +
                "my departent is: " + this. dept;
    document.write(hello + '<br>');
}

这个很强大吧。

组合

上面的那个东西还不能满足我们的要求，我们可能希望这些对象能真正的组合起来。为什么要组合？因为我们都知道是这是OO设计的最重要的东西。不过，这对于Javascript来并没有支持得特别好，不好我们依然可以搞定个事。

首先，我们需要定义一个Composition的函数：（target是作用于是对象，source是源对象），下面这个代码还是很简单的，就是把source里的属性一个一个拿出来然后定义到target中。

function Composition(target, source)
{
    var desc  = Object.getOwnPropertyDescriptor;
    var prop  = Object.getOwnPropertyNames;
    var def_prop = Object.defineProperty;

    prop(source).forEach(
        function(key) {
            def_prop(target, key, desc(source, key))
        }
    )
    return target;
}

有了这个函数以后，我们就可以这来玩了：

//艺术家
var Artist = Object.create(null);
Artist.sing = function() {
    return this.name + ' starts singing...';
}
Artist.paint = function() {
    return this.name + ' starts painting...';
}

//运动员
var Sporter = Object.create(null);
Sporter.run = function() {
    return this.name + ' starts running...';
}
Sporter.swim = function() {
    return this.name + ' starts swimming...';
}

Composition(Person, Artist);
document.write(Person.sing() + '<br>');
document.write(Person.paint() + '<br>');

Composition(Person, Sporter);
document.write(Person.run() + '<br>');
document.write(Person.swim() + '<br>');

//看看 Person中有什么？（输出：sayHello,sing,paint,swim,run）
document.write('<p>' + Object.keys(Person) + '<br>');

Prototype 和 继承

我们先来说说Prototype。我们先看下面的例程，这个例程不需要解释吧，很像C语言里的函数指针，在C语言里这样的东西见得多了。

var plus = function(x,y){
    document.write( x + ' + ' + y + ' = ' + (x+y) + '<br>');
    return x + y;
};

var minus = function(x,y){
    document.write(x + ' - ' + y + ' = ' + (x-y) + '<br>');
    return x - y;
};

var operations = {
    '+': plus,
    '-': minus
};

var calculate = function(x, y, operation){
    return operations[operation](x, y);
};

calculate(12, 4, '+');
calculate(24, 3, '-');

那么，我们能不能把这些东西封装起来呢，我们需要使用prototype。看下面的示例：

var Cal = function(x, y){
    this.x = x;
    this.y = y;
}

Cal.prototype.operations = {
    '+': function(x, y) { return x+y;},
    '-': function(x, y) { return x-y;}
};

Cal.prototype.calculate = function(operation){
    return this.operations[operation](this.x, this.y);
};

var c = new Cal(4, 5);

c.calculate('+');
c.calculate('-');

这就是prototype的用法，prototype 是javascript这个语言中最重要的内容。网上有太多的文章介始这个东西了。说白了，prototype就是对一对象进行扩展，其特点在于通过“复制”一个已经存在的实例来返回新的实例,而不是新建实例。被复制的实例就是我们所称的“原型”，这个原型是可定制的（当然，这里没有真正的复制，实际只是委托）。上面的这个例子中，我们扩展了实例Cal，让其有了一个operations的属性和一个calculate的方法。

这样，我们可以通过这一特性来实现继承。还记得我们最最前面的那个Person吧， 下面的示例是创建一个Student来继承Person。

function Person(name, email, website){
    this.name = name;
    this.email = email;
    this.website = website;
};

Person.prototype.sayHello = function(){
    var hello = "Hello, I am "+ this.name  + ", <br>" +
                "my email is: " + this.email + ", <br>" +
                "my website is: " + this.website;
    return hello;
};

function Student(name, email, website, no, dept){
    var proto = Object.getPrototypeOf;
    proto(Student.prototype).constructor.call(this, name, email, website);
    this.no = no;
    this.dept = dept;
}

// 继承prototype
Student.prototype = Object.create(Person.prototype);

//重置构造函数
Student.prototype.constructor = Student;

//重载sayHello()
Student.prototype.sayHello = function(){
    var proto = Object.getPrototypeOf;
    var hello = proto(Student.prototype).sayHello.call(this) + '<br>';
    hello += "my student no is: " + this. no + ", <br>" +
             "my departent is: " + this. dept;
    return hello;
};

var me = new Student(
    "Chen Hao",
    "haoel@hotmail.com",
    "http://coolshell.cn",
    "12345678",
    "Computer Science"
);
document.write(me.sayHello());

兼容性

上面的这些代码并不一定能在所有的浏览器下都能运行，因为上面这些代码遵循 ECMAScript 5 的规范，关于ECMAScript 5 的浏览器兼容列表，你可以看这里“ES5浏览器兼容表”。

本文中的所有代码都在Chrome最新版中测试过了。

下面是一些函数，可以用在不兼容ES5的浏览器中：

Object.create()函数

function clone(proto) {
    function Dummy() { }

    Dummy.prototype             = proto;
    Dummy.prototype.constructor = Dummy;

    return new Dummy(); //等价于Object.create(Person);
}

var me = clone(Person);

defineProperty()函数

function defineProperty(target, key, descriptor) {
    if (descriptor.value){
        target[key] = descriptor.value;
    }else {
        descriptor.get && target.__defineGetter__(key, descriptor.get);
        descriptor.set && target.__defineSetter__(key, descriptor.set);
    }

    return target
}

keys()函数

function keys(object) { var result, key
    result = [];
    for (key in object){
        if (object.hasOwnProperty(key))  result.push(key)
    }

    return result;
}

Object.getPrototypeOf() 函数

function proto(object) {
    return !object?                null
         : '__proto__' in object?  object.__proto__
         : /* not exposed? */      object.constructor.prototype
}

bind 函数

var slice = [].slice

function bind(fn, bound_this) { var bound_args
    bound_args = slice.call(arguments, 2)
    return function() { var args
        args = bound_args.concat(slice.call(arguments))
        return fn.apply(bound_this, args) }
}

参考

• W3CSchool
• MDN (Mozilla Developer Network)
• MSDN (Microsoft Software Development Network)
• Understanding Javascript OOP.

（转载时请注明作者和出处，请勿用于任何商业用途）

您可能也喜欢：
Javascript的两本书	Javascript 曲线表作图库	20个优秀的Javascript导航技术	把Flash转成Javascript/HTML5	Javascript程序员嘴最脏??
无觅

相关文章

• 2011年08月15日 -- 对象的消息模型
• 2011年12月07日 -- Web开发中需要了解的东西
• 2011年11月24日 -- 一些文章资源和趣闻
• 2011年10月31日 -- API设计：用流畅接口构造内部DSL
• 2011年07月21日 -- 面向对象的Shell脚本
• 2011年06月08日 -- 开源中最好的Web开发的资源
• 2011年05月19日 -- 在Web上运行Linux

• Java, 所有版本
• JRuby <= 1.6.5 （目前fix在 1.6.5.1）
• PHP <= 5.3.8, <= 5.4.0RC3 （目前fix在 5.3.9,  5.4.0RC4）
• Python, all versions
• Rubinius, all versions
• Ruby <= 1.8.7-p356 （目前fix在 1.8.7-p357, 1.9.x）
• Apache Geronimo, 所有版本
• Apache Tomcat <= 5.5.34, <= 6.0.34, <= 7.0.22 （目前fix在 5.5.35,  6.0.35,  7.0.23）
• Oracle Glassfish <= 3.1.1 （目前fix在mainline）
• Jetty, 所有版本
• Plone, 所有版本
• Rack <= 1.3.5, <= 1.2.4, <= 1.1.2 （目前fix 在 1.4.0, 1.3.6, 1.2.5, 1.1.3）
• V8 JavaScript Engine, 所有版本
• ASP.NET 没有打MS11-100补丁

注意，Perl没有这个问题，因为Perl在N年前就fix了这个问题了。关于这个列表的更新，请参看 oCERT的2011-003报告，比较坑爹的是，这个问题早在2003 年就在论文《通过算法复杂性进行拒绝式服务攻击》中被报告了，但是好像没有引起注意，尤其是Java。

弱点攻击解释

你可以会觉得这个问题没有什么大不了的，因为黑客是看不到hash算法的，如果你这么认为，那么你就错了，这说明对Web编程的了解还不足够底层。

无论你用JSP，PHP，Python，Ruby来写后台网页的时候，在处理HTTP POST数据的时候，你的后台程序可以很容易地以访问表单字段名来访问表单值，就像下面这段程序一样：

$usrname = $_POST['username'];
$passwd = $_POST['password'];

这是怎么实现的呢？这后面的东西就是Hash Map啊，所以，我可以给你后台提交一个有10K字段的表单，这些字段名都被我精心地设计过，他们全是Hash Collision ，于是你的Web Server或语言处理这个表单的时候，就会建造这个hash map，于是在每插入一个表单字段的时候，都会先遍历一遍你所有已插入的字段，于是你的服务器的CPU一下就100%了，你会觉得这10K没什么，那么我就发很多个的请求，你的服务器一下就不行了。

举个例子，你可能更容易理解：

如果你有n个值—— v1, v2, v3, … vn，把他们放到hash表中应该是足够散列的，这样性能才高：

0 -> v2
1 -> v4
2 -> v1
…
…
n -> v(x)

但是，这个攻击可以让我造出N个值——  dos1, dos2, …., dosn，他们的hash key都是一样的（也就是Hash Collision），导致你的hash表成了下面这个样子：

0 – > dos1 -> dos2 -> dos3 -> …. ->dosn
1 -> null
2 -> null
…
…
n -> null

于是，单向链接就这样出现了。这样一来，O(1)的搜索算法复杂度就成了O(n)，而插入N个数据的算法复杂度就成了O(n^2)，你想想这是什么样的性能。

（关于Hash表的实现，如果你忘了，那就把大学时的《数据结构》一书拿出来看看）

  Hash Collision DoS 详解

StackOverflow.com是个好网站， 合格的程序员都应该知道这个网站。上去一查，就看到了这个贴子“Application vulnerability due to Non Random Hash Functions”。我把这个贴子里的东西摘一些过来。

首先，这些语言使用的Hash算法都是“非随机的”，如下所示，这个是Java和Oracle使用的Hash函数：

static int hash(int h)
{
h ^= (h >>> 20) ^ (h >>> 12);
return h ^ (h >>> 7) ^ (h >>> 4);
}

所谓“非随机的” Hash算法，就可以猜。比如：

1）在Java里， Aa和BB这两个字符串的hash code(或hash key) 是一样的，也就是Collision 。

2）于是，我们就可以通过这两个种子生成更多的拥有同一个hash key的字符串。如：”AaAa”, “AaBB”, “BBAa”, “BBBB”。这是第一次迭代。其实就是一个排列组合，写个程序就搞定了。

3）然后，我们可以用这4个长度的字符串，构造8个长度的字符串，如下所示：

"AaAaAaAa", "AaAaBBBB", "AaAaAaBB", "AaAaBBAa", 
"BBBBAaAa", "BBBBBBBB", "BBBBAaBB", "BBBBBBAa", 
"AaBBAaAa", "AaBBBBBB", "AaBBAaBB", "AaBBBBAa", 
"BBAaAaAa", "BBAaBBBB", "BBAaAaBB", "BBAaBBAa",

4）同理，我们就可以生成16个长度的，以及256个长度的字符串，总之，很容易生成N多的这样的值。

在攻击时，我只需要把这些数据做成一个HTTP POST 表单，然后写一个无限循环的程序，不停地提交这个表单。你用你的浏览器就可以了。当然，如果做得更精妙一点的话，把你的这个表单做成一个跨站脚本，然后找一些网站的跨站漏洞，放上去，于是能过SNS的力量就可以找到N多个用户来帮你从不同的IP来攻击某服务器。

防守

要防守这样的攻击，有下面几个招：

• 打补丁，把hash算法改了。
• 限制POST的参数个数，限制POST的请求长度。
• 最好还有防火墙检测异常的请求。

不过，对于更底层的或是其它形式的攻击，可能就有点麻烦了。

（全文完）

您可能也喜欢：
Java构造时成员初始化的陷阱	JAVA的字符串拼接与性能	20非常有用的Java程序片段	Java书籍Top 10	C++和JAVA传统中积极的一面
无觅

相关文章

• 2012年01月05日 -- Resin服务器getResource揭秘
• 2011年12月28日 -- 由一个问题到 Resin ClassLoader 的学习
• 2011年12月22日 -- CSDN明文口令泄露的启示
• 2011年12月07日 -- Web开发中需要了解的东西
• 2011年11月28日 -- 如何设计“找回用户帐号”功能
• 2011年11月25日 -- 腾讯帐号申诉的用户体验
• 2011年10月31日 -- API设计：用流畅接口构造内部DSL

前言

接上文“由一个问题到Resin ClassLoader的学习”，本文将以this.getClass().getResource(“/”).getPath()和this.getClass().getResourceAsStream(“/a.txt”)为例，一步步解析加载的过程。

调试环境

1. 下载resin3.0.23的源码(http://www.caucho.com/download/resin-3.0.23-src.zip)。
2. 部署到myeclipse中，有错误，本人忽略了。Resin可运行。
3. 将EhCacheTestAnnotation部署到resin3.0.23中。
4. 调试this.getClass().getResource(“/”).getPath()。

问题来了，无论如何也模拟不出来<compiling-loader>所造成的影响，一直输出：/D:/work_other/project/resin-3.0.23/bin/ 。无奈之下，采用了这种方式：使用两个eclipse，一个使用发布版本的，部署EhCacheTestAnnotation进行调试；另外一个部署resin3.0.23源码，调试到哪里对照看源码。

开始

1) this.getClass().getResource(“/”).getPath()

本次调试涉及的所有类加载器为：

EnvironmentClassLoader$24156236[web-app:http://localhost:8787/EhCacheTestAnnotation]

EnvironmentClassLoader$7806641[host:http://localhost:8787]

EnvironmentClassLoader$22459270[servlet-server:]

sun.misc.Launcher$AppClassLoader@7259da

sun.misc.Launcher$ExtClassLoader@16930e2

首先进入Class的getResource(String name)方法，如下图：

图1

最后委托给ClassLoader的getResource方法。那么这个ClassLoader是哪个呢？一看下图便知：

图2

是DynamicClassLoader的getResource方法，原理上文已述。

最终会委托给sun.misc.Launcher$ExtClassLoader@16930e2类加载器的getResource方法，返回null，然后开始回溯。

还记得吗？当java.net.URLClassLoader分支的ClassLoader的getResource方法返回值为null后，就要遍历嵌入DynamicClassLoader中的Resin的Loader(即_loaders集合)。

当然回溯到EnvironmentClassLoader$22459270[servlet-server:]中，那么它中_loaders这个集合中的Loader又有哪些呢？

以图为证，当天确实回溯到该ClassLoader，而且开始准备遍历_loaders集合。

图3

DynamicClassLoader的1306行，没问题，resin3.0.23源码截图为证：

图4

不做多余解释，那么“servlet-server”这个ClassLoader中的_loaders集合中都放了一些什么呢？

图5

存放了两个TreeLoader(Loader的子类)，然未找到结果，返回null。继续回溯。

这次轮到遍历EnvironmentClassLoader$7806641[host:http://localhost:8787]的_loaders。下图为证：

图6

_loaders中的内容如下图：

图7

比较长，我贴出来：

[CompilingLoader[src:/D:/work/resin-3.0.23/webapps/WEB-INF/classes], LibraryLoader[com.caucho.config.types.FileSetType@fb6763], CompilingLoader[src:/D:/work/resin-3.0.23/webapps/WEB-INF/classes], LibraryLoader[com.caucho.config.types.FileSetType@140b8fd], CompilingLoader[src:/D:/work/resin-3.0.23/webapps/WEB-INF/classes], LibraryLoader[com.caucho.config.types.FileSetType@30fc1f]]

注意到了吧，主角来了。那仔细调试下把。爆料一下：CompilingLoader[src:/D:/work/resin-3.0.23/webapps/WEB-INF/classes]就是主角。

图8

看到了吧，遍历时，当前的Loader为CompilingLoader[src:/D:/work/resin-3.0.23/webapps/WEB-INF/classes]，而且url可是不为null了哦。再贴一张，看看url的值到底是什么！

图9

嗯，不用多做解释了吧。

最后看看程序输出是否吻合，如下图：

图10

然后修改resin.conf中的<compiling-loader>将其注释掉，看看程序结果会不会是我们期望的：/D:/work/resin-3.0.23/webapps/EhCacheTestAnnotation/WEB-INF/classes/。拭目以待。

图11

为节省篇幅，一下只关注关键位置。

首先调试到EnvironmentClassLoader$7806641[host:http://localhost:8787]，我们需要停下来一下。

图12

再看一下_loaders的值。

图13

贴一个详细的：

[LibraryLoader[com.caucho.config.types.FileSetType@1299f7e], LibraryLoader[com.caucho.config.types.FileSetType@1a631cc], LibraryLoader[com.caucho.config.types.FileSetType@f6398]]

对比一下，在注释掉<compiling-loader>后，loaders中是没有CompilingClassLoader实例的。

继续，下面就轮到EnvironmentClassLoader$24156236[web-app:http://localhost:8787/EhCacheTestAnnotation]这个ClassLoader了，会是什么样子呢？

图14

进入该ClassLoader时，url值依旧为null，那_loaders会有变化吗？如下图：

图15

继续遍历_loaders。

图16

到这里就结束了，url在EnvironmentClassLoader$24156236[web-app:http://localhost:8787/EhCacheTestAnnotation]中被加载。

1) this.getClass().getResourceAsStream(“/a.txt”)

getResourceAsStream(String name)方法也是采用双亲委派的方式。在前一篇文章中提出“getResourceAsStream可是将获取路径委托给getResource，<compiling-loader>却没有对getResourceAsStream产生影响”

ClassLoader中getResourceAsStream源码也确实是委托为getResource了，可是为什么呢？

getResourceAsStream(String name)方法。

public InputStream getResourceAsStream(String name) {
    URL url = getResource(name);
    try {
        return url != null ? url.openStream() : null;
    } catch (IOException e) {
        return null;
    }
}

其实不难解释，JVM中ClassLoader的getResourceAsStream(“/a.txt”)返回了null，然后开始回溯，与getResource方法的原理一致，直到某个ClassLoader及其子类或者Loader及其子类找到了”/a.txt”，并以流的形式返回，当然谁都没找到就返回null。

捡重点的说。

调试到sun.misc.Launcher$AppClassLoader@18d107f，即ClassLoader的子类，情形如下图：

图17

看见getResource(name)喽，按F5进去看个究竟。如下图，其parent为：sun.misc.Launcher$ExtClassLoader@360be0，其返回null。

图18

开始回溯到：EnvironmentClassLoader$1497769[servlet-server:]，与getResource方法一致，开始遍历_loaders集合。

这样就可以解释为何<compiling-loader>没有影响到getResourceAsStream了。因为资源(这里是/a.txt)，就不是由AppClassLoader和ExtClassLoader加载的，而是由DynamicClassLoader或者其内部的_loaders集合完成的加载。或者更确切的说是由CompilingClassLoader获取到的URL，再转换成InputStream。

<comiling-loader>其实对getResourceAsStream还是有点影响的，如果配置中配置了<comiling-loader>，并且<comiling-loader>配置的路径下，与实际项目的指定路径下，都放置了同名资源，则会先加载<comiling-loader>配置路径下的资源。

比如，下图所示：

图19

<compiling-loader>配置的路径为：<compiling-loader path=”webapps/WEB-INF/classes”/>

在加载”/a.txt”时，优先加载webapps/WEB-INF/classes/a.txt。

总结

1. <compiling-loader>如被注释掉，则只会在EnvironmentClassLoader$24156236[web-app:http://localhost:8787/EhCacheTestAnnotation]中的_loaders中被初始化，否则会在EnvironmentClassLoader$24156236[web-app:http://localhost:8787/EhCacheTestAnnotation]和EnvironmentClassLoader$7806641[host:http://localhost:8787两个类加载器各自的_loaders集合中被初始化。(通过调试this.getClass().getResource("/test").getPath()验证)
2. <compiling-loader>未注释掉，"/"(根路径)由EnvironmentClassLoader$7806641[host:http://localhost:8787]加载，注释掉后由EnvironmentClassLoader$24156236[web-app:http://localhost:8787/EhCacheTestAnnotation]加载。
3. EnvironmentClassLoader$7806641[host:http://localhost:8787]为Resin server的类加载器实例，EnvironmentClassLoader$24156236[web-app:http://localhost:8787/EhCacheTestAnnotation]为Web应用程序的类加载器实例。他们都属于java.net.URLClassLoader的实例。
4. <compiling-loader>某种程度上对getResourceAsStream方法有影响。

现在<compiling-loader>如何影响getResource(“/”)，以及getResourceAsStream“不”被影响全部真相大白。

注：<compiling-loader>只对获取根路径产生影响，也就是参数为”/”。比如加载”/test/Path.class”不会产生影响。

（全文完）

您可能也喜欢：
由一个问题到 Resin ClassLoader 的学习	Java书籍Top 10	Java构造时成员初始化的陷阱	JAVA的字符串拼接与性能	如何在Java中避免equals方法的隐藏陷阱
无觅

相关文章

• 2011年12月28日 -- 由一个问题到 Resin ClassLoader 的学习
• 2012年01月06日 -- Hash Collision DoS 问题
• 2011年10月31日 -- API设计：用流畅接口构造内部DSL
• 2011年10月14日 -- 那些曾伴我走过编程之路的软件
• 2011年08月01日 -- 你确信你了解时间吗？
• 2011年07月18日 -- 程序员技术练级攻略
• 2011年06月29日 -- 语言的数据亲和力

这篇文章的来由是因为Eva在“三个事和三个问题”的评论里问我女孩子是否能做技术，她说她的很多师兄都告诉他不要做技术，所以，她有些不坚定了。我的回复是告诉了她我工作经历中的两个技术很牛的女孩，并且我从她们身上学到了多技术。但是，后面有一些人回复说我误导了别人。所以，我在新浪微博和twitter上征集女程序员的故事和想法。我一共收到了19封邮件，其中有17封邮件来自女程序员。其中有一个已经发布了（一个女程序员的故事），其中的一些观点已经在网上传播，并得到了大家的刮目和称赞。但这并不是特例，因为下面的这些故事中，还有很多令人刮目相看的东西。

说明：先说明一下，这篇文章并不想讨论女孩子是不是适合做技术，这不值得讨论，因为，在“一个女程序员的故事”中我们已经知道，态度和努力才是原因，而不是性别。这里，也只是想告诉那些有“性别歧视”、“看不起女程序员”、“骄傲自大”的男程序员们，那些女程序员不为所知的一面。我把几乎所有的故事都列在这篇文章里了，我觉得我不用再多说什么了，这些故事组成的风景线，可以让你充分地了解女程序员。

Ada Lovelace 世界第一个程序员

在看到那些故事之前，我们需要了解这样的现实——

• 大多数女孩子并不喜欢技术。这点从我们的计算机专业的学校就可以看到了。我上大学时，两个专业60个同学，有15个女生，男女比例已经失衡。不过，这些女生今天基本全部都还在做技术。现在，十多年了，她们其中女生还在各个公司的技术部门，主要做 开发和运维。这些是70后的女生。对于80后和90后的女生来说，可能喜欢技术的就更少了。Gavin在来信中说：“我们学院每届大约有800名学生，也就是说每年整个计算机学院只有大约50名女生。在这50名女生中，据我所知有至少一半的女生从开始到最后对编程一点兴趣都没有，这一半的女生有的准备跨专业考研，有的在考公务员，有的去了跟计算机专业几乎不沾边的行业去工作了，有的在大二的时候就已经开始修双专业了”。不过，在这里我们来看看做技术的女孩子是什么样的。

• 女孩子在找工作的时候总是会被歧视。很多用人单位都会问女孩子生孩子的问题，这简直就是干涉隐私和性别歧视，要在西方国家里，完全可以对这样的公司进行起诉。对于这种不尊重女性的公司，无论男女，一定不会尊重员工的。所以，这样的公司一定不要去。而很多女孩也会觉得结婚生子后就不能再从事技术了，所以，她们也对技术行业的未来没有信心。Myma在来信中说：“女人做技术最怕就是世俗的偏见，尤其是过了30，生了孩子，明显感觉出来了，职业瓶颈”。 召娣说：“面试的时候会问有没有男朋友，下一步会不会结婚，接下来就是会不会要孩子之类的”，几乎所有的女程序员都在说这个事。

• 自大的男程序员看不起女程序员。女程序员在工作中受到太多的不公平的待遇了。就连平时男程序员们都以一种高人一头的语气和她们说话。这样的例子太多了，在我blog中的回复中，在平时，我们都可以看得到。而我们的大多数的女性都会因为别人看不起而失去信心。当然，这点男程序员也一样，因为技术好的人总是会看不起技术不好的人。这是技术人员的通病。冰在来信中说：“另一个困扰的问题是，可能女生少的原因，在本部门风言风语不断，给我个人生活不少的精神压力，平时同事也会半开玩笑的说，嫁了吧，写什么代码，而且跟一些比较资深的程序员聊天时，总会呵呵的轻笑，然后说你是程序员啊。。。部门一些杂务，通常都扔了给我处理，这个我觉得吃点亏也没什么大事，但是就是忍受不了那种受轻视的感觉”。Cathy说：“项目组的组长是一个博士，人很好但是不太会和女孩子打交道，或者说有一些性别歧视吧。”

女程序员的故事

下面的故事，都是原文，没有经过任何编辑。下面的故事，很多也很长，她们串成了一个非常美丽的风景线，我真的希望你有空能读一读这些故事。你会发现这些故事都有我们自己的身影。

真的非常感谢大家对我的信任，给我发来这么多的故事，谢谢你们的支持。我完全相信——

程序员因为女孩而美丽！

女程序员们，为你们骄傲，祝你们2012年更上一层楼。

（另外，请各种网站、媒体，报刊，杂志，自由转载或是选取其中的故事做为你们的素材）

您可能也喜欢：
程序员的八个级别	惹恼程序员的十件事	C++ 程序员自信心曲线图	漫画：程序员的一生	别的程序员是怎么读你的简历的
无觅

相关文章

• 2012年01月30日 -- 软件开发的“三重门”
• 2011年12月30日 -- 一个女程序员的故事
• 2011年12月20日 -- 三个事和三个问题
• 2011年11月15日 -- 来信， 创业 和 移动互联网
• 2011年10月25日 -- 多些时间能少写些代码
• 2011年10月20日 -- Stay Hungry, Stay Foolish ！！
• 2011年09月21日 -- 如果你看不见你还能编程吗？

本来，我想通过收到的这些故事然后编辑成一篇关于女程序员的文章，但是我觉得这个故事已经足够好了，任何的编辑都是对这个故事的不尊重，所以，我原封不动，一字不改地把这个故事转到这里。我把一些我认为精彩的地方加了粗。

当然，我还是会再写一篇关于女程序员的文章，酷壳2011年底的最后篇文章和2012年的第一篇文章都是给女程序员的，因为，我为你们骄傲！

从哪里说起呢，我的程序员之路。有些话只是自己心里想的很明白，还从没说过。希望你有耐心看完，因为我的故事不精彩，也算不上奋斗史。我的文笔和叙事能力也很差。

高中报志愿的时候坚定的报了计算机技术及应用，当时对计算机的认识只是机房里的苹果机，和老师教的用basic 输出一个正方形之类的。 我当时觉得我对计算机一无所知，我想了解他，就选择了这个专业，当然当时程序员的收入也是可观的。 ：）

大学四年下来，我的成绩不好，基础也不好，没拿过奖学金。大学的课程很多不喜欢，我不知道为什么计算机系还要学高等物理，和马列毛邓。这是题外话。说实在的，很多课上的我一头雾水。毕业后找工作不满意，我直接去读了软件工程（考研的专业课成绩没到线）。两年制，一年上课，一年实习。我想给自己的履历上增加一些至少能给我面试机会的经历。（我仔细思考过我成绩不好的原因，心里因素是主要的，高中在重点中学，我不能接受自己不是尖子生的事实，总在想自己为什么这么差，以至于这样的心情影响了我很多年，一直到工作后的几年）

实习的第一家公司是个私企，工作两周后他们不满意辞退了我，沮丧是当然的，我知道我的能力是有差距的。虽然他们没有任何培训，直接拉去干活，起码的业务流程也没给我讲，但是我真的发自内心感谢他们辞了我，让我认清了自己。其实当时干的就是一些perl 脚本和php的网页开发。

实习的第二家也是私企，给运营商做项目。我参加的是一个工作流项目，用java开发。我当时的java技术仅限书本身的不怎么牢靠基础知识，至于怎么设计这个系统也没有一点概念，终于一个月后我决定退出了。经过这一个多月，我似乎知道了自己该从哪里开始了。就从java开始吧。

经同学介绍，去了第三家实习公司，面试的经理对实习生要求不高，让我能有机会实习。做的是银行和证券公司的网站，我主要做前端jsp的页面，同时我也选修了学校请的一位Weblogic的工程师开设的J2EE的课程。总算开始入门了。公司的同事很帮助我，有耐心让我了解了系统后台的架构。后来我随几位去客户那里出差，周末和晚上加班，为了他们临时改的需求。同事说，你一个女生出差一点不发憷啊。其实我一点不觉得累。同组的team lead没事就鞭策我说，你就甘心写code么，不能总是做开发，该为以后想想。但是我当时想法是，我的视野当时有限，还不确定自己能做成什么样子。我在这家公司完成了毕业论文。然后毕业。

毕业找工作，我没有留在实习的公司，我想多试试。找工作的经历不多，我去过联想面试，笔试过了，一面是HR面，题目现在大概还记得，如果有化学家，天文学家，医生，乞丐，孕妇，在一个荒岛上，你只能带走一个，你带走谁呢？分组讨论，得出一致的结论，也要说出自己的结论。 同组有清华的毕业生，真的很自信，她说要带走天文学家。我说，出于人道，我肯定带走孕妇。后来就没了消息。难道医生可以留下照顾孕妇么，还是HR以为我选孕妇是注重家庭的人，没有事业心呢，我觉得这题真的不能说明什么。

之后面试了一家日资企业，一面是很多人一起面，我听了一圈之后，觉得自己有些把握，因为同组的人比我差，看来我运气挺好的。他们之中有本科生，有研究生，都是男生，就我一个女生。问的也挺基础，就是servlet如何工作，写没写过SP，其中有个人问，什么是SP，没人理他，我告诉他是store procedure。面试官是个部长。后来HR的人过来让我留下二面，说我一面打败了所有男士。说来惭愧，我真的是运气好，没碰到牛人。二面经理只问了些平常的问题，就过了，于是我来到这家工作。考虑的是，外企多少工作流程上比较规范，也见见日本人是怎么工作的，还有就是自己能力有限，欧美大公司估计是没戏的，我还是从力所能及的开始吧。

日本人工作的风格大家应该有所耳闻，就是喜欢加班，我进公司的第一个项目是代码改造，把VB6.0d code重写为VB.net。 加班到凌晨是常事，另外一个就是team lead的风格是没事也不能早走，也得耗到半夜才行。开始做的真是一点技术含量都没有，都是日本人写好guide，告诉你什么改成什么，别问为什么，不能有异议，他们怎么说你怎么改。弄得我当时都不去思考这里的技术细节，这是我当时犯傻的表现。除了技术本身，还有很多需要学习的。后来陆续做了一些我喜欢的java的项目，用到了sping，hibernate，ibatis, struts, ant等等。还有一些日本人自己开发的框架。每个项目的业务也都不同。在这家工作了三年，我觉得这不是我要的，我的技术提高有限，做的事都是别人设计好，甚至告诉你code应该如何写，而且做事风格不是我想要的。 我想去欧美文化的公司试试。也想做通讯相关的。

同学帮我投简历，我面试一家对欧美的外包企业，一面是本公司的人面，问了项目情况，说了说英语，我准备还算充分，过了，二面是公司的客户面，到公司和客户开电话会议面试，第一次和老美直接对话，我虽说有点紧张，但是还是专心听他的问题，听不清的就让他重复一遍，我现在记得的一个问题是如何写出高效的SQL。面完回家等通知。过了几天我收到了offer。

客户是为运营商提供软硬件服务。我们做的是BOSS系统的一个模块。都是java api。 几乎用到了J2EE中定义的所有组件和java相关的框架。我在这家工作至今。技术从不熟悉到熟悉，业务逻辑从不熟悉到熟悉，都是在开发每个feature和改的defect中慢慢了解的，硕大的系统不允许我一口吃个胖子。只要脑子里绷根弦就每天都有进步。加班不是常事，但是也有紧张的时候。 有时候一个defect要跟踪成千上万行代码，你才知道哪里出了问题，这是需要耐心和细心的。给客户的客户做support的时候，经常被半夜的电话叫醒去看一个现场的问题，我不觉得累和烦，我觉得这是我价值的体现（当然这不会每天发生）。修复一个defect我会有一点小小的成就感，每天晚上回家方便的话也会看看邮箱，看看有没有紧急的事情。有的人认为你下班了就没必要再管工作邮箱了，但是我愿意这么做，我觉得这是我职业精神的一部分，也是工作态度。

偶尔会帮着公司招聘毕业生，有时候会遇到什么简单问题都答不上来的人，我感觉就像看见当初刚毕业的我，临走，我会说一句，没关系，回去好好准备，看看基础知识。

我曾经怀疑过自己是否适合做技术，总觉得自己不如男生，也总在问自己的路在哪。而且没有自信，曾经紧张到，有人看我打字，都紧张的手抖。到现在，我觉得做技术挺好，就像你说的，我清楚的认识自己，我不是技术大牛，就每天写着自己的code，了解业务，挺好，但是不代表我不上进。很多女同学现在都不做技术了，也不写code了，但是我还在做，甚至越来越喜欢，在中国有种普遍的想法是，作几年技术该转去做管理，否则认为你不成功，这是人云亦云的说法。我想我为什么不能一直做技术呢？虽然中国的大环境可能不适合你一直做技术，但是我愿意试试。我不愿意放弃多年来积攒的一点点优势。何况我现在工作上越来越得心应手，不久前，我收到客户的邀请，他们想让我transfer到美国或者加拿大成为他们的一员，我在等待漫长的人事流程，也有可能会pending。但是我无所谓，我现在自信，知道想要什么。一直做技术，怎么了，不行么？

谈到男女程序员的问题，有些男人以技术强自居，而少了一点谦逊和工作的严谨。有些技术不强的，有些懒散，得过且过。都是我遇到过真实的人。同组的一个女生来了几个月就比一个来了一年多的男生上手快，这说明什么的，态度和努力是重要的。我更认同的是技术和男女无关，和个人有关，任何以偏概全都是片面的。

同组的男同事们没有因为我是女性而轻视我，我很感谢他们，在一个team工作，技术是必要条件不是充分条件，合作，交流，态度，遵守流程，任何一个都缺少不了。如果我只是技术差点，那么我提高的空间是很大的。 多看看书，真的不难。虽然我可能离amazon或者是google这些企业的要求还有差距，但是那是我的方向。不过像baidu，腾讯这些流氓公司，给我多少钱也不去，女程序员也是有傲骨的，虽然也有可能他们看不上我的能力，但是，那又有什么所谓呢。

如果你能看完我这如白开水的文字，很感谢，因为我写的实在太不好了，这些经历普通不过，也证明我是个普通的人，如果我高中的时候不那么在意自己是不是优秀生，就能放轻松，大学（也在想这些）会有个好成绩，没准我就能如愿的毕业就进欧美大企业，不过那样我可能也少了以上跌入谷底的经历和现在平和的心态，我想后者对我更有意义。

不用署名，有的话，一个女程序员，哈哈。有错误处，见谅，中午休息，仓促的回顾了这些。技术本身心得有限，我就不班门弄斧了，还需努力。也请不要注我的微薄行号啦。另外我老公也是程序员，我和他能谈些技术和项目上的事情，我想是非女程序员感受不到的乐趣，哈哈哈。

看到这里你还不想为她鼓掌吗？

最后，请让我我再次征集——

call 所有的女程序员，我想给你们写一篇blog，希望你们能和我分享你们的程序员的经历和技术心得。你是男程序员也没有问题，也欢迎分享你身边女程员的故事。 大家可以发邮件至：haoel(at)hotmail.com

（全文完）

您可能也喜欢：
漫画：程序员的一生	别的程序员是怎么读你的简历的	程序员版的凡客	优秀程序员的十个习惯	惹恼程序员的十件事
无觅

相关文章

• 2012年01月30日 -- 软件开发的“三重门”
• 2012年01月04日 -- 程序员因为女孩而美丽！
• 2011年12月20日 -- 三个事和三个问题
• 2011年11月15日 -- 来信， 创业 和 移动互联网
• 2011年10月25日 -- 多些时间能少写些代码
• 2011年10月20日 -- Stay Hungry, Stay Foolish ！！
• 2011年09月21日 -- 如果你看不见你还能编程吗？

背景

某日临近下班，一个同事欲取任何类中获取项目绝对路径，不通过Request方式获取，可是始终获取不到预想的路径。于是晚上回家google了一下，误以为是System.getProperty(“java.class.path”)-未实际进行测试，早上来和同事沟通，提出了使用这个内置方法，结果人家早已验证过，该方法是打印出CLASSPATH环境变量的值。

于是乎，继续google，找到了Class的getResource与getResourceAsStream两个方法。这两个方法会委托给ClassLoader对应的同名方法。以为这样就可以搞定(实际上确实可以搞定)，但验证过程中却发生了奇怪的事情。

软件环境：Windows XP、Resin 3、Tomcat6.0、Myeclipse、JDK1.5

发展

我的验证思路是这样的：

1. 定义一个Servlet，然后在该Servlet中调用Path类的getPath方法，getPath方法返回工程classpath的绝对路径，显示在jsp中。
2. 另外在Path类中，通过Class的getResourceAsStream读取当前工程classpath路径中的a.txt文件，写入到getResource路径下的b.txt。

由于时间匆忙，代码没有好好去组织。大致能看出上述两个功能，很简单不做解释。

public class Path {
    public String getPath() throws IOException
    {
        InputStream is = this.getClass().getResourceAsStream("/a.txt");
        File file = new File(Path.class.getResource("/").getPath()+"/b.txt");
        OutputStream os = new FileOutputStream(file);
        int bytesRead = 0;
        byte[] buffer = new byte[8192];
        while ((bytesRead = is.read(buffer, 0, 8192)) != -1) {
            os.write(buffer, 0, bytesRead);
        }
        os.close();
        is.close();
        return this.getClass().getResource("/").getPath();
    }
}

public class PathServlet extends HttpServlet {
    private static final long serialVersionUID = 4443655831011903288L;
    public void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException
    {
        Path path = new Path();
        request.setAttribute("path", path.getPath());
        PrintWriter out = response.getWriter();
        out.println("Class.getResource('/').getPath():" + path.getPath());
    }

    public void doPost(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException
    {
        doGet(request, response);
    }
}

在此之前使用main函数测试Path.class.getResource(“/”).getPath()打印出预想的路径为：/D:/work/project/EhCacheTestAnnotation/WebRoot/WEB-INF/classes/

于是将WEB应用部署到Resin下，运行定义好的Servlet，出乎意料的结果是：/D:/work/resin-3.0.23/webapps/WEB-INF/classes/ 。特别奇怪，怎么会丢掉项目名称：EhCacheTestAnnotation呢？

还有一点值得注意，getPath方法中使用getResourceAsStream(“/a.txt”)却正常的读到了位于下图的a.txt。

然后写到了如下图的b.txt中。代码中是这样实现的：File file = new File(Path.class.getResource(“/”).getPath()+”/b.txt”);本意是想在a.txt文件目录下入b.txt。结果却和料想的不一样。

请注意，区别还是丢掉了项目名称。

写的比较乱，稍微总结下：

程序中使用ClassLoader的两个方法：getResourceAsStream和getResource。但是事实证明在WEB应用的场景下却得到了不同的结果。大家别误会啊，看名字他们两个方法肯定不一样，这个我知道，但是getResourceAsStream总会获取指定路径下的文件吧，示例中的参数为”/a.txt”，正确读取“/D:/work/resin-3.0.23/webapps/EhCacheTestAnnotation/WEB-INF/classes/ ”下的a.txt，可是将文件写到getResource方法的getPath返回路径的b.txt文件。两个位置的差别在项目名称(EhCacheTestAnnotation)。

这样我暂且得出一个结论：通过getResourceAsStream和getResource两个方法获取的路径是不同的。但是为什么呢？

于是查看了ClassLoader的源码，贴出getResource和getResourceAsStream的源码。

public URL getResource(String name) {
    URL url;
    if (parent != null) {
        url = parent.getResource(name);
    } else {
        url = getBootstrapResource(name);
    }

    if (url == null) {
        url = findResource(name);
    }
    return url;
}

public InputStream getResourceAsStream(String name) {
    URL url = getResource(name);
    try {
        return url != null ? url.openStream() : null;
    } catch (IOException e) {
        return null;
    }
}

从代码中看，getResourceAsStream将获取URL委托给了getResource方法。天啊，这是怎么回事儿？由此我彻底迷茫了，百思不得其解。

但是没有因此就放弃，继续回想了一遍整个过程：

1. 在main函数中，测试getResource与getResourceAsStream是完全相同的，正确的。
2. 将其部署到Resin下，导致了getResource与getResourceAsStream获取的路径不一致。

一个闪光点，是不是与web容器有关啊，于是换成Tomcat6.0。OMG，“奇迹”出现了，真的是这样子啊，换成Tomcat就一样了啊！和预想的一致。

在Tomcat下运行结果如下图：

对，这就是我想要的。

因此我对Resin产生了厌恶感，之前也因为在Resin下程序报错，在Tomcat下正常运行而纠结了好久。记得看《松本行弘的程序世界》中对C++中的多继承是这样评价的(大概意思)：多重继承带来的负面影响多数是由于使用不当造成的。是不是因为对Resin使用不得当才使得和Tomcat下得到不同的结果。

最终，在查阅Resin配置文件resin.conf时候在<host-default>标签下发现了这样一段：

<class-loader>
        <compiling-loader path="webapps/WEB-INF/classes"/>
        <library-loader path="webapps/WEB-INF/lib"/> 
</class-loader>

其中的compiling-loader很可能与之有关，遂将其注释掉，一切正常。担心是错觉，于是将compiling-loader的path属性改成：webapps/WEB-INF/classes1，然后运行pathServlet，b.txt位置如下图：

确实与compiling-loader有关。

结论

终于通过将<class-loader>标签注释掉，同样可以在Resin中获取“预想”的路径。验证了的确是使用Resin的人出了问题。

疑问

/**
* Class	loader which checks for changes in class files and automatically
* picks up new jars.
*
* DynamicClassLoaders can be chained creating one virtual class loader.
* From the perspective of the JDK, it's all one classloader.  Internally,
* the class loader chain searches like a classpath.
*/

// List of resource loaders
private ArrayList _loaders = new ArrayList();
private JarLoader _jarLoader;
private PathLoader _pathLoader;

ClassLoader loader = PathServlet.class.getClassLoader();
while (loader != null) {
    System.out.println(loader.toString());
    loader = loader.getParent();
}

/**
* Gets the named resource
*
* @param name name of the resource
*/

public URL getResource(String name)
{
    if (_resourceCache == null) {
        long expireInterval = getDependencyCheckInterval();
        _resourceCache = new TimedCache(256, expireInterval);
    }

    URL url = _resourceCache.get(name);
    if (url == NULL_URL)
        return null;
    else if (url != null)
        return url;

    boolean isNormalJdkOrder = isNormalJdkOrder(name);

    if (isNormalJdkOrder) {
    url = getParentResource(name);
    if (url != null)
        return url;
    }

    ArrayList loaders = _loaders;
    for (int i = 0; loaders != null && i < loaders.size(); i++) {
        Loader loader = loaders.get(i);
        url = loader.getResource(name);

        if (url != null) {
            _resourceCache.put(name, url);
            return url;
        }

    }

    if (! isNormalJdkOrder) {
        url = getParentResource(name);
        if (url != null)
            return url;
    }

    _resourceCache.put(name, NULL_URL);
    return null;
}

boolean isNormalJdkOrder = isNormalJdkOrder(name);

（全文完）

您可能也喜欢：
Resin服务器getResource揭秘	JAVA的字符串拼接与性能	Java EE6 初探	Java构造时成员初始化的陷阱	Java书籍Top 10
无觅

相关文章

• 2012年01月05日 -- Resin服务器getResource揭秘
• 2012年01月06日 -- Hash Collision DoS 问题
• 2011年10月31日 -- API设计：用流畅接口构造内部DSL
• 2011年10月14日 -- 那些曾伴我走过编程之路的软件
• 2011年08月01日 -- 你确信你了解时间吗？
• 2011年07月18日 -- 程序员技术练级攻略
• 2011年06月29日 -- 语言的数据亲和力

其实，CSDN明文密码并不是什么稀奇的事情，我是2000年注册CSDN的吧，当时找回口令的机制就是把口令直接传回来了，这一定是明文了。去年去CSDN参加移动互联网沙龙的时候，范凯和蒋涛说过明文密码的事，不过他们说的是很早以前的事了，而且一笔带过了。1年后的今天，事情又暴了，可见，“出来混的，迟早是要还的”这句话是几近真理的。

我在以前的BLOG里就提到过CSDN的明文密码（在“如何设计用户登录功能”一文）和 帐号泄露（“如何设计自己的口令”） 的事（由此可见，酷壳里的很多文章里的事都应验了，因为我知道“出来混的，迟早是要还的”）

（可悲吧？还是程序员的网站呢，明文口令和用户信息泄露有悖于一个程序员网站的称号）

泄露的密码分析

我昨晚下载了www.csdn.net.sql文件，并分析了一下这个文件，经过各种awk, grep, sort, uniq, sed后，下面是我看到的东西：

• 有近45万的用户使用 123456789 和 12345678 做口令。
• 有近40万的用户使用自己的生日做口令。
• 有近15万的用户使用自己的手机号做口令。
• 有近25万的用户使用自己的QQ号做口令。
• 设置成弱口令的用户占了590万，也就是那种就算你用MD5或是SHA散列的也能很快就被暴力破解出来的口令。
• 只有8000多个用户的口令里在8个长度以上，并有大写字母，小写字母，数字，并不在字典表里。

（很好，这回泄露的还不单单只是明文用户密码和用户邮件，还有用户的手机号，生日和QQ号。挺好的）

下面，我们来看一下top 100的口令是什么？（第一列是采用这个密码个数，第二列是密码，我擦 dearbook是什么啊）简单地看了一下，top 一万的口令都很SB。比如什么woshishui, 123abc, aaa123456，01010101，haohaoxuexi，msconfig 相当的2B，还有P@ssw0rd，q1w2e3r4t5，看似文艺，实际很2的口令…. （可悲吧？还是程序员的网站呢，自己设的口令有悖于一个程序员的称号）

235033 123456789
212751 12345678
76346 11111111
45902 dearbook
34953 00000000
19986 123123123
17791 1234567890
15033 88888888
6995 111111111
5966 147258369
5553 987654321
5459 aaaaaaaa
5145 1111111111
5025 66666666
4435 a123456789
4096 11223344
3667 1qaz2wsx
3649 xiazhili
3610 789456123
3497 password
3281 87654321
3277 qqqqqqqq
3175 000000000
3143 qwertyuiop
3094 qq123456
3077 iloveyou
3061 31415926
2985 12344321
2886 0000000000
2826 asdfghjkl
2797 1q2w3e4r
2580 123456abc
2578 0123456789
2573 123654789
2540 12121212
2515 qazwsxedc
2396 abcd1234
2380 12341234
2348 110110110
2298 asdasdasd
2243 22222222
2166 123321123
2160 abc123456
2145 123456
2138 a12345678
2113 123456123
2106 a1234567
2100 1234qwer
1989 qwertyui
1986 123456789a
1971 aa123456
1918 asdfasdf
1891 99999999
1859 999999999
1859 123456aa
1854 123456123456
1699 520520520
1656 963852741
1652 741852963
1652 55555555
1589 33333333
1480 qwer1234
1384 asd123456
1339 77777777
1316 qweasdzxc
1285 code8925
1273 11112222
1268 ms0083jxj
1245 zzzzzzzz
1214 111222333
1206 qweqweqwe
1200 3.1415926
1183 123456qq
1148 147852369
1136 521521521
1121 asdf1234
1111 123698745
1109 1123581321
1058 asdfghjk
1054 q1w2e3r4
1038 12345678a
1003 woaini1314
991 1234abcd
988 123qweasd
975 1qazxsw2
967 woaiwojia
920 321321321
910 05962514787
894 123456987
892 kingcom5
882 zxcvbnm123
882 5845201314
853 0987654321
847 wwwwwwww
835 11111111111111111111
805 12345600
783 11235813
777 1q2w3e4r5t
772 10101010
770 123456asd

老生长谈安全问题

从酷壳出现开始我就在老生长谈用户安全的东西了，今天借着这个事，大家再去重温一下酷壳的文章吧：

• Twitter禁用的口令。看看去吧，一个好的网站应该如何引导用户设置强口令。Apple ID也是这样，需要你输入的口令有大小写，数字，非数字和字母，等等。今天CSDN的这个列表应该成为各大网站“口令禁用列表”。

• 有朋友说，明文口令是巨2的一件事，是的。我可以告诉你，这个明文口令有可能存在于所有国内的网站上，比如：QQ，新浪，人人，开心，天涯……。对于安全问题，你要做最坏的假设，鲁迅先生说过：“不惮以最坏的恶意来推测中国人”，所以，对于中国的网站你要做如下最坏假设：1）其以明文存我的口令，2）其内部不良员工会把我的信息泄露出去。不信你可以看看下面的某QQ群里的截图：（看看多玩网明文口令的消息吧，再看看这个消息吧 QQ邮箱和QQ号的）

• 你可能会说用MD5和SHA散列口令就好了，这个只比明文好一点点，因为有rainbow table，国外的号称达到99%覆盖，国内的达到93%覆盖。你加salt也没有用。就算我只能拿得到你的被散列的密码，没有rainbow和salt，我一样可以使用暴力破解，甚至就是尝试一下字典里的密码就可以了。这会非常快的，你可以看看本站的这篇文章“破解你的口令”，现在暴力破解MD5和SHA的口令很快的，因为MD5和SHA性能太好了。所以，你需要看看“如何防范密码被破解”，其会告诉你加密口令要用一个性能差的算法——bcrypt。（也可以参看Web开发中需要了解的东西中的如何安全保存口令一文）

• 所以，你有必要地读一读我的这篇“如何管理和设计自己的口令”，不要在同一网站上使用相同的口令，把口令的级别分好的组。自己管理好自己的口令。

•  对于Web用户的安全问题，程序员们一定要看一下 这两篇文章，你要是不看的话，你没有资格开发Web项目。
• 如何设计用户登录功能
• Web开发中需要了解的东西

• 当你看过 如何设计用户登录功能 一文后，你一定会头晕的，所以，我想告诉你，这种事情最好不要自己干，使用OpenID 和 OAuth吧，人家把这事干到了极致了。而且这样会带来两个好处：
• 用户不需要自己维护和管理一套新的帐号。
• 用户的资料放在国外，从政治上来说是安全的。（八卦一下：Google总部要求中国谷歌所有开发团队不得在本地保存用户的信息）

• 再说一点，再说说如何让自己内部的用户数据不会被不良员工外泄。所有的开发团队都不允许直接操作用户的数据库，只允许通过安全的接口来验证用户，用户信息的数据库中需要对操作者有审计功能，永远不允许不受信的人或操作进行全库扫描。当然，我相信，国内的开发团队绝对达不到这一步（包括某些银行）。

• 再说一下，真正的安全系统是协同整个社会的安全系统做出来的一道安全长城，而不是什么都要自己搞。比如：通过很多方法“耦合”和银行和电信其是别的第三方的安全策略，比如，让用户绑定邮箱，绑定手机，绑定信用卡等。

最后说一下，CSDN在这次事件的表现看上去还是很不错的，道歉也很诚恳，但是，我还是希望CSDN反思一下为什么数据库会泄露了？内部有不良员工？还是系统不安全被黑？不要只是诚恳道歉，还要找自己的原因。其它的网站可能就很恶劣了。包括新浪，人人，开心等，最恶心的就是腾讯，你说他的安全有问题，他还找一堆人来骂你。

祝大家新年快乐！

（全文完）

您可能也喜欢：

如何管理并设计你的口令

破解你的口令

Twitter的禁用口令

另类UX让你输入强口令

如何防范密码被破解

无觅

相关文章

• 2011年08月25日 -- 你会做Web上的用户登录功能吗？
• 2011年03月03日 -- 另类UX让你输入强口令
• 2011年03月02日 -- 破解你的口令
• 2010年05月20日 -- Twitter的禁用口令
• 2010年05月18日 -- 如何管理并设计你的口令
• 2010年02月01日 -- 如何防范密码被破解
• 2011年01月27日 -- 如何“加密”你的email地址

注：这篇文章里的所有的故事都是真实的，其不可避免地会加上我强烈的个人情怀和个人色彩，叙述的过程可能比较乱，但我能确保这些都是我的肺腑之言。

第一个事：网友的来信

第一个故事是一个杭州的学生的故事，其有两个offer，一个是北京的（雅虎研发中心），另一个是杭州的一个做商业智能软件的公司，也是美国的上市公司。他在给我的来信内心纠结地说：

雅虎其实很想去，虽然这几年雅虎走下坡，但还是大公司，牌子硬，里面牛人也多，有助于自己水平的提升。但感觉北京环境不好，生活不是那么舒坦，也搞不定户口，所以我去的话也只能干个三五年就得考虑跳槽到别的城市安家落户了。这么一跳，在北京积累的各种资源却又带不走 。

杭州，比北京更适合生活，户口不是问题，朋友多，这个公司也比较宽松，有较多的业余时间跟朋友们一起搞点东西。而且这些年这个公司上升的势头，在国内设研发中心也才4年，规模不大，公司本身规模也还不大，我觉得机会还不错。再加上离家近，对家人大概可以多些照应。

关于未来换工作，雅虎做的是搜索，广告，移动互联这几个方面的，东西在互联网企业里面都比较通用，以后跳槽的话，面相对比较宽。杭州的那个做商业智能的公司，据了解其他做的比较好的也就几个大公司如SAP，IBM有这方面的业务。

我和这个同学发了邮件，也打了长途电话，我基本上是这样回复的——

1）户口，离家近，安逸的生活，相比起你的人生经历，你的眼界，你的发展，什么都不是。千万不要让户口限制了你的人生，如果要过安逸轻松的生活，最佳方案是进政府部门，既然要活在体制外，就一定是靠能力，靠经历，一定要有好的经历和能力。

2）眼界，眼界，眼界。这是我们这个国家里的人最需要的东西了，你的眼界决定了你的人生。我对杭州的这家公司一无所知，但是我知道雅虎的一些好处：a）互联网企业，其天地明显要比BI广阔很多，b）技术强，能人多（看雅虎的面试的难度以及一些产品就知道了），c）外企，可以练英语。d) 跨国公司，可以开眼界，或许会有出国机会。e）北京，几乎所有的知名公司都在这里有基地，这里的技术氛围在全国数一数二。为了经历和眼界，辛苦几年又有何妨？！人生还是需要有激情的。

3）经历，经历，经历。问自己一下，我们会在毕业的第一份工作呆上一辈子吗？不会吧。就算不喜欢北京，就算雅虎这个公司并不完美，但是雅虎的经历，能为你开启一个更为广阔的天地。

4）我认为一个有过几乎失败经历的公司会更牛。Apple被打趴下过，Amazon也被打趴下过，只有被打趴下过而又能站起来的公司和人才是真正伟大的。如果Yahoo还能站起来，它一定会是一个伟大的公司。

小伙子是个很聪明的人，也是个对生活有激情的人，所以，最后毁了“三方”选择了雅虎。他说：

最终选择雅虎的原因是，我觉得趁早年轻先出去看看，北京还是一个开阔视野的好地方。我要是一开始就选择杭州，以后估计不太会出去了，人生短暂，我还是希望多经历一些多体会一些。我从不畏惧在北京是否有户口，那里的房价是否承受的起，我觉得一个刚毕业的学生没必要太多的考虑这些问题，最重要的是考虑自己的发展。

而我的心情却有些复杂，一方面，我觉得一个人的一生可能就此被我改变了，我的心里很复杂。另一方面，万一他来北京不是很顺怎么办？会不会说我骗了他？在这里，我想对这个朋友说——“保持你的热情，努力开你的眼界，努力提高你的能力，你不可能走得不好的，就算雅虎有一天倒下了，也会有很多个更好机会等着你的，我会一直在你身边帮助你的”。

这样的来信还有很多很多，户口，薪资，是否去大城市，几乎都成了大家考虑的重点。这个年代实在是太浮躁了。我在此想告诉大家，对于你的人生你应该把“和什么样的人做什么样的事”提到你择业优先级最高的地位，没有之一。我的答案是，“和有激情能做事的人做有意义的事”。

生活在如此刺激的年代，一定要去经历那些最刺激最有意义的东西，这样人生才会变得有意义。

第二个事：Amazon的校园招聘

在Amazon校招的其间发生了一些有意思的事，比如：

1）在哈尔滨校招过后，我被公司里的一些同事亲切地称为“体型魁梧的男子”，呵呵。希望这位同学毕业的时候还能来Amazon面试，这样，我就能再“虐你一次”。哈哈。

2）这次Amazon的校招在北京，天津，西安，武汉，哈尔滨等地进行了招聘，大家知道我们用什么面试题来面这些快毕业的学生吗？我们用面试高级程序员的问题来面试这些刚毕业的学生（我和我的团队里的那些高级程序员说：“你们应该庆幸你们面试的时候没有被回这些问题”）。你知道我们有什么样的收获？主要有两点收获：

• 武汉的学生太给力了。你们的能力超出了所有其它城市的学生，包括北京。这让我们很诧异，搞得我们几个经理都在思考是不是要去武汉建Amazon的研发分部去了。我个人的分析是：武汉属于中心城市和北京等大城市的沟通相当地好，在这里的学生和在北京的学生有一样的眼界和技术氛围，但却没有在大城市的同学们的浮燥，能踏下心来专研技术。

• 学C++的同学比学Java的同学解决问题的能力更强。因为两个原因，a) C++需要了解系统知识，b) C++的程序员几乎什么事都得自己干。（参看我的《如何学好C语言》和《如何学好C++语言》，当然，Java还是很牛的，比如OO方面）

3）有一个同学接受了Amazon的offer后，给我来信诉说，给他打电话的经理告诉他要做的是测试为主的工作。然后，他给我发邮件来和倾诉，我说，如果你不喜欢，你就要说出来，不要将就，将就出来的人生只会平添许多烦恼和后悔。在此，我想在这里澄清两个事：

• Amazon不会强行把你分配到团队中，只要你有想去的团队，你就应该说出来。我们一开始会内部做分配，这样做只是为了效率，但是这并不代表你已经被最终分配到那个团队中去了，无法再调整了。只要你提出来你想做什么。我们会把你的要求放在第一位，并尽最大的可能满足你的要求。相信经理们给你们电话的时候都说过这样的内容了。

• Amazon所有的“蓝卡员工”（在Amazon工作5年以内的员工）在工作满一年后，可以有条件地在Amazon内部transfer。条件只有一个：你的工作业绩要很不错，在相同级别的员工中是中坚力量。你可以直接申请其它团队的招聘职位（这个其它团队包括了美国总部在内的全世界的团队），经过流程简单的面试就可以正式transfer。没有人可以阻止你，那怕是Jeff Bezos也无权阻止你。（这个政策要比北京户口更有价值吧？！Think it Big!）

4）最后一个有关校园招聘的事发生在我的团队。我觉得我可能要失去这个获得offer的学生了。他在腾讯和亚马逊之间更倾向于腾讯，因为他在腾讯实习过。他一开始的理由主要是，一个是户口问题，腾讯可以解决户口，另一个是他想做底层的C/C++，而不是Java。后面的理由又转变为腾讯的团队文化，等等。

我已经给他打过两次电话了，也和他说过许多，和第一个故事里说得差不多。对于是否做C/C++还是Java这方面的事，他和我说，他想在某一个领域成为一个专家。我对他说的这个专家有些模糊，我只是和他说——“软件的精髓不在于你对系统底层有多了解，也不在语言层面，而是在于设计和架构，而设计和架构这种东西只能靠多想多看”，我和他说，Amazon不是一个喜欢分享的公司，Amazon内部很多技术和设计水平可能是外部的人无法想像的。我希望他能来我的团队和大家工作一段时间真正感受一下，再做打算。（当然，要是他不明白这些事，我也觉得他不来也没有什么可惜的）

另外，我想对所有的人说：“这个世界上有两种公司，一种是“劳动密集型”的公司，另一种是“知识密集型”的公司，很多公司把软件做成了一种“劳动密集型”的活动，在那里永远无法做出能够让业界所震撼的东西，而有的公司才能把其做成“知识密集型”的公司，在那里，你会看到世界因为他们而改变”。如果你不能理解这句话的话，你不妨想像一个网上卖书的的公司干出连Google都赶不上的“平台”（参看“Steve Y的Amazon和Google平台论”），你不妨想像一个做MP3播放器的公司可以改变唱片业乃至改变世界。

不管这位同学最终能不能成选择我的团队的一员，我都会送你一本《Steve Jobs》，额外，我还会送你一件我团队自己制作的T恤（见下图，谢谢我的HR Recruiter当模特）。

第三个事：朋友的跳槽

我有一个普通朋友，几个月前跳槽去了一家正在高薪挖人的国内的快要准备IPO的公司。他们开出的薪水和条件非常地诱人。给我这个朋友的开出薪水和那个职位诱惑力太大了。一般人都很难拒绝。但是，当他入职了以后，他发现了这个公司内有很多东西是相当恶心和让他无法接受的，这个公司就可能连“劳动密集型”的公司都不算，非常发不重视技术，在技术上做的东西相当地不规范，在那里的技术人员不但相当地苦逼，而且干的事相当的垃圾，出了问题，所有的团队都在互相推诿，管理非常混乱。这让我的那个朋友非常地难受，在那里的每一天都是一种煎熬，而且他无法改变，高管也很难改变这种局面。整个公司在一种疯狂地暗无天日的状态下工作。我对这个朋友目前的善感到担忧。

但是，我想借这个事来谈谈我的想法。我承认薪水和职位是一种价值，但是，人生的价值只有这个吗？你一年少了那几万块钱，你也穷不了，你多了那几万块钱，你也富不了，为什么不去追求那些比那几万块钱更有价值的东西呢？对于我来说，我觉得，最有价值的东西就是——能和那些有梦想有追求有能力的人一起去经历那些最有意义的事情，那些能够造福社会、改变世界、创造历史的事情。

我从我的上一份工作到现在的工作，我的薪水不但没怎么涨，只是执平，而我的职位还比上一家公司降了一级（而且我还放弃两年内职位还可能再次晋升的机会），我管的团队从4个团队减到了一个很小的5个人左右的团队（现在我坚持小的团队做大事）。我来Amazon之前，这个事让我整整思考了2个多月。最终我发现，职位和薪水这些对我来说都无所谓，因为我是做事的人，而只有有意义的经历才能真正喂饱我。而我目前在Amazon里做的这个事，是可能改变历史的事，是那种可以让我一想起来就会兴奋的事。

我知道，价值并不仅仅只是名利权，对此我只想说，不要把自己给卖了。

三个问题

其实，我还有很多故事可以讲，只不过我写得太多了，差不多到文章该结束的时候了。那些事改天再说吧。我经历的这些事让我思考了很多很多。每年年底都是我情绪比较低沉的时候，因为，这个时候是我反思一年中的得失的时候，在这个时间段里，我会有一些不安，那种我害怕已经虚度了这一年的那种不安。

2011年的年底，我问了我自己三个问题：

1）每天早上醒过来的时候，我会为什么感到兴奋？是什么在驱动着我去开始新的一天？

2）现在的经历有没有让我有这种兴奋的感觉？这种让我充满力量和期待的感觉？

3）有没有浮燥，有没有得到认可？身边的人的认可？但更重要的是自己是否对自己认可？

我把我自己的这三个问题共享给大家，我有我的答案，相信你也有你的答案。

在2011年的年底，我希望大家的2011年没有虚度，而2012年能经历那些有意义的的事。

提前祝大家新年快乐！

您可能也喜欢：
惹恼程序员的十件事	漫画：程序员的一生	程序员惯用的解释(Top 25)	未来五年程序员需要掌握的10项技能	优秀程序员的十个习惯
无觅

相关文章

• 2011年11月15日 -- 来信， 创业 和 移动互联网
• 2010年10月26日 -- 你和你的工作
• 2012年01月30日 -- 软件开发的“三重门”
• 2012年01月04日 -- 程序员因为女孩而美丽！
• 2011年12月30日 -- 一个女程序员的故事
• 2011年10月25日 -- 多些时间能少写些代码
• 2011年10月20日 -- Stay Hungry, Stay Foolish ！！

好了，下面是正文（我对原文做了一些批注，也许不对或有误导，请大家指正）

下面的这些东西可能对于大多数人并不陌生，但是可能会有些东西你以前并没有看过，或是没有完全搞懂，甚至都没有听说过。（陈皓注：我相信当你看完这个列表后，你会觉得对于我国的Web开发有点弱了，还是那句话，表面上的东西永远是肤浅的）

接口和用户体验

• 小心浏览器的实现标准上的不一致，确信让你的网站能够适当地跨浏览器。至少，你的网站需要测试一下下面的浏览器：
• 最新的 Gecko 引擎 (Firefox)，
• 一个 Webkit 引擎 (Safari, Chrome, 或是其它的移动设备上的浏览器)
•  IE 浏览器 (测试IE的兼容性你可以使用微软IE的 Application Compatibility VPC Images)
•  Opera 浏览器。

最后，你可以使用一下这个工具 来看看你的网页在不同的浏览器下是怎么被显示出来的（陈皓注：这个工具就是以前本站介绍过的在不同浏览器和平台上检查你的网站的兼容性）

• 多考虑一下人们是怎么来访问你的网站而不是那些主流的浏览器：手机，读屏软件和搜索引擎，例如：一些Accessibility的东西： WAI 和  Section508, 移动设备开发：MobiForge.

• 部署Staging：怎么部署网站的更新而不会影响用户的访问。 Ed Lucas的答案 可以让你了解一些（陈皓注：Ed说了一些如版本控制，自动化build，备份，回滚等机制）。

• 千万不要直接给用户显示不友好的错误信息。

• 千万不要把用户的邮件地址以明文显示出来，这样会被爬虫爬走并被让用户的邮箱被垃圾邮件搞死。

• 为用户的链接加上 rel="nofollow" 的属性以 避免垃圾网站的干扰。（陈皓注：nofollow是HTML的一个属性，用于通知搜索引擎“这个链接所指向的网页非我所能控制，对其内容不予置评”，或者简单地说，该链接不是对目标网站或网页的“投票”，这样搜索引擎不会再访问这个链接。这个是用来减少一些特定垃圾页面对原网站的影响，从而可以改善搜索结果的质量，并且防止垃圾链接的蔓延。）

• 为网站建立一些的限制 - 这个属于安全性的范畴。（陈皓注：比如你在Google注册邮箱时，你一口气注册超过两个以上的邮箱，gmail要求给你发短信或是给你打电话认证，比如Discuz论坛的会限制你发贴或是搜索的间隔时间等等，更多的网站会用CAPTCHA来确认是人为的操作。 这些限制都是为了防止垃圾和恶意攻击）

• 学习如何做 Progressive Enhancement. （陈皓注：Progressive Enhancement是一个Web Design的理念，如：1）基础的内容和功能应该可以被所有的浏览器存取，2）页面布局的应该使用外部的CSS链接，3）Javascript也应该是外部链接还应该是 unobtrusive 的，4）应该让用户可以设置他们的偏好）

• 如果POST成功，要在POST方法后重定向网址，这样可以阻止用户通过刷新页面重复提交。

• 严重关注Accessibility。因为这是法律上的需求（陈皓注：Section 508是美国的508法案，其是美国劳工复健法的改进，它是一部联邦法律，这个法律要求所有技术要考虑到残障人士的应用，如果某个大众信息传播网站，如果某些用户群体（如残疾人）浏览该网站获取信息时，如果他们无法正常获得所期望的信息（如无法正常浏览），那可以依据相关法规，可以对该网站依法起诉）。 WAI-ARIA 为这方面的事提供很不错的资源.

安全

• 在网上有很多关于安全的文章，但是 OWASP 开发指导 涵盖了几乎所有关于Web站点安全的东西。（陈皓注：OWASP(开放Web应用安全项目- Open Web Application Security Project)是一个开放的非营利性组织，目前全球有130个分会近万名会员，其主要目标是研议协助解决Web软体安全之标准、工具与技术文件，长期 致力于协助政府或企业了解并改善网页应用程式与网页服务的安全性。OWASP被视为Web应用安全领域的权威参考。2009年下列发布的美国国家和国际立法、标准、准则、委员会和行业实务守则参考引用了OWASP。美国联邦贸易委员会(FTC)强烈建议所有企业需遵循OWASP十大WEB弱点防护守则）

• 了解什么是 SQL 注入攻击 并知道怎么阻止这种攻击。

• 永远不要相信用户的输入（包括Cookies，因为那也是用户的输入）

• 对用户的口令进行Hash，并使用salt，以防止Rainbow 攻击（陈皓注：Hash算法可用MD5或SHA1等，对口令使用salt的意思是，user 在设定密码时，system 产生另外一个random string(salt)。在datbase 存的​​是与salt + passwd 产的md5sum 及salt。 当要验证密码时就把user 输入的string 加上使用者的salt，产生md5s​​um 来比对。 理论上用salt 可以大幅度让密码更难破解，相同的密码除非刚好salt 相同，最后​​存在database 上的内容是不一样的。google一下md5+salt你可以看到很多文章。关于Rainbow 攻击，其意思是很像密码字典表，但不同的是，Rainbow Table存的是已经被Hash过的密码了，而且其查找密码的速度更快，这样可以让攻击非常快）。使用慢一点的Hash算法来保存口令，如 bcrypt (被时间检证过了) 或是 scrypt (更强，但是也更新一些) (1, 2)。你可以阅读一下 How To Safely Store A Password（陈皓注：酷壳以前曾介绍过bcrypt这个算法，这里，我更建议我们应该让用户输入比较强的口令，比如Apple ID注册的过程需要用户输入超过8位，需要有大小写和数字的口令，或是做出类似于这样的用户体验的东西）。

• 不要试图自己去发明或创造一个自己的fancy的认证系统，你可能会忽略到一些不容易让你查觉的东西而导致你的站点被hack了。（陈皓注：我在腾讯那坑爹的申诉系统中说过这个事了，我说过这句话——“真正的安全系统是协同整个社会的安全系统做出来的一道安全长城，而不是什么都要自己搞”，当然，很遗憾不是所有的人都能看懂这个事，包括一些资深的人）

• 了解 处理信用卡的一些规则 . (这里也有一个问题你可以查看一下) （陈皓注：有两上vendor可以帮助你，一个是 Authorize.Net 另一个是 PayFlow Pro）

• 使用 SSL/HTTPS 来加密传输登录页面或是任可有敏感信息的页面，比如信用卡号等。

• 知道如何对付session 劫持。（陈皓注：请参看wikipedia的这Session Hijacking，）

• 避免 跨站脚本攻击(XSS)。（陈皓注：参看酷壳站前几天发的《新浪微博的XSS攻击事件》）

• 避免 跨站伪造请求攻击 cross site request forgeries (XSRF).

• 保持你的系统里的所有软件更新到最新的patch。

• 确保你的数据库连接是安全的。

• 确保你能了解最新的攻击技术，以及你系统的脆弱处。

• 请读一下 The Google Browser Security Handbook.

• 请读一下 The Web Application Hacker’s Handbook.

• （陈皓注：之前本站的“一些资源”提到过Mozilla的安全编程规范，还有Ruby on Rails的Web安全的开发教程）

性能

• 只要需要，请实现cache机制，了解并合理地使用 HTTP caching 以及 HTML5 Manifest.

• 优化页面 —— 不要使用20KB图片来平铺网页背景。（陈皓注：还有很多网页页面优化性的文章，你可以STFG – Search The Fucking Google一下。如果你要调试的话，你可以使用firebug或是chrome内置的开发人员的工具来查看网页装载的性能）
• 学习如何 gzip/deflate 网页 (deflate 更好).

• 把多个CSS文件和Javascript文件合并成一个，这样可以减少浏览器的网络连数，并且使用gzip压缩被反复用到的文件。

• 学习一下 Yahoo Exceptional Performance 这个网站上的东西，上面有很多非常不错的改善前端性能的指导，以及 YSlow 这个工具。 Google page speed 是另一个用来做性能采样的工具。这两个工具都需要安装 Firebug 。

• 为那些小的图片使用 CSS Image Sprites，就像工具条一样。 (参看 “最小化 HTTP 请求” ) （陈皓注：把所有的小图片合并成一个图片，然后用CSS把显示其中的一块，这样，这些小图片只用传输一次，酷壳的Wordpress样式的那个RSS订阅列表中的小图标就是这样做的）

• 繁忙的网络应该考虑把网页的内容分开存放在不同的域名下。（陈皓注：比如有专门的图片服务器——图片相当耗带宽，或是专门的Ajax服务器）

• 静态网页 (如，图片，CSS，JavaScript，以及一些不需要访问cookies的网页) 应该放在一个不使用cookies的独立的域名下，因为所有在同一个域名或子域名下的cookie会被这个域名下的请求一同发送。另一个好的选择是使用 Content Delivery Network (CDN).

• 使用单个页面的HTTP请求数最小化。

• 为Javascript使用 Google Closure Compiler 或是 其它压缩工具（陈皓注：压缩Javascript代码可以让你的页面减少网络传输从而可以得到很快的喧染。注意，并不是所有的工具都可以正确压缩Javascript的，Google的这个工具甚至还可以帮你优化你的代码）

• 确认你的网站有一个 favicon.ico 文件放在网站的根下，如 /favicon.ico. 浏览器会自动请求这个文件，就算这个图标文件没有在你的网页中明显说明，浏览器也会请求。如果你没有这个文件，就会出大量的404错误，这会消耗你的服务器带宽。（陈皓注：服务器返回404页面会比这个ico文件可能还大）

SEO (搜索引擎优化)

• 使用 “搜索引擎喜欢的” URL，如：使用 example.com/pages/45-article-title 而不是 example.com/index.php?page=45 (陈皓注：这里的URL是说Wordpress的，后者是默认的)

• 如果你的动态页面要使用 # ，那么请把其改成 #! ，而在服务端，你需要处理$_REQUEST["_escaped_fragment_"] 这是Google搜索引擎需要的。换句话说，./#!page=1 会被Google搜索引擎转成 ./?_escaped_fragments_=page=1。 （陈皓注：通常来说URL中的#后的东西都不会被传到服务器上，所以，为了要让Google可以抓取AJAX的东西，你需要使用#!，而Google会把“#!”转成“_escaped_fragment_”来向服务器发请求，Twitter的大量的链接者是#!的，比如：https://twitter.com/#!/your_activity）。另外，用户也许会使用Firefox 或 Chromium， history.pushState({"foo":"bar"}, "About", "./?page=1"); 是一个很不错的命令。所以，就算是我们的地址栏上的地址改变了，页面也不会重新装载。这可以让你使用 ? 而不是 #! 也能无刷地保住当前的动态的页面，这可以让AJAX的请求被浏览器记住。

• 别使用 “click here” 这样的链接。这样一来，无法SEO，而且对于一些需要使用读屏人来说很不友好（陈皓注：关于读屏软件，可参看本站的“如果看不见你还能编程吗”）

• 做一个 XML sitemap，并放在网端的根下 /sitemap.xml. （陈皓注：这个文件可以让搜索引擎了解你的网站图）
• 当你有多个URL指向同一个网页的使用，使用 <link rel="canonical" ... /> 你可以使用 Google Webmaster Tools 来查看相关的问题。

• 使用 Google Webmaster Tools 和 Yahoo Site Explorer.

• 安装 Google Analytics  (或是别的开源的网站分析工具，如： Piwik).

• 了解 robots.txt 和搜索引擎爬虫是如何工作的。

• 重定向请求 (使用 301 重定向网站) ，如果你要把 www.example.com 定向到 example.com(或是其它的变更) 这样可以防止Google的rank因为域名的变化发生改变。（陈皓注：301重定向一般用作域名变更）

• 知道并不是所有的爬虫都是好的，有些爬虫的行为并不好。（陈皓注：比如向你的网站发大量的请求导致服务器性能低下）

• 如果你有一些非文本的内容需要在 Google’s sitemap  中，比如视频什么的。Tim Farley的答案，可以让你看到很多有价值的东西。

技术

• 理解什么是 HTTP 比如 GET, POST, sessions, cookies等，了解什么是 “stateless” 无状态。

• 让你的 XHTML/HTML 和 CSS 符合 W3C 规范，并确认他们都是 合格的。我们的目标是避免浏览器的 “quirks mode”，并且可以让其更容易地能和非标准的浏览器工作，比如读屏器或移动设备。

• 理解浏览器是怎么处理 JavaScript 的。（陈皓：你会看到有些Javascript代码在页面上前面，有些则是在后面，所以你需要对其了解清楚为什么是这样）

• 了解浏览器是怎么装载 JavaScript，CSS和其它资源的，了解其对视觉上的影响。（陈皓注：10年前我做网页的时候因为HTML还很弱，所以只能使用table来布局，使用table布局的问题就是整个table读完后页面才会显示，用户的视觉体验并不好）。在某些情况下，你可能需要把你的脚本放在页面的后面。

• 理解 JavaScript 的 sandbox 是怎么怎么工作的，尤其是你想使用iframes。

• 请注意 JavaScript 可能会被禁止，这样会让你的AJAX失效。就算是大多数用户都开启了Javascript功能，但是也可能在一些情况下脚本是不被运行的，比如移动终端上，搜索引擎抓网页的时候也并不会执行你的脚本。

• 学习 301 和 302 转向的区别 (这也是一个SEO的问题).

• 尽可能多地学习你的部署平台。（比如：操作系统，Web Server：Apache/Nginx，防火墙，数据库，等等）

• 考虑使用一个 Reset Style Sheet.

• 考虑使用 JavaScript 框架(如： jQuery, MooTools, Prototype, Dojo 或 YUI 3)，它们会很好的兼容于不同的浏览器。（陈皓注：强烈推荐你看一下本站的开源中最好的WEB开发资源一文）

• 把视觉效果和JS框架合在一起讨论，考虑使用一个Service，如：Google Libraries API 来装载框架，这样可以让浏览器可能早就把这个JS框架已经cache了而不需要再从你的网站上下载了。

Bug fixing

• 明白你会花20%的时间写代码，而80%的时候在维护，所以你要小心编码。（陈皓注：参看本站的“多些时间可以少些代码”一文）

• 设计一个好的错误报告机制。

• 设计一个入口可以让人们联系到你并给你建议和批评。

• 为你开发的东西形成文档，这样可以让后来的人容易维护你的软件和系统。

• 频繁备份（也可确保你的这些备份功能正常） Ed Lucas 的回答 有一些忠告。你还需要有一个恢复策略，而不只是一个备份策略。

• 使用一个版本控制系统来保存你的代码，如： Subversion 或 Git.

• 别忘了做Acceptance Testing，使用 Selenium 能帮到你。

• 确保你有足够的日志，你可以使用 log4j, log4n 或 log4r。如果出了问题，这是可以让你快速找到问题的方式。

• 当你写日志的时候，确保你记录了你捕获了处理和未处理异常。报告和分析日志可以让你知道你网站的问题。

这里有多的东西被省略了，并不是因为那些可能不是有帮助的答案，而是因为那些东西都太细节了，超出了这个问题的范围，因为这本来就是一个Web开发需要了解东西的Overview。我想你可以去看一下其它人的答案，我有时间，我也会补充别人的答案进来。请随意编辑这个答案，因为可能有些东西忘了，也有可能有些东西不对。

（全文完）

您可能也喜欢：
开源中最好的Web开发的资源	Web开发人员速查卡	30+ Web下拉菜单	50套Web开发图标	如何在低速率网络中测试 Web 应用
无觅

相关文章

• 2011年02月16日 -- Web开发人员速查卡
• 2011年11月28日 -- 如何设计“找回用户帐号”功能
• 2011年11月24日 -- 一些文章资源和趣闻
• 2011年08月25日 -- 你会做Web上的用户登录功能吗？
• 2011年06月08日 -- 开源中最好的Web开发的资源
• 2011年03月04日 -- 一些有意思的贴子和工具
• 2010年10月20日 -- 30+ Web下拉菜单

从这个列表上，我们可以看到，他从去年7月份就在自己实现这些东西了，我把他实现的这些算法转过来，

• 一方面我们可以学习一下这些算法和代码，因为很多东西对我来说都比较新，我以前列举过一些经典的算法，算法和数据结构词典，还有可视化的数据结构和算法， 不过感觉都没有这个全。

• 另一方面我希望这个事可以影响到一些正在学习编程的人。看看别人是怎么学习编程的，希望对你有借鉴作用。

（全文完）

您可能也喜欢：
一个排序算法比较的网站	Why C++ ? 王者归来	C++和JAVA传统中积极的一面	一些重要的算法	可视化的数据结构和算法
无觅

相关文章

• 2011年04月06日 -- 一些有意思的文章和资源
• 2011年05月04日 -- 可视化的数据结构和算法
• 2011年03月18日 -- 可视化的排序过程
• 2011年02月28日 -- 打印质数的各种算法
• 2010年07月12日 -- 一些重要的算法
• 2009年04月15日 -- 一个显示排序过程的Python脚本
• 2009年04月10日 -- 一个排序算法比较的网站

在行文之前，我得先感谢腾讯公司的至少30名员工在《腾讯帐号申诉的用户体验》一文后的回帖（我STFG（Search The Fucking Google）看到了你们使用的那个固定IP在各个大学论坛上的腾讯的招聘广告），我感谢你们主要有两点：

1. 你们有半数以上的人留下的是gmail而不是QQMail/Foxmail的电子邮件，这点让我感到很欣慰。
2. 你们在加班到晚上11点的时候都能在本站回复，的确如你们的Andy Pan所说，你们的核心竞争力很强，包括水军方面。

好了，让我正式谈谈这个设计。找回用户帐号通常就用三个事就可以了：邮箱，安全问答，手机。

邮箱，安全问答，手机

大多数的系统都会使用邮箱和安全问答，这足够了，很多系统直接用邮箱做帐号名（Apple ID，Facebook，新浪微博 ….），这样一来，就算你的系统口令被盗，帐号的是改不掉的，于是你可以用邮箱找回（注：这些系统都会验证你的邮箱是否正确）。但是，如果用邮箱做帐号，会导致你的邮箱暴露了，这样为成为垃圾邮件的受害者，而且如果你还比较2的把邮箱的口令和帐号的口令设置成一样的，那么就相当坑爹了（你可以看看本站的这篇文章——如何设计你的口令）。所以，但凡是用邮箱用为帐号的系统都不会让人看到你的注册邮箱，比如，大家就不知道我新浪微博帐号注册的邮箱，就算是知道也应该是受信的人知道（新浪微博帐号的邮箱地址的默认可见度是“你关注的人”）。

这里要说一下，Google Mail使用的是电子邮件，安全问答 和 手机。你可以使用其中一种找回口令。gmail最漂亮的用户体验是其会提示你，你绑写的邮箱（哪家公司的邮箱和帐号名的第一个字母）和手机（3个尾号）。MSN和gmail相似，也会提示你绑定的邮箱，也可以使用手机，还可以使用你设置好的受信PC，以及通过客户支持（通过客户支持——收集你注册时用的名字，生日，国家地区，安全问题，使用过的口令，最近发送过的邮箱标题，联系人等，或是你绑定过的信用卡信息，但是不会有身份证）。

使用手机的一般是安全性比较高的网站，比如：淘宝、Gmail等。这样，使用手机找回口令也不错。因为你注册的安全问答你可能会忘了，你的绑定的邮箱也可能忘了口令，而很多木马可以盗取你的这些电脑上的安全问答或邮箱口令，但是这些木马程序盗不走你的手机（注：在移动互联网时代很可能会盗取你的手机上的信息，但是也盗不走你的手机号——无法像邮箱那样改个口令就盗走了）。你会说，手机还不是会丢失，但是你要明白，你丢失的手机，你是可以停机的，可以通过你的手机密码卡或是身份证恢复你的手机号的。另外，使用手机的好处还在于，我的系统不需要收信你的真实信息（如：姓名，身份证，住址等），这些真实信息的验证交给移动运营商验证就好了。在程序设计的里，我们把这种事叫“解耦”。Amazon就一种通过电子邮件，然后通过你使用过的信用卡后四位，以及帐单的邮寄的邮政编码，如果你的邮箱变了，没问题，打电话给客服吧，客服会问你的钱行卡号和帐单地址，电子商务的好处就是可以有信用卡或银行卡来恢复号。，因为这——把用户的真实信息“解耦”到了银行，并“耦合”和银行方面的安全策略。很明显，银行和移动公司的安全级别更高，而且用户也更信任他们。最好不要自己收集用户的真实信息，要是丢失了，你就麻烦了（在国外你就要被起诉了）

在这里，你可能会有疑问，如果我的帐号口令丢失了，那么盗取者会进入我的系统改我的邮箱，改我的手机，改我的信用卡等，那不也一样吗？我想说，对于邮箱和手机，其和密码的级别一样，你改密码的时候，你都要输入旧密码，所以，你改邮箱和手机的时候也要使用旧的邮箱和手机。关于你绑定的银行卡或信用卡号，就算是自己也看不见的（只能看见四个尾号），这就就可以防盗了。当然，盗电子商务帐号的人一般会用你一帐号买东西，但是其会遇到另一个麻烦，那就是要面对银行方面的审计工作——1）对于银行卡通过银行的网银，银行的安全系统会帮你审计。2）对于信用卡则要受到信用卡验证和签名的验证，还能让商家会帮你检查信用卡签名是否正确。

一些人说，QQ的帐号申诉过程的“美妙”在于其他尽可能多的收集你的信息，这样一来，反而是安全的，因为密码容易被盗，而你的那么多的信息则不容易被盗。这样认识只对了一半。真正的安全系统是协同整个社会的安全系统做出来的一道安全长城，而不是什么都要自己搞（当然，我们都知道腾讯的DNA就是什么都要自己搞，连FBI和CIA的事也已经在搞了），什么自己都搞反而不安全了。

其它讨论Q&A

问题一：通过申诉找回帐号靠不靠谱？

明显不靠谱，而且还很愚蠢。这反而成了恶意者的温床。他人可以通过申诉让正常人的帐号失效，这是一件多么愚蠢的事啊！（我的QQ帐号前两天不就被这样攻击了吗？）

问题二：通过联系人恢复帐号靠不靠谱？

不全然靠谱，因为你的QQ总是会有陌生人加你，你的邮箱联系人也会有一些你不受信的人。那些人可能就是攻击者的小号。所以，如果你要通过联系人的话，就不要像QQ或MSN那样坑爹的做法，让用户自己来选。而是要像Facebook那样的做法——系统随机挑些人来让你认。

问题三：在注册时设置受信的联系人靠不靠谱？

看似靠谱，但是个人觉得还是还一点问题。因为受信者通过电子信息无法分辨是本人还是盗号者，还要受信者实际联系一下对方。这就好像我们在手机号存电话号码的时候，写上了爸爸，妈妈这样的字眼，这样当恶意者拿了你的手机后，就可以向你的家人敲诈了，因为其直接就可以叫出对方那头的人和被攻击者的关系。

问题四：恢复帐号的时候收集用户的真实信息靠不靠谱？

这要看是什么情况了。如果用户在注册时提供了这些真实信息，就靠谱，如果没有就相当不靠谱。试想：你去银行开户存钱的时候，银行没有让你出示身份证，只让你设了个口令。然后我就可以用我的身份证去重置你的口令。你觉得这个事是不是相当的坑爹？！

问题五：小白不懂邮件，不懂安全问题，不懂绑定手机啊？

那就用耐心地客服教导这些小白（可参看银行等机构的做法——强制用户输入8位以上的口令，强制使用U盾才能进行大额转帐），提高他们的能力和对安全的认识，当有一天这套东西形成社会标准的时候，安全才会真的到来。安全的问题本来就是双方的事，只有大家都有安全意识，才能做得好。而不是迁就用户。还是Henry Ford的那名话——“如果我问用户要什么，用户会说他要一匹更快的马”，所以这世上也就不会有汽车了。QQ不应该为降低用户安全意识起推动性作用。

问题六：我的经历是什么样的？

我基本不上QQ，我上QQ都是被朋友和同学逼的。因为上周四我想写点关于腾读用户体验的东西，所以我才上QQ想看看，结果发现上不去了，说是帐号被投诉了，让我申诉，我猜想估计和我最早发布的关于腾讯的文章有关系。我1999年来注册的这个QQ号根本没有提交过什么身份证或是地址系统之类的东西，我曾经绑定过手机，大概在5年前绑定过。

于是在走申诉流程的过程中，腾讯说的绑定的手机没有被验证过，我还记得曾经我使用我的hotmail邮箱代替过我的QQ号，不过这些在被投诉的面前都不能用了。而我感到腾讯无法知道我提交的这些信息是否真实，又因为我以前曾经帮朋友注册过QQ号(我这些朋友就是腾讯员工说的小白用户)，所以，我就用一些看上去比较真实的但实际是假的信息，并用帮人注册的这些QQ号成功申诉回来了。

有的网友说我不分不清找回密码和申诉的差别，我在这里想说，你分明绑定了手机，但是当你发了短信后却被告诉你的手机没有被验证过。这个就很扯了。

于是，我才意识到QQ的这个申诉过程相当的不安全。关于一些细节问题，还请我们的我们腾讯的员工@larry同学给大家更多的细节。

问题七：QQ还有什么样的坑爹的Use Case?

有两个朋友在回复中说到了两个有意思的比较坑爹的Use Case。

@gqjjqg  说，他有个朋友被恶意申诉，有段时间和这个恶意申诉者来来回回地申诉这个QQ号，搞了一个多月都没有搞定。最后只得和那个恶意申诉者达成和解才解决了这个事。

@Jack Yang说，他有个朋友在网上买了一个QQ号，没过几天就被申诉回去了（毕竟那是别人用过的），然后人家再接着卖，怎么申诉都申诉不回来。欲哭无泪。

可见，在QQ的申诉流程下，什么密保，什么手机绑定，都成了浮云。

（如果你还有什么样的问题，我可以在继续更新并回答你的问题）

——————————

希望你现在明白，关于腾讯的帐号申诉过程，看上去相那么回事，实际上漏洞百出。当然，我不能说腾讯是愚蠢的，因为人家搞得那么大的企业，我只能说人家是在下一盘很大的棋……

您可能也喜欢：
腾讯帐号申诉的用户体验	腾讯，竞争力 和 用户体验	101个设计模式	用户界面和用户体验的差别	Web开发中需要了解的东西
无觅

相关文章

• 2011年11月25日 -- 腾讯帐号申诉的用户体验
• 2011年12月07日 -- Web开发中需要了解的东西
• 2011年11月22日 -- 腾讯，竞争力 和 用户体验
• 2011年08月25日 -- 你会做Web上的用户登录功能吗？
• 2011年03月03日 -- 另类UX让你输入强口令
• 2012年01月06日 -- Hash Collision DoS 问题
• 2011年12月22日 -- CSDN明文口令泄露的启示

网上有大量的文章说QQ扫描硬盘啊，说QQ收集用户信息啊，你可能忘了这些。前段时间的3Q大战的那个“艰难的决定”，你好像也忘了。还有狗日的腾讯，你也忘了。包括QQ可以预防犯罪的新闻，你可能也忘（这本就是一个容易忘事的民族）。你已经被QQ的用户体验迷住你的双眼，觉得QQ无敌于天下，就像这个微博 以及微博里的回复一样在赞叹QQ注重细节一样，那些人在看到QQ的Mac版上向Steve Jobs感谢的字样激动不已。我感到你被一块红布蒙住了双眼也蒙住了天，我问你看见了什么，你说你看见了幸福 ，这个感觉真让你舒服……（对不起，一不小心我就在唱歌了，So So Sorry）

回到正题，你会说，我们在谈技术，不谈这些非技术的。好吧，我们来看看技术上的东西。我和大家说一下这两天我的真实经历。

两天前，我的QQ号被“恶意投诉”，封了号。腾讯让我走申诉流程，于是我看到了下面这些步骤：

1. 填入我的真实姓名，身份证号，地址等我的真实信息。 （盗号者也可以填）
2. 填入我的手机号，并要用这个手机号向腾讯发个短信以收取验证码。（盗号者的手机）
3. 填入我以前曾经使用过的QQ密码 （盗号者盗到的密码）
4. 填入我是什么时候，在哪里注册的QQ （盗号者可以填忘记了）
5. 填入最近3年来，我在哪里使用过QQ （盗号者也可以填忘 记了）
6. 邀请QQ好友来帮助申诉，越多越好，需要填号好友的QQ号和真实姓名。 （盗号者也可以用自己的小号，这些小号可以加你为好友）

这已经是非同寻常的流程了…… 从这个申请过程中你看到了什么？你是否看到了这些东西：

• 收集你的用户信息，从姓名，地址，身份证到手机号，包括你好友的真实姓名。
• 收集并验证我过去使用过的密码，以及我在哪里使用QQ的。
• 这个过程无法确保安全性。没有一点技术含量。

这些意味着什么？你会说，因为我不知道QQ盗号有多严重，所以他们才有这样的措施。那么我不禁要反问一下了——

• 这个世上还有什么产品是可以让别人通过申诉来让你的帐号失效的？
• 又有哪个产品是通过收集真实的用户信息和朋友的信息来找回密码的？
• 这个世上还有什么产品是在注册的时候不要真实信息，而在找回密码的时候要真实信息？

要收信就应该在注册的时候收集，你见过哪家银行在开户的时候不要你身份证，而你取钱，挂失的时候需要身份证的？只要腾讯愿意，弹个窗，于是就可以一点一点地让所有的人都走申诉流程以收集真实信息。我看这个过程并不是想看上去的那么简单啊。这就是用户体验？你可能还依然坚持你对这一做法的理解，那么，我真心希望你看看别的系统和软件是怎么做的。（老实说，一个手机号，另一个邮箱就可以搞定了）

我的朋友在微博上回复到——

//@真谛419：。。。qq是一个伟大的企业，一步步微创新走到了创新横扫CIA，FBI的浪潮之巅 //@chengxi_: CIA弱到爆，QQ knows it all. 这个获取所有实名社交网络的创新不亚于 reCaptcha ，用QQ的和裸奔的区别在于“裸奔”是自愿的。

你也许会说，这是腾讯因为不可抗力不得已这样做的，我们都应该理解腾讯。我想了一想，我觉得你说得有道理，你无非就是想让我说——腾讯不SB，SB的是用户。好吧，我承认你有一定的道理。

既然这样，那么我就不得不加粗朋友的这句话了——用QQ的和裸奔的区别在于“裸奔”是自愿的！！ 而且，我仿佛、似乎、好像，隐约还听到有人在欢快地呻吟着：“在QQ上裸奔的用户体验太~~好~~啦~~，让我高潮不断啊~~~啊~~~啊~~~啊~~~~~~~~”。行了行了，你可以裸奔，但是没有必要那么爽吧。

（对不起，我本不应该骂人的，更不应该还骂的那么低俗，重要的是，这本来应该在新浪微博上骂的，因为那里的骂人用户体验最好的地方……）

结尾了，你会会说我是一个喷子，呵呵。我想说，腾讯是一个天使和魔鬼的混合体，东西还是要一分为二的看，用么还是可以适当用用的，但是我们的头脑还是要清楚一些明白那是怎么一回事。

您可能也喜欢：
如何设计“找回用户帐号”功能	腾讯，竞争力 和 用户体验	用户界面和用户体验的差别	另类UX让你输入强口令	微软的安全补丁分析
无觅

相关文章

• 2011年11月28日 -- 如何设计“找回用户帐号”功能
• 2011年11月22日 -- 腾讯，竞争力 和 用户体验
• 2011年03月03日 -- 另类UX让你输入强口令
• 2012年01月06日 -- Hash Collision DoS 问题
• 2011年12月22日 -- CSDN明文口令泄露的启示
• 2011年12月07日 -- Web开发中需要了解的东西
• 2011年08月25日 -- 你会做Web上的用户登录功能吗？