斯皮格尔通过自身经历来展现了现实世界开发团队中存在的这个问题。当他还是一个新手时，其开发团队使用COBOL语言开发了一个库存管理应用程序，在需要提高该应用的性能时，团队中的两个阵营之间发生了争论。

斯皮格尔提出了他在之前一个项目中学到的一些性能优化技巧，并坚称团队应该回过头去修改数据库的所有字段，以提高应用程序的性能。

但是团队中资深开发者的话让斯皮格尔当场面红耳赤，“你不知道自己在说什么！你想为了减少CPU几毫秒的时间而浪费所有人的时间？你歇歇吧！”

这句话让斯皮格尔很受伤，至今还记忆犹新。他坚信这种修改是值得的，他的建议已经在上一个项目中得以证明，每节省1毫秒时间都有助于确保批量作业的按时完成，确保货物能够准时发出。

当时的斯皮格尔无法理解，同一种编程技术在一个环境中很容易被接受，而且效果不错，为什么换了一个环境就得到不相同的结果，丝毫没有被接受的希望。

答案是课本上学到的东西和有限的真实经历不能解答一切。当然，这主要因为问题的答案随着所处环境不同而不同。在一个理想的世界中，所有代码都将被xx编写，具有优异性能。它能在不超出预算、不超出工期的情况下满足所有需求。然而这个世界并不xx。

在现实世界中，所有“年长”开发者阅历丰富，问题的答案并不总是非此即彼。由于人员、预算和设备等资源的限制，你不得不作出艰难选择。因此你不得不学会折中之道。

这让大多数新开发者感到发疯，他们会说“不公平！我拒绝走近路来编写低质量代码！”而经验丰富的开发者则会说，“这种情况我们已经经历过一次。解决此问题没有创新的方法。”就算这样系统会更慢一些。但是只要客户能够接受，这算不了什么。

这并不意味着你牺牲全体人员的编码标准。许多年长开发者的代码就像意大利面条般难解，他们明白软件文档的清晰对维护的重要性。

编写符合标准的代码往往只需要花几分钟时间，但找出达到{zy}性能的合理方式却往往需要花数小时来试验。你不一定总是有这个时间。

这是否意味着团队经理应该采纳年长、经验更丰富开发者的观点，而无视年轻开发者的意见？当然不是！年轻开发者同样为开发团队带来很多有利的东西。

许多年轻人因为痴迷于技术，从十几岁就开始写程序。当他们从计算机科学专业毕业时，已经有许多年开发经验，在把握{zx1}技术趋势方面也有一定相关经验。

他们更容易接受新观点，不会被束缚于一个特定的设计或编程方式。年轻常常意味着灵活。

培训一个新手通常要比培训一个老手容易的多。假如你的团队新招入了一名年轻开发者，对其培训团队规范和流程时，不会遇到太大的习惯性阻力。

年轻开发者更勇于冒险，这对于发现能够影响格局的新概念来说非常重要。

相对来说，年长开发者一旦长时间使用一个技术，很容易形成思维定势，碰到每一种问题时都使用这种技术。

当然，许多年长开发者也在跟踪和学习{zx1}技术趋势，在51CTO.com之前的一篇报道《》中，不注意知识更新是阻碍成长的重要原因之一。另外，理解技术在业务上的应用需要一定时间。这是资深开发者的真正出众之处，尤其是对那些长时间从业于某个行业的开发者来说。

他们已经变成金融业和制造业等领域的专家，因此更容易凭借实际经验帮助用户制定一个可行的解决方案。

对于团队经理来说关键的是，需要单独评估每一个人的情况，不能简单根据年龄来划分他们。对新开发者和老开发者所固有的特性保持清醒的头脑。

你的工作就是引导这两部分人，帮助他们认识到自身缺点和对方优点，帮助他们进行自我完善。一个新老搭配的开发团队一般是{zj0}组合，不同年代的开发者可以相互取长补短。

如果你是一个拥有好主意的新开发者，要大胆分享自己的观点。但对于那些你未曾经历过的事情，一定要善于听取过来人的经验之谈。

对于拥有丰富经验的年长开发者来说，当你的年轻同事提出一些新想法时，不要立即嘲笑或威胁他们。他们可能会拓展你的视野。而且你可能实际会发现，这些新手也并非一无所知。

作者：Eric Spiegel

原文：Is Software Development a Young Person's Game?