4月17日到22日,为了试验我们的语音拣货项目,我去郑州仓库出差5天。 从结果来看,这次出差虽然没有预期顺利,但最终还是完成了预期要达到的目标:得到了当地同事的支持;找到固定人选长期使用语音方式拣货;收集和及时处理问题。回想这次出差经历,把一些心得记录下来。 出差决策:我通过争取进入了这次出差的名单,事实证明我这一行动非常正确。我们的语音拣货项目由业务逻辑和语音引擎组成,在办公室编程、实验期间,语音引擎的表现一直相当优秀,因此大家都很乐观,老大也只打算安排业务逻辑的需求分析人员与开发人员两个人过去。但作为语音引擎开发的负责任,我认为我不能不去,现场和办公室噪音背景不一样,工人口音和对语音引擎接受程度不一样,于是我就去争取。后来到了现场,语音引擎的表现真的比在办公室时差很多。 现场调试:抵达仓库的第一天,我们的需求分析人员就给分公司领导和员工培训和讲解我们的项目,但尴尬的是,语音引擎不能识别我们说的话,于是我们从多个方面查错和改进:增加灵活的用户配置方式,方便我们修改语音引擎的各项参数;调低辨认门槛;调节语音合成语速;优化流程。拿改进配置方式这一点来说,我们在上海时,出于对语音引擎的信心,按照我们实验得出的经验值将一些参数写死了,例如,一个识别结果如果评分超过60分,我们认为是可信的,然而,在现场看到的大多数评分都是四、五十分,于是我们需要更改这个参数,但我们如果重新在代码里把“60”换成另外一个固定值,如果实验结果仍然不好,又得重新发布、部署一次,于是,我们在主程序页面上增加了这个参数的配置接口,以便随时在运行时修改这一参数。经过几天努力,工人总算是可以使用语音拣货功能了。 版本控制:上述改动由于都是在现场临时改代码,我们只能采用人肉版本控制的方式:尽量只由我来做语音引擎,另外一位同事做业务逻辑,但有时我也需要改业务逻辑层,只能先用U盘把他的代码拷过来,我改好了再拷给他,用这种最原始的方式来维持版本的正确性。另外,上海office的同事也会帮我们debug一些疑难的问题,好了之后把代码mail给我们。可以说,这种原始的方式限制了我们的开发效率,也极容易出错,我们在现场碰到过几次版本出错的情况。如果在现场也能像在办公室一样使用ClearCase/Git就方便多了。也许可以通过在github上建立Private repository的方式来实现这种跨地区的版本控制,不过不是免费的。 代码修改:虽然囿于人肉版本控制,但为了保证代码质量,我们两个开发人员尽量做到:少做改动;用unit test覆盖原有功能;互相review变动的代码。在现场时,我们多数时间一起行动,要么一起编程,要么一起验证,使得每一次改动两个人都心里有数。另外,代码经过unit test覆盖之后,改起来确实底气很充分,我只要保证unit test覆盖了所有可能情况就能够放心改代码了。出差的人往往为了赶时间而直接写代码改代码,但我认为完备的unit test是值得的,可以大大减少以至消除因为赶工造成的错误,磨刀不误砍柴工。 现场协调:虽然我们是技术人员,但在现场我们当然要和方方面面的人进行协调。幸运的是,郑州的同事,特别是仓库经理和操作主管都是对新知识新事物抱有极大热情的人,他们对我们的试验提供了全力的支持,操作主管本人更是连续三天作为最终用户直接试用我们的项目,认真地帮我们做测试并提出真知灼见,他的意见无不是切中要害的,对我们的持续改进很有帮助。 最后附送一张在现场偶得的照片~