3、差异化思维和迭代开发：关于设计和开发/测试

　　3.1 系统设计

　　不同类型的产品，不同的开发平台，设计思路有非常大的区别。本文不会就具体的软件设计做讨论。这里想重点强调的一点是系统设计中的“差异化”思维。

　　举个例子，一个西餐厅，平常的客流量基本上是稳定的，但是在情人节等特殊的日子，客流量会有一个突发性的增长。有什么办法可以解决这个问题，即使在忙的时候，也不能让客户过长时间的等待。另外一个例子，盛夏时节，用户家里的空调坏了，维修需要3天时间，作为售后服务方，应如何应对。

　　这些问题的解决思路，实际上在于如何进行合理的差异化设计。一个热门的互联网应用，在繁忙时间段（例如周末、晚间），会出现带宽、服务器资源紧张的情况，这个时候网络丢包、操作响应变慢，影响用户体验。更严重的情况下，当负荷超过阈值，出现雪崩效应，基本上处于无法服务的状态。

　　所谓的差异化设计，即要根据业务的本质，对产品所提供的服务按照一定的粒度划分层次，什么是基础服务，什么是增值服务；什么是必须满足的服务，什么是锦上添花的服务。举例来说，对于一个即时通讯业务，发送文本类消息是最基本的，而魔法表情、虚拟形象则是增值服务。在合理地对业务进行了划分之后，就可以在不同情况下作出取舍。系统和带宽空闲的时候、资源紧张的时候，系统出现故障的时候，在不同的情况下，系统的设计要能够支持划分的业务单元按需要进行组合和取舍。

　　对于业务单元的划分，也可以从另外一个角度来考虑，那就是用户的“愤怒”指数。对于一个具备十几项功能的服务，某几项功能出现问题会使用户觉得无关痛痒，而另外几项则会使用户暴跳如雷，甚至有几项出问题会使用户发誓永远不用你的服务。通过对不同功能的愤怒指数进行设定，也可以得出层次化的划分。

　　当系统、IDC、网络出现问题的时候，要优先保证最基本的、也就是愤怒指数最高的功能。当问题逐渐升级，功能要逐层取舍。这是在系统设计需要考虑的问题。

　　回到西餐厅的例子，在业务空闲的时候，餐厅提供的服务可能包括热毛巾、个性化菜单、豪华餐具，甚至跪式服务。而在繁忙的时候，为了能够提高流转速度，餐厅可能需要一份特殊菜单，这份菜单上没有过多的选择，只能像做选择题一样，选择情人节套餐A，B或者C。对于修空调来说，空调的维修需要3天，这个是无法更改的。但是，我们在维修的同时，是否可以为用户提供一个风扇，缓解目前的状况。一切方法是为了降低用户的愤怒指数，而互联网产品的差异化设计的目的也是一样的。

　　另外一个需要在系统设计时考虑的重要问题是“可扩展性”（scalability），也就是说当系统的压力持续增加时，需要能够通过扩展硬件来达到容量的提升。理想的情况是线性扩展，也就是硬件的增长和用户压力的增长是成线性比例的。但是，大多数系统是做不到线性扩展的，更差的是，很多系统在设计的时候完全没有考虑“可扩展性”，从而无法突破单机的性能极限。

　　现代的互联网系统基本上都是“分布式”的，把系统划分成前端显示层、业务逻辑层、数据存储层等几个部分，在各个部分能够进行不同策略的负载均衡。例如数据库可以采用主从备份和均衡、数据分片等方案，WEB前段可以使用squid/nginx等进行负载均衡，甚至采用DNS全局负载均衡等方案。

　　3.2 开发和测试

　　互联网是一个快速变化的世界，我们所面临的用户、环境每天都在改变，这就要求项目的技术团队能够适应这种情况，要能够做到“快速迭代”。不同于传统的软件项目，动辄几个月甚至几年的项目周期，互联网项目通常是以周为单位进行迭代。

　　在大多数情况下，一个网站在应付日常的特性修改的同时，也在酝酿大型的版本升级。因此，技术团队负责人需要对版本进行很好的规划。在开发过程中，借助SVN等版本管理工具，对主线版本和分支版本进行管理，保证日常的BUG修复可以归并到主线版本中。对于需求文档、设计思路、BUG记录等，则可以借用WIKI等工具。通过快速原型的构建，使得产品经理和其他内部客户能够尽早地体验系统功能，及时发现问题和明确方向。

　　开发团队应当在工作中逐步总结出编码规范，例如，HTML/CSS制作规范、PHP/JAVA编程规范等等。这里要特别强调的是，互联网应用中的安全问题是非常突出的，这方面需要在开发过程中特别关注。常见的互联网安全问题包括：跨站脚本攻击、代码注入、缓冲区溢出、SQL注入、权限验证漏洞、第三方系统漏洞等等。

　　根据项目的大小不同，测试团队的规模相差也很大。有些项目需要和开发团队人数相当的测试人员，而有些团队的开发人员则兼任了测试的职责。在项目的发展过程中，应尽量对一些基础功能制作自动化测试工具，并不断完善测试用例。这样测试团队可以把更多精力投入到新功能的测试中，而不是每次版本发布都在对已有功能是否被破坏而感到担心。

　　从管理的角度来说，如何使开发和测试人员热爱自己所从事的产品工作是非常重要的。往往，很多项目都是产品经理和管理层在推动，技术团队只是被动地完成任务，并不断有抱怨产生，这样的项目是不健康的。技术人员同样要成为产品的主人，要具备相当高的主观能动性来投入工作，把所开发的产品看作是自己的孩子般关心和爱护。