debug--仔细观察合理猜想调试Flex进度条问题

在调试部门建议的附件下载功能时，发现进度条永远呈现的是0%。而此项目的这块功能属于后期维护时客户新添加的功能，原项目开发人员已经不在现有项目团队中了。经过跟踪发现项目多处附件下载是调用的同一处Flex下载组件，而唯有这个部门建议功能的附件下载是有问题的。

 

对项目进行功能性测试中发现上述问题，效果见下图：

由于项目所用的下载组件是同一个，而其他的下载过程很正常，故而该问题应该出现在三个地方：附件大小的存储问题、附件大小的获取问题、附件下载逻辑处理问题。而第一个问题最好查找，只需要在DB中找到相应字段即可确定。见下图：

上图表明，附件下载的问题就是附件大小的存储出现了问题。剩下的就是查找该问题了，即附件的上传过程，首先了解下这块功能的结构。

 

在此项目，做为项目的后期环境支持、后期测试和维护工作的角色，对这项目的逻辑实现并不是很清晰。针对Flex的表单构成特点，可以首先定位到问题功能所在的mxml位置，而后debug。

 

解析此块内容的构成见下面类和图所示内容：

DeptAdviceMain.mxml   

DeptPublishCanvas --发布

DeptViewCanvas.mxml   --查看

 

 

之后，Flex端debug过程出现了久违的问题——eclipse不能进行debug。没有立刻针对该问题进行解决，原因很简单bug本身不难，而项目在当天要上线，所剩时间不多。但无论是进行debug跟踪，还是浏览代码，都可以发现以下对应关系，即，上图中部门建议中的“查看”和第一幅图中的信息详情是多对一的关系，而信息详情和信息详情中的附件是一对多的关系，有了这个数据结构便清楚了java端数据的组织形式及其在Flex端的绑定方式，简单示意如下所示：

详情：

vo.attatchments

vo:DeptAdviceVO = AppModelLocator.getInstance().deptAdviceModel.currentDeptVo;

列表：

dataProvider：model.deptAdviceModel.deptVoList

 

经过上述结构及Cairngorm框架的特点即使不进行debug也能很快定位到问题的大体位置，进过验证，问题出现在Flex 中String类型对Number类型的转换过程。转化简析如下所示：

 

1, Number(numberString) 

如果numberString是非Number类型，会进行强制转换，换个说法去构造一个Number对象更为贴切。如果转换过程中出错，会出Error。(注：Number转换失败不会出错，会返回NaN，其他类型可能会抛出异常)。

这种转换方式有一点要注意，比如Array("a"),按常理来说里面的参数"a"是String类型，不是Array类型，应该转换失败，但他会返回一个数据，里面下标0存在字符串a，["a"]。

 

2,num = str as Number

利用as转换，必须as之前的类型跟之后的类型是同一类型(或有继承关系)，否则一律返回null，但不会引发异常

 

采用上述解析1中的方法进行转化问题得以解决：

 

此bug并不复杂，只是开发人员范的一个低级错误，但是这个debug过程却告诉了我在bug的出现是带有关联性的，解决bug如果有猜想阶段的话，一定要考虑bug出现的周边情景，例如该题，下载附件有问题，其真正缘由是上传附件的问题。此外有时猜想问题比一点点debug还好快，尤其是在不能进行debug时。