关于我们的思考
——“项目开发”及读《人月神话》有感
项目开发终于结束了，按项目流程，我应该写一份《项目开发总结报告》。拿来“GB856T——88”标准文档，有框架指导我该写些什么，但是怎么能让这些框架协束缚了自由的思想呢？于是决定换一种形式。
项目开发接近尾声的时候，也是最关键的时候，有人送来一本《人月神话》。我很幸运能在这个时候读这本书，因为会有很多思考，关于项目，关于团队，关于我们……
经过两个多月的艰苦熬战，我惊奇的发现我们的系统竟然可以良好的运行，而且完成了需求里所有的功能；虽然并没有完全按原计划完成，但仍可以说：“我们创造了一个神话！”
这段日子每个人都很辛苦。我们日落而作，日出而息；吃方便面，炒鸡蛋；24小时在电脑旁边……这不正是我们曾经梦想的生活么？辛苦的日子总是令人回味的，让我们一起回味这段永生难忘的日子吧。
我们把这块骨头啃下来了，就是我们的成功；我们为最终的成功迈出了第一步。当然，我们还有很多不足的地方。成功还是失败，很难下一个具体的定义。不以成败论英雄，不拿胜负谈输赢。重要的是我们能从这次项目开发中学到什么。
如果要指出项目的成功之处，“需求分析”算一个，详尽明确的需求分析为设计和开发明确了方向；失败的地方主要应该在协作开发上，否则我们可能会更早的完成任务。
虽然我们这里有些人在一起合作过，但对于整个团队来说我们是第一次合作，算做一次尝试，我们应该从中吸取经验教训，找到一条适合我们发展的道路。下面把项目中遇到的，我想到的，结合《人月神话》中谈到的一一列出来与大家一起讨论。
毛主席说：“不打无准备之战。”
我们的这一战作了充分的准备。接到客户的“需求说明书”后便着手分析哪些是可行的，哪些是不可行的。经过多次的协商，终于得到了一份双方都认可的《需求分析说明书》。与此同时对项目中必须要完成的技术进行研究，抢得了时间。
在《人月神化》中有一段被截取，称为“程序员的苦与乐”，在网上广为流传。Brooks大师用简短的篇幅，描绘出整个程序世界的苦与乐。在这次项目开发中，有两个苦恼体现的比较明显。
一是追求完美。“因为计算机是以这样的方式来变戏法的：如果口语中的一个字符、一个停顿，没有与正确的形式一致，魔术就不会出现（现实中，很少的人类活动要求完美，所以人类对它本来就不习惯）。实际上，我认为，学习编程最困难的部分，是将做事的方式向追求完美的方向调整。”
看来我再次做出了正确的选择，我是个追求完美的人，而且我也一直认为程序员就应该有这种本性。在写程序的时候，甚至对一个变量名我都要反复斟酌，直到选择一个我认为可以表达这个变量的意义的。我并不认为这是在浪费时间：一是有助于对程序的理解和维护，好的程序本身就是注释；二是减少错误发生的可能。这次开发因为时间短，我尝试采用设计->编码->编译的方式来写程序，经常把一个几千行代码的模块写完之后才开始调试。效果不错，因为对设计考虑的比较充分，基本上都是一些拼写上的错误。不过有一个错误却另我苦恼了很久。因为一个结构的成员变量名与函数参数的变量名一样，而这个参数又在多处使用，写的时候，也可能是拷贝代码的时候，很容易把结构名给忘记或多加了一个结构名，而这时又不会有语法上的错误。吸取了这次教训，我把整个程序检查了一便，并做了一些修改。这段程序我参考的一位大师的原型，令我欣慰的是，他的下一个版本和我的程序做出了同样的一些修改。
另一个“苦恼来自设定目标、供给资源、提供信息。编程人员很少能控制工作环境和工作目标。”后面章节又提到“结构师获得了所有的创造发明的快乐，剥夺了实现人员的创造力”。“实现同样是一项高级的创造性活动。具体实现中创造和发明的机会，产东会因为指定了外部技术说明而大为减少，相反创造性活动会因为规范化而得到增强，整个产品也一样。”程序员要学会放弃一部分乐趣，整个项目也一样，这是我读《人月神化》感触最深的一点。
设计网络认证的时候，本打算用一种简单的认证方式实现，因为这不是重点。Y提出用证书加自己写的Socket类实现认证的通讯过程。这是一个很好的创意，但VC写出类无法在Delphi里使用，BCB也不行。封装，回调……大家都搞晕了，只剩下两个字：“放弃”。
由于时间比较紧，产品的功能上也放弃了一些认为是很有创意的，但需求中没有提到的部分。后面的开发中也有类似的问题，每个人都按自己的喜好调用和提供接口，可以说是八仙过海，各显神通。问题主要在于交流。
1．一切仿佛都很正常
由于做了充分的准备，每个人心里的那股劲儿也已经憋了很久了，一切仿佛都是按照“项目计划”中的步骤在紧张有序的进行着。可是没过多久，问题一个接一个的暴露出来了。先是Delphi没法调用Visual C++写的DLL导出类，然后一些人对自己的工作不明确，接着模块的接口没有按照事先约定的实现，之后调用方又不知道在什么情况下调用哪一个接口……
虽然问题并不是非常严重，而且也都得到了解决，但事实的确如此。有客观方面的原因，比如是在网络上协同开发，但网络的资源是否被有效的利用了呢？有技术方面的原因，比如在编程语言上的缺陷，不能随心所选择一种合适的语言，只能选择一个合适的模块。你可以说：“其实其他公司也差不多如此。”但怎么能把别人的缺点当作自我满足的标尺呢？这都不是主要原因，在设计的时候也都考虑到了，如搭建企业内部协作平台，增加中心调用控制模块。最重要的是交流的不够，或方式不合理。人与人之间的交流是影响整个项目开发的关键，这是我在项目开发中体会最深的一点。
2．交流方式
人月之所以不能成为神化，正是因为增加人手的同时也增加了人与人之间的交流。
我们在项目一开始就通过QQ群组进行沟通，后来又搭建了企业内部协作平台，而且还有不定期的会议。与大师所说的三种交流途径——非正式途径、会议、工作手册——不谋而合。但是，执行的效果却不很理想。是大师说的不对？不是。是我们没有利用好这几种途径。我们很好的利用会议，解决很多细小方面的误解；过多的使用QQ群组，一是在登陆QQ的时候消息太多而没看仔细，二是这种方式针对小的误解是很有效的，但对于一些系统的全面的理解必须通过文档；但是很少使用协作平台，没有仔细的阅读文档的习惯，也没有写出一个完整文档的习惯。
即使在QQ群组的交流中，也没有把问题表述清楚。经常看到：“某某：你那里有问题？”哪里？什么问题？QQ都是通过UDP传输的，这里就不需要发送ACK了，对方不在线可以通过服务器中转，到论坛发一个贴子或直接发送邮件。接着有人回答：“不可能啊？”什么事情都可能发生的，只要能满足条件。域名都会不易而飞，还有什么是不可能的呢？出了问题首先从自身找原因，发现一切的可能。
3．如何阅读别人的文档
首先必须摆正姿态，把阅读文档当成一种习惯，不要抱有不懂再问的心理，写文档的目的之一就是减少交流的次数，如果你问了一个文档中描述的很清楚的问题，你得到的回答将是：“去看文档。”
其次你要知道这是一篇关于什么的文档，对于整个项目手册来说它处于一个什么样的位置，可以根据你的需要读取相关的部分。
再次，当读到不明白的地方，从文档作者的角度出发，想一下为什么是这样。你要尊重他人的劳动成果，也许你觉得很平常的一句话，却是作者用86400ms*1K脑细胞换来的（一个脑细胞对应一个方法）。
最后，如果还是想不通，可以查阅相关的文档，或到网上去搜索相关资料。实在是想不通，再把你想不通地方整理好，最好也是用文档的形式，也可以直接告诉作者，等待回复。也许你是对的，但在得到正式确定之前必须按照原文档中所说的去做，以保证整个系统的完整性。
4．如何写文档
由于项目开发周期十分短，我只定义了各个模块的功能，接口标准，和接口说明的标准。这就要求每个成员把自己模块接口的详细说明提供给调用者。但很少有人按照给出的标准书写接口和文档，而且文档说明也不够详细。
为什么要写文档？一是减少交流的次数，提高效率；二是得到清楚、确定的策略，接口说明应该在接口实现之前就已经写好；三是为整个项目的规划提供依据。
文档并不一定要按照标准来写，但标准有助于交流。一个好的文档应该让一个没的接触过此项目的人一看就明白你想要做什么，怎么做。有些时候阅读的人只读他感兴趣的部分，因此尽量在每一个部分就把事情描述清楚，如果是引用或继承要说明出处。不要怕麻烦，现在的一点点工作会为以后带来很多方便，否则会适得其反。
期待已久的整合工作开始了，不过要比以前更加忙碌。大家开始互相指责，一个说：“你的文档没说清楚”，另一个说：“听不懂你在说什么”；一个说：“我这里没问题”，另一个说：“我这里代码很简单”……
为什么会这样呢？除了上面谈到的几点之外，还有一点就是对测试的理解。客观条件的限制使我们必须自己动手测试。模块开发人员负责单元测试和集成测试；其他人员进行系统测试和验收测试。但在测试过程中对一个问题常常需要几番周折，甚至用重装系统来证明自己的无辜。一切都是有原因的，现在的麻烦是因为开始准备不足。可以从下面几个问题来证明这一点：
你是否为模块做了详细的设计？包括提供的接口，引用的模块、实现的流程、使用的对象等。一个设计良好的模块应该很容易定位到出错的地方。
你的模块是否有可测试性？当错误发生时，应该有错误类型的说明或代号，或者记录出错的过程。这里包括对工具的使用，调试的技巧等。没有测试不了的模块，只是方法和时间上的问题。
你是否为你的模块编写了测试工具？DLL调用，消息处理，临界条件等不好手工测试的部分应该写一份测试工具，也许这个小工具会给你带来一些创造的乐趣。
你是否对测试做了计划？不是每次都那么好运，一下就能测试出问题。而且一个问题的发现可能会联想到另一个问题。
你是否对测试出的问题做了详细的记录？只告诉开发人员：“你那里有问题！”是没有任何意义的，这里又回到文档的交流上。没有文档就很难对BUG进行跟踪，有些BUG要说很多次才能修正好。
另外还有一点就是整合的时间太晚，问题都堆在了一起。在设计这个系统的时候是想尽早的做出一个可用的系统，拿怕只有“退出”生效。这种设计也可以称为原型法，不但有助与程序员对整个系统结构的理解，还可以鼓舞士气。但由于上面提到的和一些其它没有在这里讲到的一些问题，导致这个可用的系统一直未能谋面。
从上面的分析可以看到我们存在很多问题，但我们还是把项目开发完了。因为我们有一个法宝——激情，激情可以战胜任何困难。
“我们来自五湖四海，各自为了心中的梦想在网络的世界里寻找自己的坐标。也许是缘分，也许是偶然，也许是心中共同的信念和梦想，让我们走到一起；共同努力，相互帮助，默默奉献着自己的力量，在技术的天地中贪婪地汲取养分，渴望成长，渴望强大。”“感谢上帝让我成为了为数不多的那些开开心心地做着自己喜欢的工作的人之一”。
回想这三个月里的日日夜夜，是一种骄傲与自豪。有人问我这么辛苦是为了什么？我也常常问自己，为谁？为钱？都不是。因为我年轻，因为我有激情，因为我从不后悔。在网上游荡的时候，看到一段话，值得回味：
无情的岁月让我们一秒秒地老去
慢慢地封存在发黄的照片里……
在回首过去的时候……
在那渐渐被遗忘的岁月中
我们应该要为自己的人生留下感动的回忆和汗水……
记得有段时间我们每天MOHAA，而且也颇有心得，还小有名气。于是有人问：“为什么这样，你的激情呢？”我回答：“一个人，不管做什么事都要有一个目标。目标就是动力，失去了目标也就没有了激情……”在游戏人生的日子里，的确没有学到多少东西，但是我们不后悔。至少我们走过来了，我们的人还在；而且也再次证明了我们的实力，“我们是冠军”。
曾经幻想中的帝国大厦如今已变成一堆垃圾，经历了诸多的风风雨雨，我们又回到起点。我们不在迷茫，我们不在徘徊。“投入新的战斗吧，为了不改变一切的理想，为了改变不理想的一切”，再创辉煌。希望我们的故事能够成为更加年轻的，像我们一样拥有激情的人们的榜样。
本文只是我在项目开发和读了《人月神化》之后的一点感想，没有谁的对与错，对于本文一些观点的正确于否欢迎与您一起讨论。本文只是按照项目流程，挑主要的部分叙述了在开发中体会到的一些感想。这次开发让我学到太多太多的东西，将使我终身受益。还有很多的想法，如团队建设、整体设计、开发模式……希望以后能与大家多多交流，相互学习。
《人月神化》这本书推荐大家都去读一下。它不是良药，不能为你解决实际工作中的问题，但它可以给你带来很多思考，让你变得更加成熟。软件工程是为开发软件服务的，标准不是目的，只是手段。《人月神化》没讲标准，但它为怎样做好一个项目提供了一些参考。它会增强你的自信心，当有人反驳你的观点的时候，你可以告诉他：“Brooks大师如是说^-^”。
