主站后台开发规范

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. 对于前台服务,需要严格执行以上流程。对于后台服务,在运维工作交给运维人员之后,原则上也需要执行以上流程,如果有特殊情况,请及时说明。

你可能感兴趣的:(主站后台开发规范)