项目进入测试，心里慌慌，第一次提测项目，总感觉怪怪的。提测第一天，组内的同事体验了一下，当日无BUG，感觉还行，处理一下由于配置导致的问题，不算是BUG，一天就过去了。下周会正式交付给Web端测试，很期待自己的第一个「BUG」。今天在分享一下自己在整个研发过程中的一些体会。
- 等测试完毕，预计会开源整个后端项目，到时候欢迎各位指正。
代码够规范，BUG改的快
虽然没有收到测试反馈的「BUG」，但是在调试过程和自测阶段还是发现了好些「BUG」，既有需求的没完全理解的，也有实现方式的，总体来讲，BUG虽有，改的挺快。
感觉来说，有两点原因：第一、新项目，后端完全我自己一个完成，而且刚刚完成比较新鲜，所以维护起来比较快速；第二、代码规范比较好，除了遵循公司统一的项目规范以外，由于我用的Groovy和Java混编，所以格外注意了一下Groovy的使用，总的来讲，脚本语言写项目真的比较蹩脚，而且「Intellij」对于Groovy检查不是特别检严格，很多Java编译不通过的地方都能正常编译打包，甚至部署都没事儿。
本项目大概一周左右测试时间，期望顺利上线。
单元测试做不得
项目一开始我打算进行单元测试的，因为毕竟是测试出身，单元测试这种「高级玩意」能上还是要上的，具体的实践文章参考：单元&白盒。
后来发现万万不可，经历过这个项目让我对单元测试和「TDD」有了新的认识，除去常见的原因，比如单测比较费时间、代码量偏高，维护成本太高等等。
我还发现了一个非常重要的因素：「变」。
即使我们这个项目花了大量时间（超出开发和调试）从零开始确定需求，也几乎不存在需求错位等问题（因为产品、前端、后端都是光杆司令，独立完成）。但是在开发和调试阶段还是遇到了很多「疑点」，然后就是进行调整。
我现在觉得除却我还没有见识过的「异界」的项目和团队外，没有适合进行单元测试和「TDD」的机会。我目前的方案就是进行接口测试，然后进行Web端功能测试，加强自测，严格代码规范，统一参数校验。我用的是validation的注解式参数校验，在设计边界值的时候，可以通过定义全局的常量来实现各个bean中的参数校验一致性。
