Web 2.0中的LAMP结构开发与运营

文 / 钱宏武

Web2.0，让我喜欢让我忧

 “Web2.0时代主角的光环头一次照在了程序员的脑袋上，一直默默无闻、辛勤工作的工程师不再是后台不为人知的工作人员，也开始走到前台。而历史告诉我们，每一个成功的主角背后，都是血泪和汗水。一个互动系统，作为公司的核心，或者说领导关注的重点，工程师的日子大概不会像以前普通的工作人员那样省心。

 首先就是系统的不稳定成了无数程序员的梦魇。不过做程序的都知道，花了无数钱的Windows，当机那是家常便饭，所以对于自己程序的设计缺陷，上线运行，偶尔当当，只要不造成数据丢失，大概每个人都会认为是正常。“等一会，重启一下”也成了每个开发者的口头禅，而在互联网，在把流量和钱划等号的领导面前，这个口头禅和抢他钱没什么两样，在领导可以杀死你的眼光下，每个工程师都是极其头疼。

其次就是Web2.0中间无数突发奇想的功能。由于动态产品重点不在于内容，于是功能成了很多产品的发展或者考核的重点。但是，凡有一点程序开发常识的人都知道，功能众多是程序稳定的大忌，在第一个问题都还没有解决的情况下，第二个问题又成了一个巨大的包袱。

最后，需求朝令夕改。这是程序员最不喜欢的。很多情况一般是一个外行的领导，或者说有一些不负责任的产品。但更多的时候，产品设计人员有时也很委屈，不是他们想不明白，这个世界变化太快。

Web2.0互动产品开发的三个思想误区

以上三个问题，是Web 2.0的开发人员最常碰见的。对于这三个问题，我初次碰到的时候，也是快崩溃了，后来慢慢找到解决方法。在解决这些问题中发现，对于这种互动产品的开发，很多理念和传统的开发是有差别的，甚至有些是完全相反。也就是说，如果要解决这些问题，首先是解决我们思维中的一些禁锢，或者说思想上的一些错误观点。

第一种错误观点就是认为数据是宝贵的，宁可出错，也不能丢失数据。在传统系统中（如财务系统），数据很多都是涉及到钱的，丢了一条，就会出现财务账面对不上。而在互联网运行的产品中，数据从来都是第二位的，因为数据大部分都是文章，或者博客，很多统计也是点击数。这些数据，点击数少几个多几个、文章的发表数量的统计少几篇多几篇没人会说什么。如果一定要追求完美，程序的复杂程度将增加许多，而这种复杂程度将直接导致系统的故障频繁。

第二种，就是真实，这是很多优秀程序员最容易犯的错误。系统出错了，老老实实报一个大错，有时候还怕别人不知道，用大大的红字提醒。在此，我借用产品的一个词，就是用户感受度。因为对于互动产品来说，很多人过来用，都是寻一开心，博客也罢，论坛也罢，贴吧也罢，都是能有一个愉悦的心情。是否是真的，他并不在乎。所以出了错，最好的方式是向那些政客们学习，掩盖住，别让用户知道。如果有较真的用户，系统可以再提示他出了一些小问题。很多时候，系统有点小故障，一会也就过去了。在这一点上，一定要注意把握好度，你不能什么都欺骗，而具体的度在哪里，就看个人的掌握。

第三种，系统之间，关联度比较小。很多人在设计互动架构的时候，由于第一种思维方式，系统和系统之间、机器和机器之间、模块和模块之间，耦合度非常高，这种高耦合度的好处就是保证数据的完整和真实，但对应的就是开发的成本和稳定运行就会很差。

以上几点，我觉得是互联网互动产品和传统开发中，思考方式最大的区别。在总结这么多问题的前提下，下面我来谈谈自己对互动产品开发和运维方式的一些感受。

开发和运维

对于互动产品来说，一期开发完毕并且上线，只是走完了万里长城的第一步，接下来将面对越来越大的问题和劫难。对于Web2.0互动产品来说，一般有一个临界点。在这个点之前，一切都很顺利，性能稳定、速度快、用户反应也很好，开发也是有条不紊。突然有一天，一切都改变了，系统开始不稳定、速度变得极慢、各个方面的需求开始增多，开发开始出现混乱。这么多问题，怎么解决？是先解决稳定问题，还是先招人解决开发问题，还是加机器？

我的建议是，如果问题已经产生了，首要解决的一定是稳定。稳定一般都是由数据库引起的，优化数据库、索引，然后更改读取的方式，把数据进行分拆，都是你可以做的。优化完了之后，砍掉一期开发中华而不实的功能。注意，一般的互动产品通常是读取具体内容的那个页面访问量最大，所以那个程序需要做到最简单——什么功能都不要带，就是读取，最好是读取的静态页面。至于动态的部分，可以使用js回填的方式来控制，如果能跑出来，当然是完美的页面，如果这个动态部分跑不出来，也不影响用户浏览主要的内容。这些做完后，下面的工作才是重点。

如何高效率地开发

系统稳定后，需要考虑运维中长期会碰到的问题，毕竟对于稳定来说，最后其实就是通过系统架构，完成一个可以通过添加机器来完成对整体流量的上涨平衡。但对于日常的开发，一旦处理不好，每天就会疲于应付那些新需求，不太可能有精力投入对新系统的构架和开发。其实，对于那些突发奇想的功能，一般按照划分，最多的就是对内容的操作，毕竟现在所谓的2.0产品，归到底，个人感觉就是围绕文章如何分类的问题。

编辑或者产品的需求，一般最常见的也就是突发奇想的几种分类或者排序而已，只是由于他们很在乎这种体现形式，如红的还是蓝的、带图还是不带图、或者是纯图，系统自动出还是他来选择、用户能看不能看等。这些东西开发人员可能觉得不起眼，但对于编辑或者产品来说很重要，他们就是靠这些来实现他们的想法和创意，实现产品的推广和运营。对此，很多负责开发的人一般是两种态度。

第一种是来者不拒，一视同仁，排期，一个一个做。这种做法一般是被下属骂死，使得工程师流失率极高。由于流失率大，开发的质量和速度自然不能保证。第二种来者皆拒，我这里很忙，我系统要升级。这种态度一般开始是慢慢地没人搭理，后来就直接被投诉，然后

被干掉。

对于这些，最好的方式应该是有选择地答应用户的需求，要达到90%的需求都能满足，然后自己开发一个开发平台。不要觉得那是微软或Borland才能做的事情，其实自己设计一个开发平台很容易。当那些琐碎且重复的需求在你的工作计划中占了2/3的时候，就需要这样一个开发平台了。

这个基本的开发思想，就是程序生成程序，完成开发中80%代码重复的部分，然后完成剩下的20%。在开发说明中，按照要求一步一步去做，最后完成需求。面对这样一个需求，一个初级工程师也能在30分钟左右完成，并且保质保量。这样，你设置一个半人，就能应付所有的需求。我见过很多人都有类似的自己代码生成系统，这里我讲一下我当时是怎么设计的。

当时的工作主要是更新网站的内容页面，当时有近30个频道，每个频道都有一个社区首页，每个频道基本是3 个月要求整体改一个版。平均下来，就是每三天就会有一个频道需要改版。其他小的改动，基本每个频道是每2周会有一个。也就说，一周的工作计划中，一般会有2个大的页面开发，15 个的改动。分析后发现，就是图、文、人绕来绕去，不同的形式显示，写了三个对象：

l  图的对象

l  文字的对象

l  人的对象

然后，根据对象写一个代码生成，这个初期设计也比较简单。就是说，就是几种方案，就是文字取的方式和显示方式，他们当时就几种，或者大类选取，比方说整个女人购物分类。下面所有版面的文章，然后显示出最新的10条，开发一个选择的条件，根据选择的条件，选择不同的类对象的代码，然后传入对象方法中的参数，再把代码显示在一个页面中，拷贝后，放在程序中。熟练后，一个工程师在几分钟就能完成一个版块。一般小的需求，都是一个版块，大的页面，也就是20~30个版面。这样，小的需求基本是当时来，当时就能完成；大的也是上午提交需求，下午就能给用户，这样有很多好处。大体结构图如下：

1由于基本类可以集中很好的人来开发，核心代码质量代码很高，初级的人员由于只写表现层，不涉及数据库和底层的操作，不会影响整个系统。

2 由于速度非常快，需求还没来得及换，我已经写完并且上线了，对方没有时间提，避免了需求朝令夕改。

3 由于对具体操作人员要求很低，而且能保证时间和质量。

4 大量琐碎的工作可以由初级员工完成，这样一个可以锻炼他们对于程序的理解，也避免了高级工程师做这种大量重复而低级的工作。

 有人曾经建议过我用模板的方式来写，就是大家常说MVC的模式，显示和逻辑完全分开。这个我考虑后，个人觉得不太适合互动产品，主要是从效率来考虑，毕竟，很多传统的开发中间速度一般是不太考虑的。而对于互动产品来说，如果慢或者说消耗系统资源巨大，那么这个开发基本是非常失败的。

结语

对于互动产品的开发和维护来说，需要抓住开发的重点，而归结起来，就是效率。很多项目经理能注意到程序本身的效率以及修改的效率，其实更重要的是开发本身的效率，就是通过开发的积累，把很多开发的工作，变得像流水线一样，可以让比较初级的人员处理大量重复简单的工作，这样才能保证本部门人员慢慢从日常繁杂的开发中抽出时间做一些更基础的工作。

作者简介：

钱宏武，职脉网技术合作人，原搜狐互动产品开发部主管，构架并开发能承担6000万/日访问的社区论坛，协助设计并运营搜狐体育直播间，最高承担48万人同时在线观看NBA直播，对于LAMP下的互动产品开发，有7 年的开发管理经验。联系方式：msn:qhw108@hotmail.com；qq: 690889126。