中午饭点的时候，在园区食堂吃完饭准备回办公室休息的路上，听到路旁经过一位程序员说道 “程序员最不想去的地方就是现场了”，顿时觉得这句话好熟悉，在心底引起了一丝共鸣。看来程序员对于出差这种任务还是具有普遍的抵触情绪的。这一丝共鸣又使我想起了工作这几年所经历的出差以及其中的酸甜和苦辣。

作为数据处理（数据库及数据同步）行业的从业人员，我所从事的工作扮演了DBA、技术支持、产品测试、产品开发等各种不同的角色。所在公司重点推广应用的产品是数据库及数据处理相关工具类软件。数据库及其相关数据处理类工具软件，属于基础系统和应用性软件产品，追求高效、稳定、可靠、易维护、易用性等主要技术指标。其版本的迭代速度比较缓慢，甚至比不上目前市场上各种新品手机的型号推出速度。数据库作为基础性系统软件，其版本的迭代升级所需时间更长，通常以年为时间单位。由于行业特点所在，因此我们这一类技术员的主要工作有两个方面，一是维护优化现有的各种版本产品，包括性能优化，功能完善、缺陷修复、功能强化等方面；另一方面就是进行前沿技术预研、高级功能攻坚、新功能新版本产品测试等迭代升级工作。

基础性的功能性软件产品，用户首要追求的就是高效稳定，首要考虑的就是以目前的解决方案，解决目前的业务问题，并具备一定扩展要求，满足业务不断增长的需要。特别是在产品已高效稳定运行若干年后，“升级”这个词语，用户将会有一丝抗拒。因此多半情况下，升级一般是由产品供应商申请，而不是用户主动要求，除非当前产品版本在经过各种补丁以及各种绕坑策略处理后依然不能满足业务要求。这种产品应用的特点，决定了我们开发架构和功能的设计一定是有长远考虑的，开发的功能是具有长久生命力的。不同于当前互联网产品的应用特点，迎合海量用户的需求，需要高效的去获取流量用户，扩大影响力。版本升级由市场竞争驱动，追求高效快速，追求独特创新，接受着流量的考核。其新功能的生命周期如果没有流量的驱动，一般都比较短。产品的高效稳定决定了出差的性质，要么不出差，出差就是大问题！

行业另外一个特点就是，应用场景万万千。通用的产品需要去适应这万万千的场景，而不能针对每种场景进行个性化的定制。场景的繁多，就需要对产品进行完备的测试。从测试投入以及资源来说，行业巨头尚不能满足各种测试场景需要，何况中等规模，一般规模的企业。以ORACLE数据库测试为例，从相关资料报到看，测试服务器就达到成千上万台，测试用例数据庞大，光运行测试就需要耗费大量时间。一般规模的企业，很难达到这种测试效果。这种情况就导致，在产品大量应用时，不可避免的会遇到不能预期的错误，重要的是，这种错误，企业内部的测试环境没有条件复现。那就回归到了本文的正题，出差。企业内部不能复现，你还怎么gdb？

出差对于我们这边的开发人员一点都不陌生，因为我们身边有很多技术服务支持。在很多人眼里，出差是技术服务支持的工作，是DBA运维管理的工作。但是就像上面说道的，如果是产品本身的问题，技术支持也是无能为力的，需要开发进行产品调试。企业内部没有环境，当然得去用户现场了。用户现场具有宝贵的场景资源，宝贵的数据资源，以及留给你的各种挑战！

出差的挑战不仅仅是技术上的，还包括生活上的。出差的第一任务就是奔波，在你接收到任务的第一刻起，你得预订现场的车票，酒店；然后一路奔波到目的地，接受异地不能适应的睡眠环境和饮食习惯，接受来自产品调试的日夜煎熬，有可能还会受到老婆电话里的抱怨“什么时候回啊，还不回？“ 在现场调试产品，还需要适应用户的期待以及挑剔。产品遇到问题，首先感到着急的肯定是用户，因此当你到达现场后，用户可能会对你进行非技术性的抱怨以及苛责。当然，作为技术人员，承受苛责哪怕谩骂也许也是一项生存必备技能，毕竟你需要对产品的质量负责。所以，到达用户现场的第一要务，不是打开笔记本，连上服务器，而是深吸几口气，平复心情，然后和用户沟通，做好安抚。

承受苛责的时候，需要换个角度看待问题。产品不稳定，用户提供了稀缺的场景资源，是对产品质量提升的一次宝贵机会。毕竟，有时候，获取一个测试机会都需要付出很多，哪怕就是试一试呢？现场的开发，除了非技术性的素质外，也能看到产品内部更加深刻的问题，解决别人没有看到的问题，是对开发人员能力的一次提升，也是对开发能力的肯定，就是展现开发价值的时刻。

经历过出差的开发就像凤凰涅槃一样，得到新的重生！虽然，有可能造成夫妻关系也进行一次重生(*￣︶￣)！