分布式三子棋游戏设计心得

1、这次实验基本上达到了实验目的，学习并巩固了JAVA的一些重要技术：图形用户界面、多线程、网络编程、流、异常处理等机制。

 

2、这次实验是用JAVA完成的第一个完整的工程性的项目，从无到有的走了一遍JAVA软件设计的流程，从最开始的对题目的分析、到逻辑层的设计、到表示层的设计、到编写代码、到调试、测试。这些，在JAVA平台上是第一次做的。首先，这几天的连续工作让我了解了JAVA的软件设计流程，同时也是一次宝贵的软件设计的经验积累，对于以后我做JAVA软件打下了很好的基础。其次，由于是第一次，其中不免遇到很多问题，这些问题，有的可以反映出自己一些知识的盲区，有的可以反映出自己编码风格的混乱。通过这些问题的解决，不仅可以学到一些以前不会的、或者以前会一点但是没有理解透彻的、或者可以通过调整自己的编码风格来适应工程型问题，而这个调整的过程也就是提高的过程。

 

3、由于做该实验之前对JAVA只有一些浅层次的了解，所以很多东西都是边学边做，这样就缺乏了一个从高的角度来审视问题的平台。也就是说，由于知识和经验的缺乏，没有一个从架构上来分析这个问题出发点，这样导致后来出现了一系列的问题。举一个例子，我一开始就走了一条错误的路：对这个问题应该是自顶而下来解决，而我一开始由于自身技术力量的薄弱，无法把握”顶“这哪里，所以我选择了”自底而上“。我先把这个问题简化为一个简单的通信的程序，于是先写了一个简单的即时通讯的功能（用同学的话讲就是山寨版的QQ），然后再在这个基础上去添加功能，问题就来了，三子棋游戏的连接建立要通过多次”握手“而不是简单的一次；三子棋从信息发送必须是轮询的，而不是想发就发；三子棋有一个要每次改变棋局的信息并且服务器要在这个信息的基础上来判断胜负，而不是简单的把客户机消息丢来丢去等等一系列问题。对一连串的修修补补烦躁之后，最后的手段是重新分层设计了逻辑，重新写了一遍。通过这个事实，可以看到的一个问题的，我们在做工程性项目的时候，架构的重要性。要解决一个大的为题，我们可以把这个问题分小、简化，各个击破，但是真正有技术含量的步骤不在于如何解决那些小问题，而是如果用一个好的划分方式来细分大的问题，使到小问题可以轻松解决并能以最好的方式重新组装。以前我的思维很局限，把子问题都交给类，而现在学会了在类的上面应该还有更高级的层次，那就是层。

 

4、关于这些实验的问题解决。这次实验中确实碰到很多问题。解决这次问题的办法有几种：a：查书、Google、wikipedia，b：问牛人，c：发邮件问老师。我对这几种解决办法总是按其排列的顺序来的。在解决问题的过程中也发现了一些规律：a是最慢的，但是却是最好的，b次之，c在另一个极端。碰到问题自己去弄懂是最好的，因为要解决这个问题，我们可能首先要对问题本身的逻辑十分清晰，否则就无从解决，而我们很多时候就是卡在这第一关的，我们只能采取仔细分析的策略了，很多同学也叫”使劲分析“（也许这就是程序员工作的高强度性原因之一了），通过对逻辑思路的理清，问题有时就豁然开朗了，有的还不行，它又会牵引出另外一个问题，而这个新问题反映了我们对某些相关知识的”模糊理解“，于是我们查书查资料，直到透彻掌握这些知识，问题也就解决了。这一系列过程收获很大：首先培养了逻辑思维、分析能力，然后又有了对旧知识的巩固、对新知识的补充。不过这个方法缺点就是有点慢。

 

5、关于调试。做这个实验有一个很深的体会就是编码不难、调试难。这个体会也是很多同学都有的。服务器和客户端加起来也就1000多行的代码量，而却花了几天时间来调试，分析其原因，我也有和同学讨论过。首先，是我们编程习惯的问题，我们现在往往是还对程序的逻辑不太清楚的情况下就开始敲代码，而我们真正弄清程序逻辑的过程，却是建立在我们的调试过程中的，这无疑给了调试这个过程很大的压力。我们知道，现在很多正规软件的流程是先建UML工程，再在UML的基础上填代码，这就是在逻辑确定的情况下通过代码实现其功能的，和我们的错误做法正好相反。其次，我觉得这是我们知识的深度和广度都不够的问题。很多“牛人”调试时，看到错误就知道是哪里出了问题，我觉得这是他们掌握了很多知识、而且对每一个知识都了解很透彻的结果，看到某一种错误他们可以通过错误本身的特性，结合每个用到的技术的机制，对应到出错的某一或多个出错的代码段。比如，我有一次，服务器要发一个信息给客户机，通过调试确定已经发出了，而客户机也有接收语句在等待接收，但是客户机这条语句就是收不到。找很久不知道错在哪里，请了同学过来看，一眼就看出可能是被其他线程读走了，结果一查，果真如此！为什么那位同学这么“牛”呢？我觉得这应该归功于它知识的深度和广度，通过“读不到”这个问题的本身的特征，在他自己的知识库里搜索所有“读不到”的可能情况，溯源到可能是其他线程读走的原因。还有一种可能，那就是这个同学以前碰到过这种情况，并且已经正确解决了这个问题（当然我这里不是说这个同学不“牛”的意思）。这也是我想讲的我们不会调试的第三个原因，经验缺乏！如果我们经验丰富，就会对海量的错误都会很”敏感“，那些学英语的人看到文档中的错误会”敏感“的结果是建立在他们有了丰富广泛的阅读量的前提上的，同样，调试也是。调的多了，经验丰富了，我们在我们的大脑中会形成一个“错误库”，有的错误正好就落在这个”错误库“里，也就是刚刚举到的碰到相同错误的例子。而有的没有命中，但是我们大脑是一个网络状的，我们可以以这个未命中的错误为关键字索引到类似的错误，再通过这些类似的错误找到本错误可能原因。我们调试经验积累的过程，就是我们不断完善、扩展我们“错误库”的过程，人的大脑内平均有140亿个神经元，假设每个神经元可以存储1B的信息量，再假设我们只用1/1000的神经元数来作为我们“错误库”的存储介质，那这个容量应该相当可观了吧，相信不是GB、TB能驾驭的了得数字。

 

6、关于耐心。很多有丰富经验的“大牛”对我说过，做程序员要有耐心，通过这次的切身体会，我算是明白了。抛开第5条说到的一些“调试难”的原因，耐心可以算是调试的一个法宝了。有时候就是1天18个小时坐在电脑前不动，就为了解决一个错误，甚至还解决不了，那躺在床上了还得继续纠结。我相信没有耐心是坐不住的，多一份耐心，多坚持一分钟，解决问题的概率就大了一分。这个实验我就有两次没能坚持住，把问题留给了明天甚至后天。等到下一次来调试的时候，已经没有了那种浸泡式的状态，而要投入到这种状态又需要很久的时间。

 

7、一鼓作气。这个应该可以承接第6条。一鼓作气的搞定一个程序。一鼓作气的搞定一个程序。能不吃饭尽量不吃饭，能不睡觉尽量不睡觉。如果我们中间有间断，要重新回到那种写程序写到很high，很多方法、线程在大脑里run得很流畅的状态又需要很多的时间，具体多长时间如何计算不知道要如何量化，但是就我的经验来看，视程序的复杂性在15min-60min之间。写完程序，做完测试还没完，直到写完文档才能结，否则，可能又要重新回头去看UML甚至看代码。

 

8、综上所述，这次实验收获可观。“知识库”，“错误库”这些“硬知识”得到扩展，代码风格、编程习惯这些“软知识”也得到提高。不过有一点遗憾就是原来想做一个注册登录的功能，把JDBC也覆盖上，但是由于时间原因，就没能实现了。