关闭

项目开发代码规范

标签: 代码规范Android
721人阅读 评论(0) 收藏 举报
分类:

1. 开发流程

  1. 调研、评审、立项,最终形成调研文档和设计文档;
  2. 在产品develop分支上拉取新的feature分支,进行项目/功能开发;
  3. 项目开发完成后,需要做相关的测试,需要包含单元测试、流程测试、功能测试、质量测试、性能测试等;
  4. 再从develop拉取release分支,将feature分支merge到release分支,并进行提测;
  5. 测试通过后,提请上线申请,上线release分支;
  6. 上线申请被批准后,将release分支的代码上线,向运维组发送上线邮件;
  7. 配合运维组上线产品,及时回测,并在上线初期经常监控产品线上状态,应对突发情况;
  8. 上线完成后,将release分支merge到master分支和develop分支,并在master分支打tag;

2. 编码规范

主要使用Java语言来进行开发,严格遵循Sun公司的Java编码规范。此外还有以下补充。

大小写常量的字母全部大写,单词之间用一个下划线字符(_)进行分隔。除常量外的命名采用大小写混合,提高名字的可读性。一般采用小写字母,但是类和接口的名字的首字母,以及任何中间单词的首字母应该大写。

编码格式

  1. 确保IDE工作环境使用UTF-8编码格式。
  2. 缩进一律使用空格而非Tab。
  3. 缩进一律采用4空格。可以设置IDE 1Tab=4空格。
  4. 对于非第一次创建的代码文件,禁止做reformate操作,这个操作会破坏代码的修改历史,造成大概率的push、merge、pull等操作冲突。

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

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

命名规则

  1. package: 1.1 package: 每一个包的名称总是小写,暂定将com.keegoo.+(模块名)作为总前缀,比如com.keegoo.demo.blog.service、com.keegoo.demo.blog.dto; 1.2 明确不同业务建议建立子package,比如有关User业务的:com.keegoo.user.account.service、com.keegoo.user.account.dto;
  1. class类:类名必须是名词,且以大写字母开头。类名应该简单清晰。

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

  3. 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”属性的取值会有一个固定的范围,包括但不限于以下几种:IOExceptionConnectionRefused

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

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:3692次
    • 积分:118
    • 等级:
    • 排名:千里之外
    • 原创:3篇
    • 转载:3篇
    • 译文:0篇
    • 评论:0条
    文章分类
    文章存档