A-A+

编译,通过,完成?

2018年09月29日 杂文 暂无评论 阅读 806 次

一个团队在经历从无到有的过程中,总是有那么一些令人头疼的问题时不时的蹦出来,骚扰一下团队的成员。比如下面这段熟悉的对话:

测试:小A,这个页面根本进不去啊,怎么回事?

开发:我看看一下啊,稍等。

......

开发:好了,更新了,再试试。

......

测试:小A,刚才那个问题好了,可是这个文本框为什么只能输入10个汉字,不是应该能输入20个的吗?

......

测试:小A,你为什么开发完,不测试一下啊,搞的我这里总中断,用例每天都跑不完。

开发:测试?测试不是你的事情吗?我是开发啊,再说有的问题开始也没说啊。

当然了,以上对话邪乎点,不过这种小范围冲突屡见不鲜,似乎说的都没错,似乎又说的都有问题。我先搞点鸡汤,然后再来讨论讨论实际问题。

鸡汤就是:着眼于大局,不要太在乎工作的边界,领导看在眼里,喜在心里,自然升职加薪。十年前我觉的这鸡汤真是滋润无比,现在我倒是觉的团队的担当还真是这帮脏活累活抢着干的人。当然了,欣赏不了这些人的所谓领导确实不少,不过树挪死,人挪活,有技术有能力有担当的人,换一家就是,也没必要一棵树上吊死。你要是不换还天天嘴上胡喷,这到底是谁的问题,也是仁者见仁智者见智了。

接下来,就该讨论讨论实际问题了,怎么样才能避免测试埋怨开发,开发心里憋屈呢?毕竟,这种小摩擦不断,万一冲突升级,磨刀霍霍,也是个不得了的事。就算不磨刀霍霍,天天打嘴炮,影响心情,自然就影响工作效率和工作积极性嘛。

其实上面的问题,我个人认为开发的问题多点,毕竟作为一名争强好胜的程序员来说,总被人挑刺还不带有改观的,尤其挑的还是这种仙人掌上面的刺,就有点实在过意不去了。所以我觉得可以先从开发这边来改进:

1. 在需求层面达成共识。一个和尚挑水喝,两个和尚抬水喝,三个和尚没水喝的故事耳熟能详,一个项目或者一个目标,如果涉及的人员死活不向一个方向努力,那这个项目或者目标的完成似乎遥遥无期。所以,在最开始确定需求的时候,一定要由团队负责人牵头,达成共识。比如,一个文本框输入字符的最大长度,开发人员理解这里能输入10个汉字,测试人员的理解是能够输入20个英文字符,这俩人最后不掐架才怪。

2. 踏踏实实的做做设计,多想点没坏处。噼里啪啦敲代码的时间过的是最快的,也是最美妙的,沉浸入工作的时候感觉真好。但是这噼里啪啦的一通猛敲,真的是最优解吗?低着头一通猛走,真的能够最快到达目的地吗?有时候停下来观察一下,抬起头来看看,不止能保持方向正确,很有可能看到沿途美丽的风景,更可能有意外的收获。所以在编码之前,多多思考一下,把问题想清楚,提前抛出问题。古人云:三思而后行嘛!

3. 职业素质。程序员的修行没有尽头,或者说人这一生总是处于学习之中。不攀比,但是不能活的无望·。我崇尚匠人精神,尽自己最大的能力去打磨架构,去完善每一个函数,去追求更好的更易读的实现。虽然也会妥协于现实,但是总要有一颗攀爬的心,在允许的范围内交出一份令自己满意的答卷。所谓无愧于本心,也就是这么回事了。不然素质堪忧,难当大任,搞着搞着也就得过且过了。切记的是:某些标签一旦贴上了,就很难再摘下来了。

4. 代码走查。任务都搞不完,还走查?不走也得走,没有自动化工具的时候,就得人走。有了自动化工具,也得结合人走。没时间的话,找领导协调,充分讲述代码走查的好处,比如:统一的代码风格,减少显而易见的逻辑问题,统计人员易出现的问题,增加代码可读性,增加团队协作,以老带新,降低未来维护成本,减少单点等等等等。代码走查这个事情,愿意干的人挺少的,因为读别人的代码确实很痛苦,不过这其实也是一种锻炼,增加见识,增长能力。

5. 个测。个测这个东西我觉的其实分为两大块,一个是编码完成的冒烟测试,一个是单元测试。很多开发人员为了工作而工作,想当然的写代码,想当然的抛给测试,结果就被啪啪打脸。自己写的代码,再烦躁也得运行起来看看成果吧,当程序员为了什么,不就为了那一行“Hello world”能够痛快的屏幕上显示吗?不就是为了看到从无到有的那种成就感?自己都不用用,对得起入行的初衷吗?单元测试这个东西吧,仁者见仁智者见智了,按理来说应该有,但是有界面的程序,一般情况下做了冒烟也就差不多了,如果时间不允许的话,放了也就放了吧,苛求也没意思。

6. 集成测试。开发经理的责任心,体现在两个地方,一个就是有没有完整的做好设计、详细讲解给下属并且做好走查验证工作,另外一个就是,有没有在各模块开发完成,交给测试之前,真正的去安排团队做一次集成测试。人和人说到底肯定不会一样,写出的代码再怎么规范,再怎么模式化,甚至于扣钱,都不可能达到完美的一致,那怎么能保证各模块能够顺理成章的完美融合呢?集成测试呗,先集成再测试,有时候集成就需要解决一大堆问题,跑起来测试又能解决一大堆问题。而且在解决问题的时候,需要协调各模块人员沟通,制定计划和方法,向着一个目标再次使劲,又增强了一次团队凝聚力,何乐而不为呢。

7. 追踪。不要交给测试就不闻不问了,合理的沟通交流,定时的追溯统计,都是为下一阶段工作开一个好头奠定基础。哪里总是三番五次的出现问题,哪个工程师总是犯这样那样的低级错误,BUG率是上升了还是下降,上升的原因是什么,下降的原因是什么。只有分析了问题,才能更好的解决问题,只有追踪了问题,才能在下一次避免再出现问题。不停的被坑不是问题,问题是每次都被同一个坑给坑了才是问题,被同一个坑给坑了还不知道那就是更大的问题了,是不是很绕,没关系,追踪总结就不会这么绕了。

说了一大堆,其实很简单:工作上用点心什么都解决了。开发说了一大堆,今天就到此为止,下回再分解测试的。话说,公司聚餐喝酒大法好,让我一晚上能喷出这么多干货来,哈哈哈哈哈。

给我留言

Copyright © 字痕随行 保留所有权利.   Theme  Ality 京ICP备14039894号

用户登录

分享到: