主站后台开发规范

1. 开发流程

1. 调研、评审、立项，最终形成调研文档和设计文档。
2. 在产品代码trunk主干上开始进行开发。项目的开发需要符合编码规范，SVN上提交代码时的日志需要符合SVN日志规范。
3. 项目开发完成后，需要做相关的测试，需要包含单元测试、流程测试、功能测试、质量测试、性能测试等。需要测试组进行的测试通过公司邮件或redmine提测。
4. 通过redmine与测试组进行沟通，结合测试的反馈结果对代码进行修改。
5. 测试通过后，提请上线申请。
6. 上线申请被批准后，将项目的代码合并prod分支上，向运维组发送上线邮件。
7. 配合运维组上线产品，及时回测，并在上线初期经常监控产品线上状态，应对突发情况。

2. 代码管理

主站开发使用SVN来进行代码管理，产品代码分为trunk和prod分支，其中trunk是主干，用来开发和测试，prod是上线分支，是由trunk上通过测试的代码merge而来。为对于长期的项目，为避免互相影响，也可以在新建分支上进行开发。使用SVN管理代码是应该遵循以下规范。

1. 上传内容：保证SVN上保存的是“干净”的代码，不得有编译后再次生成的代码，如Java字节码文件和JSP生成文件，也不能有IDE生成文件。
2. 上传注释：必须加简要的注释，注释的内容应包含开发的项目名称以及功能，在提交合并后代码时，建议将合并时的SVN语句作为日志的一部分进行提交。
3. 上传时间：如果当天工作超过2小时，请上传代码。
4. 上传质量：提交和合并到trunk主干的代码尽量保证是自己测试通过的代码，以免影响别的项目，合并到prod分支的代码必须是通过测试部门测试并被允许上线的代码。

3. 项目管理

主站使用maven和gradle来进行项目管理，其中maven主要是供开发时使用，而gradle则在测试和上线时使用。

1. 在添加项目依赖的时候注意同时在两者的配置文件中添加。
2. trunk分支不要依赖prod的jar包。

4. 项目编码

主站的产品主要使用Java语言来进行开发的，严格遵循Sun公司的Java编码规范。此外还有以下补充。
大小写
常量的字母全部大写，单词之间用一个下划线字符(_)进行分隔。除常量外的命名采用大小写混合，提高名字的可读性。一般采用小写字母，但是类和接口的名字的首字母，以及任何中间单词的首字母应该大写。
编码格式

1. 确保IDE工作环境使用UTF-8编码格式。
2. 缩进一律使用空格而非Tab。
3. 缩进一律采用4空格。
4. 避免做reformate操作，这个操作会破坏代码的修改历史。

常量定义
对具有特殊意义的数字或字符要以常量的形式定义，并说明常量所表示的意义，避免幻数的出现。

统一定义公共常量
对于一些公共常量的使用，应该单独定义相应的常量类，并统一使用，避免在各业务类、功能类中分别定义、直接使用。

命名规则

1. package：
   1.1 package: 每一个包的名称总是小写，暂定将com.niux.+(模块名)作为总前缀，比如com.niux.api.services、com.niux.api.model；
   1.2 明确不同业务建议建立子package，比如有关deal业务的：com.niux.api.services.deal、com.niux.api.model.deal；
   1.3 如果整套接口有本质性的极其大的变化，并且旧的接口要废弃，会考虑使用com.niux.api2的形式出现，当前暂无此考虑；

2. class类：类名必须是名词，且以大写字母开头。类名应该简单清晰。

3. interface类：
   3.1 Interface命名上，暂定以XxxService的形式提供；
   3.2 最终提供的接口应以Java Interface的形式出现；
   3.3 每个独立的业务的Interface应该有独立的package包，一个package下可包含该业务模块下的多个Interface；
   3.4 每个Interface的一个方法对应所谓的一个“中间层服务接口”，需要按照规范书写该接口的说明；

4. memcache缓存命名规则：对memcache的key要采用命名空间，以避免冲突，同时要考虑缓存的命中率，不要浪费缓存的空间。

controller，interface类，接口实现类编写注意事项

1. controller类里不要写复杂业务逻辑，不能直接调用Biz类（Biz类是对DAO的简单封装），复杂逻辑的实现和Biz调用要放到service实现类里完成。
2. interface接口定义类只定义方法，方法的实现要在实现类里完成，interface接口以xxxService结尾，接口实现类以xxxServiceImpl结尾。

注释

1. 方法注释：每个接口、方法应该有一个方法的整体说明，包括方法实现的功能、参数的详细含义、返回值的取值及其详细含义。
2. 类注释：对于工具类或者流程类，需要在类的注释中对于类的功能进行详细的说明；对于Model类，要对其重要的属性添加注释，注明其含义，必要时要重载hashCode和equals，toString方法。

对功能性模块的抽象
业务模块的开发过程中，应该避免过长的方法，进行合理的功能模块的提取以及抽象，避免同一段代码、类似代码到处copy的情况。

5. 日志规范

主站的监控和统计需要日志的支持。
日志级别
根据日志的严重程度和功能所划分成以下五种：
FETAL：致命的错误，程序不能或不应该正常运行。FETAL级别的日志主要用于记录非常严重而导致程序不能正常运行的错误，比如得不到FileSystem对象、Job运行失败、ODFS写重要的数据文件不成功等。
ERROR：严重的错误，但不影响程序流程，Tool可以继续运行。ERROR级别的日志主要用于记录虽然严重但不至于影响程序运行的错误，比如Parser解析失败等。代码中捕获异常后输出的日志一部分会属于ERROR级别。
WARN： 警告日志，不影响程序流程，Tool可以继续运行。WARN级别的日志与ERROR级别的日志有一些相似，但通常是不能准确判断是否出现问题，需要人来判 断，比如某轮待抓取的数据为0；而ERROR级别的日志通常是在程序运行过程中就可以发现代码、流程或数据等的某一方面或几方面存在问题。
INFO：信息日志，不影响程序流程，Tool可以继续运行。INFO级别的日志主要用来记录一些需要统计的信息，比如抓取统计，以及一些必要的诸如程序启停等信息。
DEBUG：调试日志，不影响程序流程，Tool可以继续运行。DEBUG级别的日志主要用于记录调试所用到的信息，在线上运行的过程中该级别的日志不会输出。

设计这些日志级别是为了方便的对日志进行过滤，对于线上系统，一般会将日志级别设置为WARN，这是为了让维护人员能够根据日志迅速判断问题，另一方面不会因为频繁的写磁盘也带来性能问题。而在查找具体问题时，可能要将日志级别调到DEBUG，希望通过更多的输出信息来定位问题。

日志格式
日志格式指的是输出到日志文件的每一条日志所遵循的格式。为方便起见，每一条日志格式都由若干个“key=value”这样的属性对组成，不同的属性对之间用制表符（即“\t”）分隔。有几个特殊的属性稍有区别，不采用“key=value”这样的形式：

1. 时间：时间是一条日志的第一项。而由于outlog会采用“yyyyMMddHHmmssSS”这样的格式自动记录日志的时间，所以无需再增加“key=value”这种格式的时间。
2. 级别：级别是一条日志的第二项。级别采用“[LEVEL]”这种形式，如“[INFO]”。
3. 消息体：消息体是一条日志的最后一项。为更直观，消息体也不采用“key=value”的格式，而直接输出，如“This is a message.”。

除此之外的其他属性均采用“key=value”的格式。这些属性对位于级别和消息体之间，以制表符（即“\t”）分隔，无需排序。 对于“key=value”中的“key”，有一些常用的值可以定义为常量，如“CLASS（类名）”、“ERROR（错误类型）”等，对于非常见或特殊需求的“key”，可以在记log的时候自己定义，解析的时候注意保持一致即可。 属性中还有一个特殊的属性，即“ERROR（错误类型）”，用于表示错误的类型。ERROR和FETAL级别的日志中需要包含该属性，其他级别的日志中无需包括。“ERROR”属性的取值会有一个固定的范围，包括但不限于以下几种：
IOException
ConnectionRefused

6. 项目测试

开发完成后，项目需要交由测试组进行测试。测试包括单元测试、功能测试（包括安全性测试）和性能测试。单元测试指的是检查测试覆盖率，运行单元测试检查通过率。功能测试指的是运行根据需求文档和设计文档编写的测试用例，发现功能上的各种Bug。安全性测试指 的是测试系统是否存在XSS等安全漏洞。性能测试指的是测试系统中各模块（DS、LS等）的吞吐、响应时间以及随着线程增多两者值的变化情况。

测试之前,开发人员需要通过公司邮件向测试组提交测试申请并通过redmine根据测试结果进行调整和修改。整个过程大概是这样的：

1. 首先部署好测试环境，通过公司邮件向测试组提请测试，邮件中应该要包含测试环境，测试内容已经一些必要的文件。
2. 测试人员在收到测试申请后，首先进行单元测试，如果测试成功率和覆盖率没有达到要求，会通过redmine回复Bug说明，开发人员根据修改后，根据实际情况要么直接回复提交申请的Bug，要么关闭该Bug重新发出测试申请。
3. 单元测试通过后，测试人员进行功能测试或性能测试。如果有编写测试用例，测试人员需附上评审通过的测试用例。测试时发现的Bug，测试人员在redmine系统中提交，并在测试申请总结中指明。
4. 测试完成后，测试人员在测试申请邮件中回复说明Bug的情况，并给出测试是否通过的结论。如果通过，则进入上线申请的流程；如果不通过，开发人员需要修改Bug并重复1-4的步骤，直到测试通过。

7. 项目上线

项目测试通过需要上线时，上线流程大概是这样：

1. 对于比较大的项目，代码在上线之前需要进行代码review,代码review通过后方能进入上线流程。
2. 发送上线申请邮件，邮件有固定的模板，上面包含项目项目的SVN地址、版本号、产品经理、开发人员、测试人员、项目负责人、新功能等，另外还需要包含上线失败的回滚方案。
3. 在测试人员、产品经理、开发人员和项目负责人回复“同意上线”后，开发人员将代码合并到prod分支，运维人员会安排新代码部署线上服务，并回复上线成功与否。
4. 测试人员回测上线后的服务。如果回测没有问题，回复上线没问题。如果回测有问题，会立即找研发人员和运维人员确认，确认仍然可以继续运行的，回复回测没问题的邮件，同时针对出现的问题报相应的bug；如果确认服务不能继续运行，需要运维人员回滚服务，研发人员、测试人员和运维人员一起总结问题。
5. 对于前台服务，需要严格执行以上流程。对于后台服务，在运维工作交给运维人员之后，原则上也需要执行以上流程，如果有特殊情况，请及时说明。