那具体问题是什么呢?
他们司app的一个新版本的开发,新版本中原来h5页面改造成了native页面,需要在h5页面的入口上做版本判断,在新版上需要跳到native页面,否则还是跳转到h5页面。
新版本:10.1.0, 该版本中h5页面改造成了native页面。
伪代码如下
var version = getAppVerion()
var verArr=version.split('.')
if(verArr[0]>10 || (verArr[0]>=10 && verApp[1]>=1)){
//新版本会跳转到native页面
goNativePage('aaaPage')
}
上面的逻辑没啥问题吧,但就是在自测的时候为了看下在低版本中是否正确,结果在后面忘记了把判断改回来。
if(verArr[0]>10 || (verArr[0]>=10 && verApp[1]>=0)){
//测试低版本...
}
虽然就是一个数字的差别,但是这影响还是很大的,直接导致测试流程走不下去了。
如果是你遇到了这个问题会采取怎样的方案,来避免这样问题呢?
像这种特殊改动,将他记录下来,后面一定要想着改过来。
这种方法可能只对发生过这样问题的人才有用,没经历过的话很难有这个感触,而且后面还会有新人进来,他们也完全不了解这个方案的背景是什么,所以说这不算什么好方法,后面难免还会出现类似的问题。
即便不出现这样的问题,还会出现版本判断有误的问题。
把版本判断的逻辑封装成一个通用的方法,避免多处重复写逻辑判断。
export function compareVersion(curver,targetver){
//比较逻辑
}
这种方式确实可以减少出错的几率,但是你封装好了,还要通知大家都去用这个方法,大家还要记着有这个方法,有这个意识还好,但是新人呢?新人可能不知道有这个方法,还是会自己写逻辑,所以还是有可能出错。
前面两种方案h5项目采用一套代码,不分版本
其实要想彻底避免这个问题,那就是不做版本判断,从规范和流程上来解决,也就是h5也分版本,跟app的版本走。
大概的说下实现思路:
app端内置一个版本配置文件,里面有h5页面地址配置
{
h5Url:'https://xxx.com/v10.1.0'
}
然后定一个h5项目分支规范,上线分支必须按照这样的规范来定义
masterV10.1.0
masterV10.0.0
masterV9.0.0
最后h5项目在构建的时候会根据当前的分支名,获取到版本信息V10.1.0
,然后在服务器创建该名称的文件夹,将所有内容打包到该文件夹内。
这样,h5项目也就彻底分了版本,再也不需要在代码中做版本判断了,然后落地成规范,形成文档,可以方便新人查看。
可能你觉得这样还不完美,比如重复资源、多版本如何维护等,当然在我看来这都不是什么问题,和这个隐患比起来那都可以忽略了。