ＰＨＰ神话（上）：模拟项目２００８

开始一个网站项目

传说中人闲得无聊的时候总会下意识地找点什么事情做，恰巧这段时间我正因为种种缘由处在这种状态之中，于是乎我便打算模拟个什么项目来练练手，也好让自己有聊些。Web2.0仍作为一个囫囵吞枣的概念被国内的网络圈狂热地追捧着，所以项目俺就挑选了比较典型的视频网，跟着赶赶时髦。故事也就由此开始了……

【软件工程】

既然是模拟一个完整的项目，那么了解一下“软件工程”的概念是很有必要的。简单说，软件工程就是“采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。”（张海藩 1998）实际上网站也可以看成是一种软件，比如它有软件界面（网页），也有后台事务处理（后台PHP程序、数据库等），所以同样能应用软件工程。

一个人从生到死，经历胎儿、儿童、青年、中年、老年等各个阶段，称之为“生命周期”。同样，一个软件也要经历创意、开发、使用和废弃这样一个过程，这就是软件的生命周期。软件生命周期一般分为软件定义、软件开发和软件维护三大阶段，每一阶段又能进一步细化，比如一个通用的软件过程框架就可以是：

1.沟通：与客户交流，确定要达到的目标是什么，多大规模等。

2.策划：描述要执行的技术任务，分析可能的风险及资源需求，制订工作进度计划等。

3.建模：软件设计阶段，建立需求模型和软件设计模型等。

4.构建：编制代码（手写或自动生成）和测试。

5.部署：将完成的软件产品交付使用，并作后期维护。

传统的软件工程，大致按上面的步骤一环紧扣一环进行，如同一泻千里的瀑布，所以称之为“瀑布模型”。

组建梦幻团队

一个人毕竟能力有限，于是我偷偷拽上室友—一个自诩为设计师的家伙，请允许我这样称呼他—Y。于是乎我们两人组成了一个有着完整结构的团队：需求分析、系统架构、主程序员和系统优化由我一并承担，同样Y也不得不肩负起用户体验设计、用户界面设计并实现、前台实现、黑白盒测试和客户沟通等多项任务。与客户沟通是一项涉及到民生的大事，毕竟客户才是我们的衣食父母。而对于更注重逻辑的我而言，要与客户华丽而优雅地交流，在体现出我们专业的同时还要有艺术的热情，实在不是一件轻松的工作。

恰到好处的客户需求

“食君之禄，忠君之事”，让客户以更低廉的成本实现更高能的需求，是我们应该达成的准则。因此，我们应该尽可能地减少服务器数量和网络带宽的占用，同时尽可能地保持项目的可发展性。不过在与客户沟通之前，我一再叮嘱Y：用我们超人的智慧去帮客户扩展需求大可不必了，这并不是一个明智的选择—当然，尽可能地从安全和实用性角度去帮助客户精炼需求同时也优化用户体验，还是一个好员工所应该做的。不过过分地重视流量一直是中国网络圈的顽疾，哪怕是在Web2.0的华丽外表之下。所以如果客户对于优化用户体验并不热心的话，还是就此作罢得好。

【需求分析】

正式项目中，需求分析是前期非常重要的工作任务，它贯穿了软件生命周期前期阶段（从沟通到建模）。简单说来，需求分析的任务就是解决“这个软件要做什么”的问题，这需要多方沟通，全面理解用户的各项要求，最终形成一个准确、全面的用户需求列表。

精益求精设计建模

一个项目的研发周期中，前一半应该都留给设计，后四分之一为测试和维护保留，真正留给开发的时间寥寥无几。所以在编码之前的设计期间，我和Y就尽可能地弄清所有潜在的问题。同时，为了让团队运转得更加高效，我（程序）和Y（美工）决定齐头并进，同时展开各自负责的工作，只需在最后阶段再合作拼装就可以了。

视频网需要实现的基本功能不外乎这么几点：多媒体播放、包含了评论的扩展社区、好友、圈子和刺激用户的一系列榜单等（如图1所示就是一个典型的视频网页面结构）。于是我们这个团队的两大巨头开始频繁碰头，商定数据取舍，同时在客户规定的关键用户体验上进行完善。商定结束后便兵分两路，我拿着罗列的数据开始尝试设计程序结构。因为是视频网，大量的视频下载会是程序性能的最大瓶颈，所以在程序设计之初便需要考虑清楚视频的分布、命名和下载规则，而不是要等到程序基本完成之后整体优化时才做这个工作。

图1

【设计思路】

1.预先使用多服务器分布视频，可以分解大量用户访问时的压力——即便最初因为成本问题只允许一台服务器存放视频，也可以在此服务器下载流量达到一定高度时添加镜像。一定不要因为最初设计上的短视，导致运转正常的网站被迫关闭以整修的方式再开发升级。

2.使用特殊规则重命名上传的规则，让恶意用户和爬虫（可以自动提取数据的一类网络程序）无规律可循。这主要是为了保障客户的利益，毕竟谁也不想自己辛辛苦苦整出来的成果被他人剽窃。

3.下载规则的制定包括三个部分，一是多用缓存减少用户重复访问次数，这点主要是RFC中的一些HTTP头定义在起作用（RFC是Request For Comments的缩写，它几乎包含了所有Internet相关的重要资料文档）；二是尽量避免用户使用多线程下载，这点也还是由HTTP头定义操控；三是对视频的下载进行监控，需要的时候手动维护。

视频规则想清楚之后，就该设计数据库了。我先遵循第三范式（3NF）来上一遍，然后根据视频网的实际需要小小地逆反一下，目的在于让程序消耗在数据库上的时间和资源最小。如果客户告知了后继可能发展的话，在设计时也应该尽可能为后继发展留下空间。不过需要注意的是，如果涉及比较冗杂的计算或排序时，最好在此时便将镜像表（无论物理表还是内存表）都设计好。具体到MySQL上，自然是大数据尽可能不入库，字符串类型字段尽可能使用CHAR而非VARCHAR，同时表类型尽可能为FIXED。这些都做完后，就去看看Y的进度喽。他根据用户体验制作的用户界面范稿已经出来了，并且客户也认可了。

【名词解释】

构造数据库必须遵循一定的规则，在关系数据库中，这种规则就称作范式。更多关于范式的内容，可访问http://bbs.cfan.com.cn/thread-666109-1-1.html查看。

根据设计出来的数据字典建立对应的模型，三下五除二罗列出来扔给Y，让他拼出一份雍容华贵的设计文档交送客户过目——自然也得在文档的排版布局上体现出本项目的风格特色出来——虽然实际项目中这样做实在功夫深效果小，但本着精益求精的精神，其消耗的时间就忽略不计了。理所当然地，客户看到了这样一份在表现上堪称经典的设计文档，除了满意肯定不会有什么别的想法了。

万事俱备只欠编码

前期设计工作告一段落，接下来就是重复劳动造代码的时间了。考虑到只有自己这么一个苦力写代码，所以工作分解和排期就大可不必了。十指劈劈啪啪在Zend Studio里敲个不停，偶尔切换到单元测试页按F5键试试能否通过。

软件的测试也是一个浩大的工程，一两句根本说不清楚，这里俺就一笔带过了。其实测试的时间比真正编写代码的时间还要长呢。

风雨之后见彩虹

至此，项目程序终于搬到了正式服务器上，剩下的工作只是小小的调整和优化而已。Y疲于应付客户在界面和用户体验上的小修正和小要求，不过考虑到项目结束即将到来的钞票，我坚信他现在是幸福而快乐的。终于这个项目结束啦，俺的模拟事业也暂告一段落，有机会松口气了。文末再点点题，小子狂妄，说得错了还请诸位多多海涵啊！

图书推荐

对一个软件项目的负责人来说，软件工程知识不可或缺。哪怕只是软件项目中具体负责程序编写的程序员，也完全有必要了解一下软件工程的概念（即使你没打算有朝一日去做系统分析师），这有助于开阔视野，对软件开发有个总体感觉。

为了编辑本期稿件，小编特意去书店泡了一天，发现有关软件工程方面的图书还真不少。不过，大部分著作过于专业，对我这个初学者来说，翻了一会就觉得兴趣索然。就在准备离开书店时，我发现了《软件工程——实践者的研究方法（第6版）》，一下子吸引了我。作者灵活风趣的语言让人倍感亲切，贯穿整本书的一个虚拟软件项目又能让人将理论落到实处。当然这里我可不是要为这本书做广告，大家可参考/computers/common/info.asp?id=33095的介绍，看看是否适合自己的需要。