聊天室项目总结

项目总结报告
1,引言
经过3个星期的苦战，我的聊天室程序基本成功，其间经历种种磨难，终于化成正果。

我把在开发中遇到的困难以及如何把它们解决的过程写成文档，以让自己和看到的人吸取一些教训，也不白费了我三个礼拜的时间。

2，困难和问题
在开发过程中所遇到的问题，都在我的Bug管理程序中可以清清楚楚的看到，你还能看到它们产生的原因，以及我是如何解决的。

可能问题本身的意义并不大，但是解决问题的方法却是值得借鉴的，这些经验给我们以后的开发带来很大的帮助。

问题本身并不可怕，没有解决问题的决心和方法那就很麻烦了。

关于问题解决的经验和方法，在后文会具体讨论。

3，开发中用的方法
3.1，三权分立
在开发过程中我尽可能的按照规划，开发，测试的三权分立原则进行开发。

在程序开发之前先想好程序需要的所有功能（最好文档化，写好需求分析说明书，我是在后来才把说明书补上的），然后按照所需要的功能一一实现。

由于是一个人开发软件，所以不得不集开发和测试大权于一身，边开发边调试，如果是三人以上开发，强
烈建议每个人各司其职，严格把三权分开。

权利的集中容易导致专制和腐败，同样规划，开发，测试权力的集中也会导致程序的腐败，因为没有人喜欢把自己的程序鸡蛋里挑骨头，所以导致许多问题没有被及时发现。

3.2实验试的调试方法
程序中难免有我们所不希望出现的情况，我们往往想让它这样，可它偏偏却那样，及时查找出问题所在，是解决问题出现的关键！
eg1：
无法实现自动滚动屏功能
我们本来用的是JScrollPane的AutoScroll(boolean)方法，从名字上看的确也应该是这个函数，但事实上却不是。

在老师的帮助下，通过不段的实验找到了让它自动滚屏的事件——文本域光标所在位置。

所以后来改用了setSelectedEnd(int)函数，问题得到了解决。

eg2:
服务器启动后cpu占用率总是100%，其他程序运行极其缓慢。

猜测cpu占用率太高，应该是线程上的问题，在服务器程序中一共定义了三个线程1，ServerThread 2,ClientThread 3,MessageSendThread 。

分别关闭每一个线程，发现只要有MessageSendThread存在，cpu占用率永远是100%，那么我们就把目光集中到了MessageSendThread中，经过仔细检查原来是Thread.Sleep(long)函数放错了位置，问题终于得到了解决。

而我原来总是怀疑是ClientThread的问题，因为它最复杂，最容易有问题，而
检查了半天都没发现错误。

即使我们没有怀疑对象，而对整个程序仔细检查，这也是很不经济的，劳民伤残，伤害视力。

通过实验测试，像破案一样把怀疑对象缩小范围，最后在小范围内花大力气解决问题，这也是一条很重要的调试方法！
eg3:
客户端偶尔会连接不上,CPU快的出错概率要小。

文本区打印的是连接失败，而控制台打印的却是空指针的异常，这就另人很奇怪，因为在那个try语句中感觉每一句话都不太会抛出空指针异常，更另人奇怪的是这种异常竟然是随机产生的，你想想，一个不变的程序，在外界环境不变的情况下会有两重不同的结果，这是以前编程从来没有遇到过的事情。

更更奇怪的是，在家里出错不多，而在学校基本上是每连不上，10次里有一次连上就不错了。

开始调试，找原因，我给try语句中的每一句后面都放了一个标记语句，看看程序出错时，是做到哪里开始停。

结果发现是在new 一个消息对象的时候抛出的空指针异常，而消息对象一共有4个参数，后面三个参数是绝对不可能有问题的，只有第一个参数，它传入的是用户名，而用户名是用随机函数计算得到的，可能是这里的问题，为了证实我的想法，我把用户名换成了一个普通的固定的字符串，结果百连百通。

好，我们终于找到了问题的所在，在new 消息对象的时候需要用户名，而此时，用户名还没有计算好，返回了一个null，抛出了空指针异常。

这同时也证明了一件事，学校的电脑太烂了。

那么又如何解决呢？很简单，在new一个消息对象的前面给系统一些时
间，确保它把用户名算出了，那么程序出错的概率会大大减少，而且时间越多，越不容易出错，而这一点点时间对人来说是微不足道的，我们几乎感觉不到。

在这次调试过程中我们不段通过实验来得到一些现象，我们再根据这些现象来猜测问题的根源，再通过实验来证实我们的猜想，最后找到了问题的本质：随机函数计算结果的置后。

马克思的方法论：透过现象看本质，在计算机科学中同样得到了巧妙的运用。

3.3 Bug管理系统
在程序开发过程中，我自制了一个简单的Bug管理系统，用来记录Bug，它的严重程度，它的原因，解决方案，和被解决的状态。

这样一个系统时时提醒你程序中还有多少Bug悬而未决，而不至于让一个刚刚发现的Bug由于没有及时解决而被遗漏。

从某种程度上说，实现程序的功能并不算是程序的难点，真正的困难是和你程序中不段出现的Bug作斗争。

所以我认为Bug才是整个程序的核心，是整个程序的瓶颈。

对Bug的处理好坏直接影响到你程序的成败！花大力气研究如何处理Bug也是理所当然。

磨刀不误砍柴工，Bug管理系统的引入是绝对可以加快整个项目进程提高项目质量的。

Bug管理系统也是众多软件公司必用的先进方法。

4，程序有待改进
4.1设计上的失误
4.1.1 程序结构设计失败
在开发服务器端的时候，将界面程序和服务器程序分离是一大失误，表面上，界面程序和服务器程序的分离可以使程序层次更加清晰，这也是我一开始把它们分离的原因，但是在编程过程中发现，他们在逻辑上有着不可分割的关系，服务器程序要用的界面中的组件，而将它们分离不得不通过传递函数来使它发生联系，这样你就在界面类中看到很多的返回组件的函数。

一方面从结构上它们分离，另一方面从逻辑上它们有紧密联系，服务器程序要不段用到界面程序中的变量，每次要用这些变量都要通过函数传递，消息系统资源是其次，最主要的是程序显得杂乱无章。

其实一开始就应该让ServerFrame extends Thread 。

这样服务器线程要用到组件了直接用下全局变量就可以。

如果你绝得窗口类继承线程类让你感到结构混乱的话，你只要注意你的代码的放置就可以，布局代码放上面，事件代码放中间，服务器线程放最下面，严格分开，中间多打空格，从整体来看，结构是完全清晰的。

4.1.2 消息类定义牵强，不够灵活
在消息传送中，为了能够实现多功能（比如传送一些命令，如更改用户名，发送消息炸弹等），采用了自定义消息类，用变量来标记消息的种类，比如：MESSAGE_ONLY表示是普通消息，MESSAGE_COMMAND_USENAME表明是更改用户名的命令，服务器根据消息不同的种类来处理消息，来达到多功能的目的。

就本程序而言这么做的确是解决要做的事情，但是我要说的是这并不是一个好的方法。

比如说某些消息，它只需要3个参数，这时它不得不为了凑
这个类而放一个哑元，这就让人感觉很牵强，虽然程序可以实现，但是缺乏美感，明明只要3个参数就行了，凭什么多给它一个丫？所以这种处理方法并不好。

应该定义多个类，每一个类有自己的变量，该几个参数就几个参数，服务器处理的时候不是判断类中的参数是什么，而是判断这是什么类，用instanceof关键字判断就可以，这样程序就更容易让人理解，效率也更高。

4.2功能还需完善
还可以添加如下功能：
1，添加文件传输功能
2，添加发送图片表情功能
3，添加在线联机游戏功能
4，添加点歌功能
5，添加视频语音聊天功能
6，添加隐身功能
7，用户列表图标化
柏拉图
二○○五年一月十六日。