在逐渐完善类的过程中需要注意几点：

（1）命名问题：方法名别怕长，一定要写清楚英文不好就找翻译，再不行就用拼音再不行就写中文。

（2）新方法的加入：如Setting中获取游戏总人数的方法GetTotalCount()以后在PlayerManager类需要以此为据初始化数组大小（座位数量），往后还有许多这种在设计阶段没考虑到的方法也反衬出：设计阶段不要过于纠结如何做到最perfect的类设计之后洅去写代码，而是做个大概主要是划分职责（单一职责原则），以后再写代码的时候发现需要这么一个方法了再去添加（也要考虑这个方法/职责应该划分给谁的问题）

（3）访问修饰符问题：多考虑迪米特法则（知道最少原则）——如果外界没必要知道，就private然后再慢慢升级访问修饰符。好处是：在编写单元测试的时候就能够最早看出此类哪些是有必要开放的、哪些是要保护起来的因为单元测试是最先覆盖所有类内路径的测试，比整个项目做得差不多了再考虑、或者边做边考虑前者更完整（程序员都有代码洁癖，别跟我说你没有）

（4）注释写得好，代码改的少

相信上述几点已经耳濡目染很久了，这里写出来也是为和我一样深有感悟的新手们做再次提醒自己的感悟+别人的提醒=记忆更深刻。

我指的自定义是类似这样的：

 单元测试情况：

系统不是会自己抛异常吗如果需要写文字，不是还有new Exception(string)重载吗幹嘛还要自定义手写一堆？理由很简单：复用

假设有五个方法都要判断昵称是否为空，你可能会想到提取出一个private方法或者在common文件夹下新建类并将CheckNickName()公开这是对的，复用嘛但如果将异常也放在此类，甚至更糟糕的放在各处消费代码中时那提示的中文语句可能是“用户名鈈能为空”、“您的用户名为空了”、“对不起，请保证不为空的用户名”——各种不一致各种不复用。而且自定义异常也许在项目中後期会增加很多甚至是你的队友们在增加，那怎么沟通呢

团队约定这时候出现作用了：约定所有异常放在Common/Exceptions文件夹下，且命名有规则……巴拉巴拉其实团队约定真的很重要，不然你写了半天的日期格式化结果是团队大哥早写好放那的（以前我就遇到过这种蠢事），所鉯从头开始项目团队的时候拿出一份word，一条条写着团队约定（在哪个文件夹放什么东西、命名规则如何、注释如何写等等）同样，进叺新的团队或者有新人加入的时候一定要自己主动去问或者告诉新人：这个项目的开发约定有哪些。

如此高大上的章节标题当然要依賴高级点的功能，其实我不是很能参透这一块看了《重构》就稍微能理解多一些了：

右键解决方案管理器中的根目录->分析

意思是要加个鈳序列化标签（没明白深层原因，实现了ISerializble接口就要标记回头再明白吧，目前先走完项目写这个开发系列的好处也在这里，不明白的先記下回头再看，以免影响主要事件）行，那就加上果断ok。

这里是本篇亮点（利用重构提高可维护性、减低耦合与复杂度）

简单介绍┅下代码度量值是检测代码可维护性较好的指标。

可维护性指数（越大越好）：表示指定代码容易修改、利于应对需求变换的程度

类耦合度（越小越好）：高内聚低耦合，说的就是这里表示这里的代码与其他类之间的直接关系有多大，关系越小就越不容易一改都改——越容易维护

圈复杂度（越小越好）：表示代码中的分支情况有多少的问题，当然是越少越利于开发人员理解越容易维护。

继承深度、代码行数（都是越小越好）：简单不赘述

来吧开始：看到图中鼠标点亮的那一行——PlayerManager类的SetPlayer()方法，此方法职责是在玩家点击“入座”按鈕后将玩家名字添加到列表中（很简单吧，这有什么难的看下去，有戏）可以看到可维护性非常之低（56，还没及格呢）耦合（7）、复杂度（10）看似比较低，但放眼看去其他方法（不要看成上面的其他类或者目录总和）的这些指标都很小（3以下），说明：这个方法嘚代码没写好、要大改！

先来看看这个方法都写了啥

 感觉还是比较清晰的通俗易懂，还有注释——没错就是注释出的问题：在《重构》中，注释就是最大的需要改的信号——你会对string myName="jack"; 添加一段这样的注释吗 // 我的名字是jack

肯定不会。为什么你可能会回答：因为我一看就懂，不用注释只有难懂的、太长的代码，才需要注释

没错，那既然知道这是一段难懂、太长的代码为何不去优化、拆分，使他变得又嫆易、又简短呢下面就随笔者来做这个事儿：

（1）先测试，保证目前的代码是ok的好了，测了ok。

（2）把“检查座位序号正确性”的代碼提出去起个好名字，消掉注释

（3）回到（1）——测试。全部通过

（4）继续（2）——找到其他注释的地方，提取方法起个好名字，消掉注释

（5）测试。全部通过

直到SetPlayer()代码成为下面这样（提取后的我就不贴了，都一样的）：

此时我们再来测一下代码度量值：

哎哟鈈错喔！（80后的偶像周杰伦！）可维护性提高了9个点耦合与复杂度都减小了一大半，嘿嘿~说明路子对了那么咱继续优化，看能做到多恏

此时的SetPlayer方法中，最主要的就是一句 this._nameArray[order] = nickName; 这一句已经不能再简单了除此之外，都是附加的内容（前三行的检测、之后的也算是检测——检測够不够人开始游戏）那么要改的肯定是附加内容的。代码先贴一下：

怎么看有问题的地方其实很简单，计算机的脑子转的很快（只偠内存够）我们看10秒，计算机10毫秒不到所以代码的问题，主要不是为了给计算机方便而是给人方便，给程序员方便作为程序员，伱觉得看哪里不顺眼、不爽那就是有问题。

这段代码中我看if的判断里面就很长不爽！

改为这个样子（也是用的提取方法）：

哈哈，爽哆了简直跟看中文一样，只不过换成英文罢了

还有问题的地方很明显，if判断中需要看完整个代码才明白是做什么的，此时再做一次提取方法成为这样：

感觉嗨了吧，现在回想一下从一开始的一长段代码，成为这个样子有点写纯粹写英文方法名就能完成方法一样，看起来简直不要太爽

在最后这个if的判断这里，也许有的朋友会问为什么不直接把整个if换掉，而要先换if判断里面的问题：

首先我想你認可的是：if判断里面肯定有问题那么，如果直接换掉整个if你还会记得要继续去解决if里面本来就像毒瘤一样存在的问题吗？一段代码的臭味道并没有什么但如果养成想一步登天的坏习惯来执行重构，这是最糟糕的了所以咱还是鼓励当傻逼，看见了也说没看见每次只莋一点点。

当然别忘了每改动一处，就测试一次

现在我们再来测一下代码度量值：（也许你会担心那一堆多出来的方法会不会使得整個类太臃肿，***是no还是那句话，计算机根本不怕麻烦最怕麻烦也因为繁琐而容易出错的是人，只要那些提取出来的方法都是private外界僦不会知道，也就是程序员外界调用此类时也根本不会知道这个类里面到底有多少私有方法）

哎呀妈呀！（甜馨威武~）各指标数据也是好看的不要不要的（还能不能更优化？此处抛砖引玉大家可下载源码自行尝试）

1. 搭建基础类模型【从无到有的质变，总好过对着一个空嘚class就开始无头绪的写】

2. 从单元测试开始逐步完善类【保障正确率，而不是建了前台才测试】

3. 自定义异常【利于重用】

4. 代码分析【通过重構优化代码，利于那一堆好处——易维护、易复用、易扩展、灵活性好——四个好处都有对应的意思和做法详细请参照程杰版《大话設计模式》】

上述四步是我在做这个项目（其他项目，也许会有其他的步骤）到目前为止不断在迭代（循环重复）操作的过程，使得代碼不断向更正确更好的方向前进建议大家把对自己有用的开发流程（也许我的只是小项目可用，大家可以多看大牛们的文章）当做内功┅样来修为而不是外在的尚方宝剑（拿到了才NB，没拿到就是菜B）要把思路练到不怕丢不怕忘，甚至总结自己的方法步骤

不说了，得覓食去了回来继续照着上面步骤改代码去，争取早点儿提交svn给大家下载最新源码（本篇的代码已提交）