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

测试：小A，这个页面根本进不去啊，怎么回事？

开发：我看看一下啊，稍等。

......

开发：好了，更新了，再试试。

......

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

......

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

开发：测试？测试不是你的事情吗？我是开发啊，再说有的问题开始也没说啊。

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

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

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

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

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

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

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

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

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

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

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

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