参数校验框架使用说明

简介

在web项目和service项目中,有许多校验参数并返回结果的代码,比如:

屏幕快照 2018-01-16 下午5.27.49

这种校验代码比较冗长,费时费力且影响代码可读性。为此,提供一套参数校验框架,通过注解进行参数校验。

目前处于内测阶段,所处项目及分支:

thor:validate分支

avatar:validate分支

配置方式

spring配置文件中配置AOP:
<aop:aspectj-autoproxy proxy-target-class="true"/>

<bean id="validateAspect" class="com.aixuexi.thor.validate.aspect.ValidationAspect"/>

<aop:config>
    <aop:aspect ref="validateAspect">
        <aop:around method="around" pointcut="execution(* com.aixuexi..*.*(..))"/>
    </aop:aspect>
</aop:config>
注意:web项目只能在springmvc的配置文件中配置。

使用方式

一、校验model域

1、在形参上加 @Validate 注解,表示该参数需要校验。groups参数表示校验组。
@RequestMapping(value = "/not_null", method = RequestMethod.GET)
@ResponseBody
public ResultData test(@Validate(groups = Group.WEB) PageParam pageParam) {
    return new ResultData("invoke success!");
}
2、在model域上添加校验注解,groups的值与@Validate注解groups的值有交集时才触发校验。
public class PageParam implements Serializable {

    @NotNull(groups = {Group.WEB}, successMessage = "ABC validate success")
    private Integer pageNum;
}

 二、校验形参

在形参上加校验注解,表示该参数需要校验。
@RequestMapping(value = "/not_null", method = RequestMethod.GET)
@ResponseBody
public ResultData test(@NotNull(errorMessage = "str1不能为null!") String str) {
    return new ResultData("invoke success!");
}

注解说明

注解
支持类型
说明
@Validate
Object
表示方法形参需要校验;
表示POJO对象需要校验;
表示Collection中的对象需要校验;
@Null
Object
必须为null
@NotNull
Object
不能为null
@Assert
Boolean
是否为true或false
@Range
Number
数字是否在区间内
@NotBlank
String
字符串不为空串
@Pattern
String
字符串是否匹配正则表达式
@ValidStr
String
字符串是否合法(仅含数字、英文、汉字、下划线)
@Length
String
字符串长度是否在区间内
@Telephone
String
字符串是否为手机号格式
@Email
String
字符串是否为email格式
@NotEmpty
Collection
集合是否为空
@Furture
Date
日期是否为未来时间
@Past
Date
日期是否为过去时间

目录机构

 参数校验框架目录结构

 

关于项目中.gitignore文件中*.properties一行的思考

在做项目重构过程中发现许多项目为了把dev下的配置文件忽略(因为本地配置经常改动),在.gitignore文件中加入“*.properties”来解决。

这样做固然固然很简单方便,但在思考一下,把所有的properties文件一棒子打死了(尤其是我们的gerrit还不能在线预览文件)。其实有这样一种场景,当其它环境的properties文件中有更新,你(也可能是你的队友)写完后本地测试没问题,然后commit 上去,发现非本地环境就是没有跑通,也许你会很快意识到.gitignore文件的问题,但当你本次提交有很多改动混合在一起的时候,你会首先怀疑自己的代码有问题,然后排查了半天,还是不知所以然。。。然后半天过去了。。。发现自己被很弱智的问题坑了。。。是的这是个很忧伤的故事,蛋蛋的忧伤

所以这个.gitignore文件加东西要慎重,太随意的话,在你忘记了你忽略了什么的时候,它就拐回来坑你,还有你的队友

回到我们的问题场景,我们只是为了忽略dev/下的配置文件,打死的范围不要多也不要少,来吧1,2,3走起
1.在”.gitignore”文件中加入”src/**/dev/”
2.清除git版本对要忽略文件的已有追踪
“`
git rm -r –cached src/**/dev/
“`

这时候执行git status查看发现,dev/下的文件被删除了,像下边这样

图片1

看到这个不必困扰,其实这里只是删除了git版本库中对这些文件的记录(看一下dev目录的这些文件,他们还在)。
3.别忘了最后一步add and commit
“`
git add .
git commit -m ‘fix ignore that only ignore dev/*’
git push origin head:refs/for/master
“`

在gerrit中+2并入分支

 

好了,解决,其它忽略类似

icode 快速入门教程

简介

icode是基于gerrit的二次开发,底层的服务由gerrit提供,icode旨在解决使用gerrit过程中的痛点,优化整个开发流程,打通整体流程,包括:代码托管、持续集成、自动化运维,前端部分使用react + mobx + antd搭建,服务端使用python作为连接gerrit与前端的桥梁。

登录

icode使用gerrit账号进行登录,目前还没有开通注册功能,所以新同事可以找运维人员开通gerrit账号来使用icode。

WechatIMG48

创建代码库

点击创建代码库的按钮会出现创建代码库的弹窗,在输入框中输入需要的信息就可以直接创建对应的代码库。WechatIMG50

分支管理

点击进入项目之后便可看到项目完整的分支信息,包括:分知名、备注、创建时间、分支状态、领先落后数量等。

WechatIMG51

新建分支

点击新建分支,会出现弹窗,在输入框中填写具体的信息就可以创建新的分支,分支名默认自动生成,且不允许修改格式。

WechatIMG52

克隆代码库&切换分支

申请分支之后,我们可以先把代码库克隆到本地。

WechatIMG53

ps:想要执行这段命令需要先把ssh-key添加到gerrit账号中。

地址:http://gerrit.dev.aixuexi.com/#/settings/ssh-keys

克隆到本地之后,我们需要切换到我们新生请的分支。

使用:git checkout –track origin/[你的分支] 指令来切换到对应的远程分支,并建立本地分支与其关联。

提交代码

icode为每次提交都添加的评审,且校验了change-id,所以我们提交评审的时候需要使用hook生成并携带change-id,建议添加gpush别名来简化提交。

bash -s << '_EOF_'
git config --global alias.gpush '!f() { : push ; r=$1; [[ -z $r ]] && r=origin; b=$2; t=$(awk "{ print \$2 }" $(git rev-parse --git-dir)/HEAD); t=${t#refs/heads/}; [[ -z $b ]] && b=$t; cmd="git push $r HEAD:refs/for/$b%topic=$t"; echo $cmd; echo; $cmd; }; f'
_EOF_

代码评审

提交评审之后,在icode上实时的看到评审列表,点击评审主题就可以跳转到评审页面。

WechatIMG54

在线预览

点击文件菜单可以在线预览代码库结构以及文件内容。

WechatIMG55

提交历史

点击提交历史,可以查看每一次的提交记录,并且可以查看提交内容的diff记录。

WechatIMG56

WechatIMG57

收藏代码

WechatIMG49

持续集成

点击持续集成菜单,会弹出新的页面进入持续集成平台,在持续集成平台中,我们提供了编译、送测、发布、合并回主干的功能。

  • 编译:点击编译按钮可以编译当前分支的代码,产出服务器上需要的压缩包。
  • 送测:点击送测按钮,可以选择对应的QA,系统会自动发送邮件来提醒对应的QA人员本次提测的代码库地址和分支号。
  • 发布:测试通过之后,点击发布会把压缩包发布到产品库中等待上线操作。
  • 合并回主干:当上线结束之后,点击合并回主干,分支代码会自动合并回master分支,并且删除当前分支,分支的生命周期走到尽头。

WechatIMG58 WechatIMG59 WechatIMG60 WechatIMG62 WechatIMG63

阿里代码规范插件-来自阿里的神秘力量

hello 大家好~

作为程序猿,深知代码规范的重要性,其好处就不用说了,易读,易维护,代码跑起来也有效率、爽快。

不管是使用什么IDE,其自身都会集成一些规范检查,不过基本都是纯英文的,我相信大多人都不怎么会去看的,说句打脸的话,我也不怎么看,,手动捂脸。。

最近阿里的大神们推出了一款代码规范检查插件,试用了下,效果不错,今个做一简单推荐介绍。

GITHUB:https://github.com/alibaba/p3c

官方说明:https://mp.weixin.qq.com/s/IbibsXlWHlM59kfXJqRvZA#rd

首先,怎么安装,so easy~

打开我们的Idea ,选择 File – Settings – Plugins – Browse repositories

然后搜索 Alibaba

安装

搜索出来的第一个插件就是,然后在右边红框会有安装按钮,我这个已经是装过了,装完以后重启Idea即可。

然后,怎么使用嘞。

使用1

可以在类、包以及整个项目上使用,点击右键,就会看到红框位置有一个编码规约扫描,是它是它就是它,大胆的点击它,然后就是见证奇迹的时刻。

使用3 使用2

我这个是跑了整个项目,它的检查结果分为三个级别:简单理解就是崩溃>严重>重要,咱们优先处理等级高的问题,比如下面这个

使用3

点进来以后详细的代码位置都有,然后有没有注意到上边有个神奇的按钮,为代码添加大括号!别犹豫,点它!瞬间当前类下所有没加大括号的全有了有没有,神不神奇,厉不厉害

使用4

这简直就是真·良心功能啊。

另外,它还有一个实时检查的功能,代码有波浪线的时候,鼠标放上去,就会有提示了。

这款强大的插件还有更多神奇的功能,我也刚刚开始使用,还需要大家一起去发现,去研究,插件终究只是辅助

心中有规范、处处成规范

什么时候我们写出的代码,任何主流规范检查都检查不出大问题,岂不是一大快事~

少年,还等什么,快试试吧!

财务系统-axxBank和marginCall项目上线小总结

财务对账一期,在各方势力催促下,匆匆忙忙上线了,上线之后,第一天cat监控显示有4个接口超过了300ms,最高请求能达到1秒多,爆炸!

微信截图_20170930155822
接下来,查找原因,4个接口4条业务线逐一排查,首先走Debug先从sql入手,对于新增的表 没有及时建立索引的,增加索引保证sql最优化,接下来走单元测试打印运行时间,看代码块响应时间,优化代码 !
这次调优印象最深的有两点:

1、有个业务方法,在for循环中加了sql查询,这个错误太明显,

微信图片_20170930155009
二话不说修复代码将所需3张表的数据一次性加载到内存中,在内存中进行各项封装,时间从180ms优化到6ms,鼓掌!~\(≧▽≦)/~
2、另一个错误是在频繁使用一个三级分类查询中,使用了google guava缓存,有一个方法未写正确,导致每次都重新查询加载到缓存中,怎么避免这种失误很简单,debug断点看是否第一次加载进去,第二次从缓存中直接取到,还是不能太相信自己,直接测试功能就认为没问题
经过一些修改之后,使用勇勇的gatling压测,4个接口平均响应时间已经低于40ms

本次小总结:

1、sql优化,养成每个sql在写代码阶段就自己进行性能调优监控的习惯
2、单元测试,不能只是简单的测试功能是否正常,打印出响应时间,好坏立刻见效
3、上述两条只是基本的编程习惯,有了上述两个之后,适当地使用缓存,上线之前进行压测,都是避免不必要问题的措施啦~

江湖路远,下期再见~

微信图片_20170930155456

有赞读后感

一个成熟的运维团队,流程化、平台化是必不可少的。需要根据相应的流程去准备相应的平台,才能让一个团队的工作效率大大的提升。

对于运维来说,我们更多关注的是线上服务器的运行状态,线上服务的运行状态,发布上线的快速化、简单化,能够更高效率的解决开发或者测试在环境问题中遇到的瓶颈。

对于现在的我们需要做的,监控的完善,自动化平台的完善,虚拟化(docker)的完善,自动化平台对接监控+虚拟化。

现在的我们,流程化的东西正在逐渐的完善,平台化的东西我们也已经开始在做,尤其是我们第一版的自动化发布平台已经正式上线,这也就意味着我们已经成功了一多半,我们离一个成熟的团队也越来越近。

<有赞测试读后感>

看完有赞测试团队的介绍,从中获取了很多启发。
一.首先就是项目测试,分为三类:
1.标注需求项目或者跨多个业务项目
2.技术重构项目
3.小型项目
我们瑞恩3期就属于重构项目,所以测试可以借鉴他们的经验,设计测试方案并完成测试用例落地即可,用例有开发完成,测试需要自动化覆盖。
二.还有一点新颖的地方就在于,有赞测试他们关注了线上服务的性能和稳定性,通过他们自己开发的工具监控线上服务的健康性,以及及时的告警。
三.开发分支管理,有赞大巴的管理模式,由测试来管理分支。
四.各种工具的建设,极大提升了测试团队的效率。

有赞测试文章读后感

有赞的发布系统为公交车发布系统,我们的发布系统为极品飞车发布系统将来肯定会比他们的牛逼。目前我们的极品飞车系统还在起步阶段,分支发布还在开发过程当中,但整个发布系统功能跟有赞类似,我们的平台将来还要与docker平台,监控系统对接,这是有赞公交车系统所没有的;感觉他们的分支发布好像不是自动编译的,现在我们运维平台实现了自动编译功能,发布项目挺快的;他们的发布流程很长,也不知道他们发布一个项目需要多长时间。

值得借鉴的是他们的整个发布过程已经跟测试打通,整个发布流程相当于是一条龙服务,全程自动化,平台界面展示效果较好。我们的平台现在还没有达到这种地步,但是肯定会的,很看好我们的平台!

有高度,有深度——有赞测试团队介绍读后感

附链接:有赞测试团队介绍

一、有高度:有赞的测试团队基于“提高产品质量”的立场,参与到产品研发流程各个环节:技术评审后的测试方案制定和评审、测试用例编写驱动开发、codeReview、集成测试、多环境测试,并且积累了一系列高效的工具:QA平台、mock服务、安全扫描工具、性能测试平台、持续集成平台、基于测试历史数据分析的工作台。

二、有深度:深入到跟质量相关的各个层面:RPC接口、http接口、线上服务监控等。

他们的测试团队打破了我对测试团队固有的看法:界面点一点、顶多用工具做一下接口测试和压测,他们能基于自己的使命主动出击,做了很多严格意义上讲并不属于测试职能的工作:codeReview、服务监控等,但这些也确实与产品质量和服务质量息息相关。

还有一点,他们的自研能力很强,能基于测试需求开发自己的工具,达到了可持续测试,并且基于测试数据做产品的宏观质量分析。

最大的感触,测试团队也大有可为!