在开始做http://133.newsky.cn之前，我已经明白网站的开发与产品开发没有什么不同。不过在2004年离开微软中国研发中心Office组的时候，我对网站开发仍一无所知，这主要是因为我之前没有任何互联网研发的背景。虽然对传统软件产品的研发管理比较有经验，但从未接触过Internet相关的项目。

从零开始与网站开发亲密接触

去年我接手第一个网站项目http://www.okooo.com开发时，并没有做网站的经验，只能试着按照以前我参与做Microsoft Office时的方法来做：

首先是打造一个便于公司内部沟通交流的内部网，其中包含“传统软件”研发需要的三个工具：文档库（存放公司各项目的文档）、CVS（保存项目的各种源代码）、BugFree（记录项目的各种缺陷）；

然后，抓住“需求、开发、测试”三个环节：

l         要做好规划、明确需求。为什么要做这个网站、要达到什么目标？特别是需求，要详细到每个页面的每个区域放置什么内容。网站需求应该由对业务最熟悉的人来定义，他负责按照我要求的规范（详细程度）来写出每一部分需求文档，并放入文档库中。每完成一个页面定义，我就召集开发、测试人员来阅读、讨论，这样全部需求写完的时候，项目组成员对整个网站就有了一个清晰的认识。

l         需求明确才进入开发阶段。首先是定义数据库——有多少张表、每张表中有多少个字段。我和开发组长反复讨论，搞清楚这些表定义能否涵盖全部需求，这是最关键的一步，决定着下面编码能否顺利进行。数据库定义后，就是网站后台管理的编码实现，也就是对一张张表进行管理（增、删、改）。当后台管理完成时，项目的大部分就大功告成了。用户看到的前台页面仅仅是内容展示——把一张张表中的数据取出来按照最初的需求放置到页面的各个位置。所有的代码都用CVS管理起来。

l         网站测试和开发同步进行。后台管理每完成若干张表的管理，测试人员立即开始测试。这就像流水线，开发完一部分，立刻测试；同样的，网站前台展示开发时也一样需要测试人员跟进。发现的每一个Bug都用BugFree记录下来跟踪处理过程。

l         数据统计跟上。网站后台各个表的任何改动要准确记录，决不允许出现不知道谁修改了数据库内容的情况。其次，网友访问网站的日志要做好统计，每天结束的时候就能准确的看到当天的用户访问数据。这些数据对网站运营极其重要。

四个月后，我的第一个网站项目顺利上线。所有参与该项目的同事感觉都很新鲜，因为以前他们在做网站时，基本上是一个人“包干”一个频道，简单构思一下就开始写程序、边写边想、相互独立。后来，我跟一位曾在某门户网站工作过的高级工程师朋友介绍了上面的做法，他非常认同和赞赏，得到他的认可我也很兴奋。

随后接触到的很多网站技术人员，让我发觉作坊式做法同样存在于互联网公司，网站在重复多年前传统软件的老路：一个“大虾”很厉害，搞定一个频道或一个网站的方方面面，离开他谁都玩不转；代码中处处留着他的灵感，人走了，网站维护就成了大难题：没有文档、没有统一的编码规范、没有测试记录。

其实无论传统软件、网站、还是游戏等等软件产品/项目，都是程序员用一行行代码敲出来的，只要像微软软件研发那样抓住需求、开发、测试这三个环节，其管理都极其类似。因此当我进入http://133.newsky.cn网站项目的时候，信心十足：我能把它管好！

打造一个网站开发的品牌项目

05年2月18日：项目启动，开始整体规划

在我加入金环天朗的时候，这个网站就已经存在了，而最开始的计划也只是对原有的网站进行局部改版。但是等我深入了解后，大吃一惊：

u       规划／需求：原有网站没有经过认真规划就匆忙上马，只有部分的简单示意图，对于每个页面具体区域的功能描述和逻辑过程还是依赖口头沟通。没有独立的后台管理，依赖于WAP业务的后台，内容展示力不从心。

u       页面设计：美工因为还有其它工作所以有一定程度的拖延，没有时间观念，整个设计方案没有经过整体评估，导致后来许多细节没有按照计划实现，页面设计先后由两人分头独立完成，导致部分风格不一致。

u       开发：技术实现一直处在救火的状态，没有规划，没有步骤，没有主次之分，没有时间观念。代码的结构非常散乱，没有可用的文档查询，开发人员走了，给以后接手的人带来极大的麻烦。代码没有规范、没有注释。归结起来就是可读性很差。

u       测试：没有任何测试，开发人员简单试一试就直接上线了！

u       内容：网站内容维护没有专人负责，逐渐处于无人答理的状态。

总之，原来的网站有太多不尽人意之处，和同类网站比起来差距较大，市场人员无法推广，技术人员很难维护，动不动就出错。只能另起炉灶，推倒重做一个全新的网站。

对一家SP公司而言，做网站是打通让用户消费的通道。从常远看，内容为王，但短期内通道为王：就是让用户很容易找到公司提供的内容。因为WAP业务非常依赖于运营商的门户排名，一个业务放在运营商WAP门户上，第一屏和第二屏有着本质的不同，愿意翻到第2屏上的用户可能少一半或更多！所以SP要想尽一切办法来摆脱对门户的唯一依赖，必须能用别的通道让用户很方便的找到你的业务。而网站就是最好的宣传通道，是公司产品最重要的展示平台。网站研发的目标就是尽快打通联通、移动用户的消费通道，把公司生产出来的产品（图、铃、文字）方便地展示给更多的手机用户。

这个http://133.newsky.cn网站是面向中国联通用户的，其设计目标是：

?         1~3年内不需要改动大框架

?         公司业务内容的精美展示、销售平台

?         在同行中有很强的竞争力

?         老板可以拿出来给投资人演示

为了达成这个设计目标，我和项目组花了近一个月的时间来制定完整规划。

明确的研发流程应该是一个开发团队的固定资产，从这点上，我建立了一套项目研发流程，并为其提供工具支撑：

?         认识老网站的现状、确定新网站的设计目标；对新网站的总体设计图纸进行反复讨论，确定网站研发的四个总原则（灵活的后台、以专题为网站细胞、丰富的资讯、翔实的内容）；明确人员分工、并预告项目执行的几个关键点。

?         在没有公司内部网的情况下，我先搭建两个工具：用于保存各种文档和源代码的TortoiseCVS(客户端)+CVS(服务器端)，用于缺陷管理的BugFree。为每个项目搭建一个CVS模块，其中都有四个子目录：Spec(需求文档)、Design(设计文档)、Code(源代码)、Test(测试文档)。

示意图：网站项目的CVS目录

然后是人力资源，我在规划中提出了非常明确的人力资源需求：

?         前台需求定义：1人（蔡志宏）

?         后台需求定义：2人（刘振飞、朱伟波）

?         美工设计制作：1人

?         开发：3人

?         测试：5人

?         运营：5人

然而，当时的情况却是项目组人员迟迟无法到位：美工只有一个兼职的、时间无法保证；只有一个开发组长；没有测试人员；网站运营人员不能确定。针对这样的情况，我的任务还包括了招聘相关人员及时到位。

在整体上完成上述工作以后，时间已经是3月22日了，事实上，在整个项目启动初期的准备阶段是一个非常重要的工作，清晰的项目规划也为后来的工作扫清了很多障碍。这就是俗话说的“磨刀不误砍柴工”。

05年3月22日：开始定义网站需求

网站需求特别难以确定，为了解决这个问题，我将整个需求定义划分为三个主要的部分：

1．网站前台展示的定义

我首先和负责定义需求的蔡志宏确定了需求Spec文档模板，然后他根据首页、二级、三级页面逐个页面、逐个模块的去定义：展示什么内容，大概的模样（最终样式由美工负责）。这样每个页面都被分解成一块块的“部件”，一个“部件”由一份Spec描述，比如下面是“首页公告栏区域需求定义”Spec的示意图。

示意图：首页公告栏区域的需求定义Spec

每完成若干相关联的Spec，我就召集美工、开发人员开会讨论（本应该也叫上测试和运营人员，但当时还没有人），大家站在不同的角度去看看有无问题，并最终确认下来。

2．联通用户消费流程的定义

用户消费流程涉及到收费问题，必须把每个细节都要搞清楚。这个需求由我负责，先形成一份PPT文档，在大范围内征求大家的意见，然后细化每个细节：从用户访问我们的首页开始，如何登录，如何转向联通网站，如何扣费等每个细节必须想到。

3．网站后台管理的定义

       根据网站前台的需求，我和开发组长朱伟波来设计数据库定义，确定多少张表、每张表中有什么字段。然后从运营人员的登录页面开始设计，用PPT把每张页面的示意图以及逻辑关系都展示出来，然后把需求、开发、美工召集起来一起讨论，看看是否符合运营人员的习惯、是否有遗漏的地方。

需求文档要想清楚后再写下来，让别人读得懂。定义好的需求Spec是整个项目开发的“合同”，马虎不得。在需求定义的3周中（其中前台展示的需求用了2周、后台管理的需求用了1周），每写出来若干相关的需求文档，就在项目组内讨论一次，最终明确下来。需求文档一旦成型以后，就必须严格按照需求文档编写设计代码，尽量控制需求的变化。这不但要求我们在最开始的需求分析阶段做好最充分的准备工作，而且还需要作为项目经理的我，顶住一些来自各方意见的压力。幸运的，我们团队还是非常好的坚持下来了：

示意图：上线后的首页公告栏区域——完全根据Spec中的需求定义来实现

然而，另外的一个问题是，需求文档很容易“老旧”、跟不上最新的变化，需求定义人也懒得去更新，因为开始编码后谁都不去注意需求文档了。为了解决这个问题，我就在后台管理的每一张表的维护页面上，增加一个“Spec”按钮，点击后就可以看到相关的需求文档Spec列表了。这样做有两个好处：一方面运营人员可以很方便的看到最初是怎么设计这块功能的；另一方面也把需求定义者的工作暴露在全体同事面前，文档写的好坏是一目了然。

充分的需求定义保证了整个项目能够准时完工，这也是我们这个项目能够取得圆满成功的原因之一。需求确定之后，后面开发、测试的时间就基本明确下来了。

05年4月12日：数据库设计，正式编码开发

有了完整的需求文档后，接下来就进入开发阶段。如同前面提及的，首先需要完成的是数据库的设计。其实早在需求定义期间，我和朱伟波就已经开始数据库定义，确定多少张表、每张表中有什么字段。我们花费了三天左右的时间来对后台数据库进行详细的设计，并产生出设计文档。

示意图：新天地网站2005版后台数据库定义.doc

然而，光有需求和详细设计文档还不够，开发团队需要保持要一种一致的风格，这一点要求所有的程序员对代码有责任感。因此在这个阶段之前（3/16~4/12），我就让公司所有的Java工程师多次讨论，并最后确定一份“编码规范”，这样网站真正开始写代码的时候，就有一个明确的规范来约束代码的书写。

对于软件项目来说，经常会有一些出乎意料的情况发生。比如，本来计划有两个开发人员做后台管理，结果因为沈阳联通的一个合作项目需求紧急配合，只好临时抽调一个人去支援，毕竟网站是公司内部可以控制的，导致后台开发只有朱伟波一个“光杆司令”，那一段他连续十余天加班到晚上11:30！这样高强度、高压力的工作状态，不是每个程序员都能承受的。经过朱伟波的努力，终于在十天时间内将所有的后台编码全部完成（4月16日至4月26日）。

紧接下来，从5月10日开始，专门为网站开发配备的两个Java程序员到位，朱伟波首先给他们介绍后台管理和Struts技术。随后分工：首页、3个铃声二级、3个图片二级、杂志、热门推荐、精彩专题等，每人承担几个频道的实现，分头阅读对应的需求文档并随时找蔡志宏讨论不清楚的地方。当理解需求之后，由朱伟波协调，三个人分头开始进行前台展示页面的编码工作，加班加点，在5月31日基本结束。

05年4月28日：与开发并行的测试

在这个项目之前，整个公司是没有测试人员的！这不得不让我大为惊讶，一个SP公司没有测试怎么行！所以在这个项目进行的同时我启动测试人员招聘工作，最终成立了一支5人组成的测试组，负责所有业务的测试。

当网站后台管理编码完成后，4/28立即启动测试工作：后台管理中的首页管理、动画、声音、彩图、专题、资讯由专人负责测试，发现一个问题就在BugFree中记录一个Bug。通过BugFree的跟踪和记录，可以让某些问题不必累积到最后才解决。随着网站前台展示开发在5月中旬启动，测试工作也在并行跟进：每个频道、每个页面都有专人负责检查，这样尽可能的把各种潜在的问题揪出来，免除后患。

示意图：用BugFree来管理网站项目中的Bug

很遗憾的是，因为测试组搭建的比较晚、测试任务又比较重，他们需要花费很长时间去熟悉公司的各种业务，所以在这个网站项目中，对测试文档部分（比如测试用例）我并没有要求，只要把问题发现出来上Bug就好了。这就是项目管理中的Trade-Off：抓住主要矛盾、抓大放小。这个项目结束后，测试组已经逐步成熟、磨合好了，我才开始强调测试文档的重要性，每个业务测试时一定要同步完成相关的测试文档（计划、用例、测试结果等），测试时就按照相关的测试文档进行。这样以后复测就能省掉很多时间，换个人测试也很方便上手。

经过一个多月的努力，测试组的同事基本上完成了网站所有频道、页面的检查工作（6月8日）。

05年5月23日：迟到的运营组开始运转

研发人员做出来的网站只是一个空空的框架，没有实际的内容填上去，网站就无法上线——打个比方，研发人员把“大楼”盖好了，还需要运营人员把“内部装修”做好。然而面对人员的稀缺和内部调整，一直到5月23日才确定运营组长及组员分工，他们匆匆进入角色，一面熟悉网站后台管理，一面准备内容。6月8日才开始正式的网站内容录入。

在此期间，整个项目组都进入了最后的冲刺阶段。为了确保6月15日网站能够上线，我开始将工作日往后倒推，每一周甚至每一天，需求、美工、开发、测试、运营等环节需要到达什么状态，必须做到心中有数；每天都要盯着进度，一旦有了延误，必须立即找到原因和补救方法。如果实在忙不过来，我就要做出决定砍掉哪些可以延缓的功能模块。

示意图：项目最后突击的日志

05年6月15日：网站正式上线！

值得庆祝的日子到来了。6月15日凌晨我正式向全公司同事报告这个网站正式上线。这是我自己主持研发的第二个网站，也是我非常用心管理的一个项目。我想留下一个参考样板，为公司其他项目的管理摸索经验。我认为这是一个成功的项目是因为：

整个项目组成员在网站上线后都非常兴奋，这应该是公司到目前最成功的一个项目管理实践。公司领导对这个项目的研发表示非常满意。现在的情况是，休整2周后，7月4日按计划我们又启动了第2步移动网站的研发；另外对历史遗留的众多WAP业务的整理开始提上议事日程。我需要更多时间、耐心和细心，和需求、开发、测试等各个环节的同事们密切配合，把公司各个业务的项目都理出头绪来、让研发部为公司业务的不断成长做出贡献，也让技术人员工作“累身不累心”，不要总是“救火”，要能看到辛苦工作的成效。

网站和产品开发没有什么不同！

按我整理的时间表和项目计划，对照微软的流程，你会发现，我完全是按照微软“传统软件”的研发流程去管理这个网站项目，略有不同的地方是，这个网站项目的时间跨度比较小（只有4个月），而且人力资源有限，美工、开发、测试三个环节我只能是并行处理、流水作业，以尽量缩短项目的整体时间。

我也算是“把微软先进的软件研发理念和中国中小企业的具体情况相结合”吧，其中最难的是把项目研发流程的理念灌输给全组同事以统一认识，并能有效的执行下去。很多时候要靠我不断的去PUSH各个环节，做的比较累，但在完成之后，很有成就感，尤其是针对一个团队不断发展和成熟，所做的努力是显而易见的。（未完待续）

1.软件工程三要素的价值
      思考问题的方法可以是由点及面的，也可以是统揽全局的。换成业界最常用的词汇，就是“自上而下”还是“自下而上”的区别。
      “牛屎图”中描述的工具、方法与过程也被称为软件工程的“三要素”。在本书中他们被分解开来思考——并不是要孤立这三个层面，它们实际上是相互作用的。例如“过程”问题，既有实施过程的工具，也有相关的过程方法理论。虽然说方法是“基于一种数据结构的编程实践的结果”，但这是一种非常狭义的定义。这个定义在过程的开发环节是有效的(或者说对“开发方法”的定义)，然而“需求”、“设计”、“测试”等其它环节也有各自的方法论。即使站在具体环节之外，过程本身也有方法论的问题，这还不包括管理方法等等在内。
      由于方法在过程环节以及过程总体层面上具有贯通性，因此保证“方法(或其行为)”实施的“工具”也会出现在过程的各个环节和层面上。这样得到的软件工程模型将不是经典的、层状的“牛屎图”，而可能像太极图一样由阴阳交汇而生万物。为了不使读者认为我已经入了道家理论的歧途，这样的一副图还是交由你们自己去画吧。只不过应该清楚一点，即使画出了太极图的软件工程模型，所见到的仍旧是工程的细部环节，就如同以管窥豹一般——斑是斑，豹是豹。
      把每一个“管见”拼合起来，得到的才能是“豹”，而不是“斑”。所以尽管本书割裂了软件工程的各个要素，并从每个孤立的层面来审视。然而实质上，应该回归到软件工程的本体上来思考问题，而不是仅关注于每一个局部的要素。
      工程的整体问题仍旧是“实现”。

2.RUP就是“杂物箱”
      我也许总是在批评RUP，但是不得不承认它是对前人在软件过程思想方面的高度包容。请注意我用“包容”这个词，而不是按照语言习惯那样用“概括”。因为如果是“高度概括”，那就应该把目光投向瀑布模型，而RUP其实就像一个杂物箱一样“包容”了全部的已知理论。
      可以把RUP定制成其它任何模型所表述的过程形态——RUP本身的特质决定了这一点——因而它也如同一个杂物箱一样放满了各种希奇古怪的东西：你可能从这个杂物箱里面拿出了一把剪刀，或一只苍蝇拍，或者是一根钓杆……
      面对“软件开发”这样的需求，钓杆能有什么作用呢？在你扔掉它之前，请转换一下思维：钓杆可能带给你的团队以精神上的激励。如果你能意识到这一点，那么它将立即转化为生产力——请把钓杆挂在开发部的墙上。
      RUP能不能被用起来，将取决于你刚才那个挑挑捡捡的行为，以及在你拿到“钓杆”后的辨识能力与组织能力。

3.UML与甲骨文之间的异同
      在你真的打算用“甲骨文”来写项目文档之前，请先弄明白UML与甲骨文之间的异同。在本书里，它们都被做为沟通的工具。因此，目标是沟通，而不是“选用工具”。更进一步的推论是：即使你因为个人喜好而选择了甲骨文，也不要试图在结绳记事的原始人面前去用它。UML与甲骨文都是符号文字，都具有像形含义。然而，这并不表明UML符号本身能表达多么丰富的含义。如果要像甲骨文一样用几代人、上千册的论著去解释它，那么UML图的价值也就只剩下象征性意义了。
      出于沟通的必要，UML语言的象征意义在一个图中应当被表述得足够准确和详细，以致对于不同的阅读者来说都提供了充足的信息。然而，一方面UML的规范中没有提供一个标准来衡量“怎样的UML图是描述充分的”；另一方面，UML作为一个语言，也无法直接在某个硬件平台中被语法检错和调试。所以在工程中使用UML图，应该有相应的文字来描述它。而且，这种描述与图之间的对应关系要持续地维护下去。如果这种关系松散了、断裂了，那么下一个阅读UML图的人所面对的将是无异于甲骨文出土时的困境。好在做UML图的那个工程设计人员(在辞世之前)还有机会为这些古怪符号写下规约。

4.经营者离开发者很远，反之亦然
      使我第一次意识到EHM模型反应了角色所关注的不同视角的人，是我的老板。
事实上，他是一个完全不懂软件技术的老板。在EHM模型中，他所处于的位置在最右端，而开发者在最左端，在二者之间没有相同的关注界面(关注点)。EHM真实地反应了“老板不懂技术”的合理性，同样也真实地反应了“开发者转型为老板”的道路将是相当地漫长与艰难。
      于是，担任中间角色的项目经理就有了一种使命：协调经营者与开发者之间的沟通。例如招来一名开发高手，对于公司的运作并不会有深入的影响(当然，如果你招来了Anders Hejlsberg就另当别论)。因此，我甚至不需要与BOSS讨论这名高手的来历及作用。同样，与一个技术分析人员讨论一个产品的技术价值、市场价值之间的差异，以及市场运作方式与技术实现手段的无关性是毫无必要的。
你要理解这种根源：角色的关注层面完全不同。

5.矛盾：实现目标与保障质量
      在需求阶段我们会面临“目标”的问题,然而在大多数时候，与此相反的是我们会在项目交付和试用时才会碰到客户在质量上的投诉。
      需求人员会把所有的责任归咎到开发人员，而开发人员又不停地埋怨需求的不清不楚或者变更的没完没了。如果正巧需求和开发都是由同一个人或者同一小组来做的，那么他们便会开始埋怨客户的苛刻以及工期的紧张。
总之一件事，没有人会跳出来说：我们原本就错了。然而，事实上根本问题可能是：我们把目标定错了。
      可以看到，在项目的平衡三角(时间、资源和功能)中讨论的是目标问题，但并不讨论质量问题。也就是说，经典教材中总是关注如何更快的完成项目，并减少资源占用，以及实现更多的功能。但是，即使平衡了这种关系，项目的结果仍可能产生一个天生的残障。因为目标可能在平衡中确立，但质量却要在过程中控制。即使在时间、资源和功能三者中取得了平衡，并且客户、项目组和公司同样满意于这个平衡“目标”，但它仍然有可能是“不能实施”的。
      如果原定的目标本身就过大，那么无论如何平衡这三者之间的关系，其结果仍旧是保障不了质量。
      问题是：又有谁愿意在最初签订协议的时候，就降低或者放弃协议标准呢？

6.枝节与细节
      前面说到目标和质量的问题时，提及“平衡时间、资源和功能三者的关系”。这其实是一个实施过程中的细节。或者说，它是一个具体的方法，而不是目的。
      所以我们通常所说的细节，其实是对实施方法的一些有限量的描绘。比如“软件工艺”概念本身的提出，就是考究“细节问题”的。从这个角度上来说，我并不反对“细节决定成败”的观点。但请注意一个前提：这是技术或方法的细部。
      我在前文中一再地混用了“细节”与“枝节”这两个词。枝节是事实发展的次要的分枝，它不涉及行为本身，也不是对行为本身的考量。因此我在前面的文字中说到“跳出细节”，本意是“跳出枝节”——细节只有做到何种程度的问题，而并不是关不关注(或做不做)的问题。
大多数情况下，管理人员有责任去审核、评估其它成员的工作成果。这个时候可以讨论“细节决定成败”类似的问题，因为这决定了产品的最终质量，而质量是工程的目标之一。
      而在另一些情况下，例如管理人员做事件决策的时候，就必须要学会忽略枝节问题。
      混淆这两个名词的使用，其根本原因在于一大部分读者并不能区分“细节”与“枝节”。从惯于“实做”的程序员一路走来的工程人员，很难分清自己什么时候是在“工作”，而什么时候是在“决策”。
      因此我只好用最笨的方法提示管理者：别管它是细节还是枝节，只要你感到你的脚趾已经沾上了泥淖，就快点回头。
      用脚趾去感觉，有时比用头脑去思维来得有效。

7.灵活的软件工程
      并不像现代人想象的那样，古诗词一定是“逐字论平仄”的。变化或者变通，其实是常见之事。因此古词谱中，才常会见到冠以“摊破”、“减字”、“添字”等字的词格。然而古人在词格上的这种变通，是基于“音律”的。通常说的词律是指词格，这与音律是两回事。词律(格)是平仄，音律则是乐器、音调与歌舞。古词中用来吟唱与歌舞的词牌就不能混用，律不同，调不同，如是之。然而古词的音律(亦即是律谱)已经失传了，也就是说，今天的词是用来读的，不是唱，也不是舞，甚至连吟哦也不是。所以今人总是拿普通话中的一、二声作为平声，三、四声为仄声来填词，并以此论平仄，而全然不想词的格律的根基是“词律”与“音律”这两个部分的融合。
      我曾经参与过一个讨论，叫“古人是如何说话的”。在我看来，古人做文章和说话是两回事，文章中之乎者也，日常交流中还是市井俚语的。因此评论中会说“以俚语入词”。也可见填词做文章与说话毕竟是不同。再者，说话也存在方言的问题，因此方言之间平仄音调也不尽相同。古代的歌妓是要求会“官话”的，这相当于现在“普通话”的地位，她们歌唱起来，也是用的“官话”。
      更进一步的推论是：古代的词律中的平仄是以官话为基础的。然而如今的普通话毕竟不是古时的“官话”。也就是说，即使我们以普通话的四声为基础讨论平仄，在古人看来，也是可笑的，这样做出来的词依旧不可唱，也不可读。因此今人做词的标准是应该重定的了，除了词格(这里仅指字句的格式)和用韵之外，其它的部分是无法遵循的了。在各自的平仄以及句式上，应当以“能通顺”和“能品味”为准，风格上则以古雅为益。
      仅此而已。
      对于我这样的格律观点，一位网友曾有一句“未蕴而变，自欺也；知律而变，智者之道也”，实为良言。变向不变求。不变者，万变之所源，亦万变之所归。习诗词之法度，若蚕虫之结茧，若无结茧于前，何有破茧于后？故，知律而变，智者之道也。
      “知律而变”中的“律”字，若解释为“规律”，便是可以用于软件工程中了。“道”是规律，如果明“道”，而可以变化无穷，这样做软件工程才是活的。就如同今人难于填词一样，不明道，则不明智，不明智则无所以为，因而在软件工程实施中不可避免地盲目与停滞。
      “知律”的另一层意思，是在于“知道原理”。明白“为什么要这样”或者“为什么不是那样”。这在软件开发中是常见的问题，大多数人不知究竟地使用着技巧和方法，而一旦出了问题，则归咎于这些技巧和方法的不好。而真正的问题在于，这些人(我们通常叫做Copy&Paster)并不知道这些技巧、技术和方法的原理，因而不知道变通，也不知道回避错误。
      死读一本《软件工程》的人不会做真正的软件工程，所以我写了本书，聊做软件工程实践者的思想之著。

摘要：“龙”不应该翻译成dragon。Dragon的本意是凶残的巨兽、恶魔、悍妇等。中国人在外国人面前自称dragon，是自我妖魔化。“龙”也不应该翻译成long。Long的英文发音不是“龙”，而是“狼”，这不是真正的音译。“龙”应该翻译成loong，它的发音和“龙”相近，在英文中本来就是“龙”字的音译，有些西方人也把龙称为loong，有广泛的使用基础。Loong的两个“O”字母象龙的两只眼睛，loong使人联想到long（长），所以它也是一个象形文字，和汉字特色相通。而long在形象上是独眼龙。

“龙”是中华民族的象征，在中译英时，“龙”被翻译成Dragon。

但是在英文中，dragon是邪恶的怪物，还有“凶暴的人，悍妇”等含义。在图画中，dragon的身躯庞大笨拙，颜色是黑灰色的，长着巨大的翅膀，口中吐火，吞噬人和动物，非常丑陋恐怖，和中国的龙完全两样。

中国人在西方人面前自称“Dragon”或“Descendants of the Dragon”（龙的传人（后裔）），西方人当然要把中国人看成是恶魔、坏人了。所以我们再也不能把“龙”翻译成“Dragon”了！

有人建议把“龙”音译成“Long”。

但是“long”的英文发音和“龙”完全两样，相当于中文的“狼”，并非真正的音译。当西方人指着龙说“long”时，中国人还必须纠正他的发音，不仅增加了交流的困难，还会引起对方的困惑。Long在英文中是一个使用非常普遍的常用词，含义本来就很多，把龙翻译成long也会造成意义上的混乱。所以不能简单地把龙的拼音字母作为龙的英文音译。

既然是把中文“龙”音译成英文，那么在英文中的发音就应该和“龙”相近，否则就不是真正的音译。

英文中对“龙”字的音译是“Loong”，姓氏“龙”和人名中的“龙”字也被翻译成“loong”，例如新加坡总理李显龙的名字被翻译成“Lee Hsien Loong”。在一些涉及龙的文字中，“龙”也的确被称为“loong”。因此，把“龙”翻译成“loong”才是真正的音译，而且它已经有了广泛的使用基础，也符合海外华人的习惯，有利于团结海外华人。

Loong的两个“O”字母，就象龙的两只大眼睛，loong在文字上又和“long”相近，给人“长”的感觉（很多西方人有意把“long long ago”写成“loong loong ago”），因此loong还具有象形文字的特点，和中文汉字有暗合之妙。而long则有“独眼龙”之嫌。

英文中本来没有loong这个单词，因此把“龙”翻译成loong，不会引发歧义。所以，“龙”应该翻译成“loong”。（作者为华东师范大学传播学院教师）

1、都是靠出卖为生。
2、吃青春饭，人老珠黄肯定混不下去。
3、越高级收入越高，当然中间人的抽头会更高。
4、生活没有规律。以夜生活为主，如果需要，凌晨也要加班。
5、名声越大，越容易受到青睐。
6、必须尽最大可能满足客户各种各样非正常的需求。
7、鼓励创新精神。
8、喜欢扎堆。程序员集中的地方称为软件园，妓女集中的地方叫红灯区。
9、流动性较大，正常情况下没有工会。
10、如果怀孕了，既不能做程序员，也不能做妓女。
11、都为防病毒的问题而烦恼...
12、当然,个中高手还专门以制毒传毒为乐
13、一个是Microsoft,一个是Plug & Play
14、工作状态相同。工作时精神高度集中，最怕外界干扰。
　　工作完毕身心放松，体会到一种不可替代的工作快乐。
15、女孩子最好还是不要做这两个职业，但还是有很多女孩子做。
16、除非在转行以后，否则都不愿意结婚。
17. 程序员怕查户口的。妓女怕查房的。
18. 妓女工作的地方(床)是程序员最向往的地方
19. 程序界的高手通常很讨厌微软，妓女界的高手嗯。。这个。。恐怕也如此
20. 都是吃青春饭，不过到人老珠黄后，凭着混个脸熟，程序员可以混个管理员，妓女也行，不过俗称老鸨
21. 妓女靠的本钱是三围，程序员靠的可是四围(思维)
22. 程序员为了拉客，通常会在交易前提供一个DEMO，妓女提供的那叫PHOTO
23. 程序员现在出的活时兴叫吃霸、结霸，妓女大姐一律叫波霸
24. 心不在焉的妓女可以一边工作一边do { beep(1); sleep(9) } until overflow心不在焉的程序员也可以一边工作一边navigate到成人网站上去
25. 程序员手册：一套好的人机操作界面要求，对于新手，能够一步一步的引导他进入功能，相反对于熟客，能够直奔主题；妓女同样要遵守程序员手册对人鸡界面的规定
26. 妓女在工作中最怕的是临检，程序员最怕的是停电
27. 新上手的程序员叫菜鸟，刚入行的妓女叫雏鸡，都是好可怜的小动物
28. 程序界现在流行OO的方法，虽然在XXXX年前妓女已在床上掌握了O～O～～～的技术
29. 程序员为了拉客，无奈之时，也可以先让客人试玩，妓女当然有时也会先给你甜头

不过总之程序员比妓女还惨，补充如下：
1. ; 妓女每个月总有几天可以理直气壮的说不，程序员如果老板不发话，可要一年干到黑
2. 女人做程序那叫奇女、才女，男人要是做妓，那就叫鸭了
3. 妓女不干了人家那叫从良，程序员如果不干了，估计是下了岗
4. 程序员有千年虫问题，妓女好象没听说有
5. 妓女的工作隐蔽性很强，程序员的工作只怕亲戚朋友都知道，所以更加没脸皮
6. 程序员做的越好，要做的程序越多，妓女做的好，就可以挑三拣四
7. 程序员现在流行FREE、OPEN什么的，说白了就是自己玩自己，妓女界好象还没这样恶性竞争