[事后反思]个人项目反思

　　本次个人项目分略低，在细细研究了一下测试点，然后从网站上下载完自己的程序以后才发现自己交的工程不是最新的...我自己新建了一个Finished的文件夹又核查了一遍bug，在最新的版本里把某个bug修复了，然而网站上还是自信满满地上传了原先那个版本的工程文件。

　　由是引发了博主以下感慨：版本控制工具真是必不可少啊，以后只要是个项目，就得合理使用Git来控制版本。

　　反思其他方面，个人项目对-n和-r的错误输入没有设防，毫无防备地被测出没有正确地处理错误的情况，这也是一大失误，没能对错误的情况进行防御。虽然是个人项目，但是基本的出错处理还是很有必要的，以后得慢慢改进。

　　而且我没有进行单元测试！没有单元测试！没有单元测试！自从结对项目单元测试发现了一个我之前黑盒测试没发现的bug后，我就对单元测试十分喜爱，设计单元测试的过程，实际上也是对解题思路的又一次整理，真是非常好的一种复审。

　　半个月后再看自己的代码，真的是没有注释，没有明晰的结构，代码写得丑极了，变量命名也特别随便。最近在看《代码大全》，愿能通过一定的阅读与思考来弥补自己的风格上的问题，并且能有好的编码规范。再翻出我的结对项目代码，发现虽然注释写了一大片，但是注释对于整体的把握理解帮助不大，有些函数其实只要点几句就可以说明白整个框架里这个函数的作用，但是自己确实像是翻译代码一样在翻译注释。希望以后能学会有效注释的方法，高效注释~

　　这次犯的另一个比较严重的错误是在风格上的：我在写某个函数时使用了如下代码：

public int Frac(int Mo,int De)
{
　　this.Mo = Mo;
　　this.De = De;
　　Reduce(ref Mo,ref De);
}

　　原意是改变类里的属性Mo和De两个值，最后发现引用到的变量是输入参数里的Mo和De。这种参数与属性大小写毫不区分的风格比较容易犯错，在核桃的建议下，我最后采用了参数使用小写，类属性大写的写法，这样能区分开两种变量，不会因为没加this前缀而蛋疼不已。

　　这次还犯的一个错误就是我在比较两个二元式是否相等时，自定义了一个static的Equals方法，但是后来发现这个方法很容易和对象本身的Equals混淆使用...我一开始就因为这个错误一直纠结不已，以后在命名时不能再弄这种容易引起歧义用法的方法名字了，坚决不！

　　我的高中老师吕老师常说：“答案不能让人成长，只有反思才能”，希望这篇反思能让我常常想起这次做项目的惨痛经历，以勉励自己。