处理我陈旧的同事

我是一个相当年轻的程序员，我在一家中型公司的IT部门工作。我有一个同事，他是一个非常好的Visual Basic 6程序员。我的意思是非常好。老实说 在我需要喝第一杯咖啡并启动机器时，他可以交付工作中的应用程序，其中包含的错误很少。他就是那么好。

事实是，我们正在与一个团队合作，他的工作风格完全过时。他不相信版本控制软件（如果您只是确保代码正确，就不需要所有的废话）。不相信部署（我可以交付一个可运行的可执行文件。如何部署该文件供系统管理员了解）。不相信抽象。（''如果您想创建一个子例程，请继续，但是不要从该子例程中调用任何子例程。这样会造成混乱，并且代码也很难遵循。这样，每个人都可以遵循该过程中的每个步骤。 ”或“是的，请确保您可以使用该库为您完成此操作，但是那样您就不会真正了解正在发生的事情”），当然也不相信OOP。（我们在VB.net中工作）

他的工作非常出色，可以比我更快地交付应用程序。但这在团队中是行不通的。我们的其他团队成员很安静，尽管他倾向于同意，但他不喜欢大声说出来。我们的经理认为我是有根据的，但不是程序员。

我很难维护他编写的程序，但这并不能营造良好的团队氛围。您认为对我来说最好的事情是什么？

这听起来像是“他是个好人，但是...”中的一个，您知道真相即将到来。事实听起来好像他并不是一个真正的工程师。好的软件不仅仅是工作和开发速度。它还涉及您提到的其他内容-可维护性，兼容性，抽象（以提高未来效率）等。

话虽这么说，听起来您手上有问题开发人员。对您来说，更糟的是他已经被证明并且可能会按照自己的方式进行训练。所以，你可以做什么？

• 在他周围工作。
• 努力按照他的时间表安排您的项目。
• 如果您做不到，则可以得到更好的结果。
• 随着时间的流逝，那些被他拒绝的可靠概念将开始为您带来回报。

另一方面，如果您被迫按自己的方式行事，请离开。

不要试图改变你的同事。您将他描述为能够交付工作软件的人。将它集成到团队中可能为时已晚。

因此，您有两种选择：

• 适应自己。也许随着时间的流逝，您将能够使他相信源代码控制系统的实用性？您将不得不增加影响力。他对变化的抵抗力越强，您将需要更多的时间。

• 删除自己从team。您有很多观点可以证明这一点。也许您应该保留它自己的应用程序，并专注于新事物。

• 删除自己从company。有时，这是唯一的解决方案。

如果您是我，我现在将建立自己的源代码控制系统。开始将其用于您编写的所有代码，并对其进行管理，以便您的其他团队成员拥有帐户并可以访问它。您的其他同事可能会对使用它充满热情。

不相信这种做法的同事可能很难说服。但是，您被迫使用的任何由他编写的代码都应进入版本控制，以便您可以使用它。当他需要访问您的更改时，请向他发送有关如何从存储库中提取代码的一组简单的逐步说明。

您不必太好斗或超越他就可以让他参与更现代的过程。有时候，仅仅按照自己的方式行事并成为行动的领导者比尝试用语言说服某人更有效。宝贝的步骤。如果他开始对版本控制更加敏感，请开始重构子例程并添加单元测试以防止更改。使测试自动化，并向他展示如何在他签入后立即获得结果。

很多时候人们只是因为他们不喜欢改变而抵抗。但是，如果将这些更改以渐进的方式呈现给他们，并且使他们易于遵循，那么他们通常会很快看到收益。

最重要的是，让一切对他来说都尽可能简单（保持简单愚蠢）。让他按照自己的条件开始遵循这些做法。但是不要让它拖下去。

老实说，你没有给他画好照片。古老的方法，难以维护的软件，对新的工作方式顽固，反对抽象等

用你的话说，如果他比没有使用可重用的库和旨在快速进行应用程序开发的设计模式来更快地开发出没有错误的软件，那么与他相比，它更能说明你自己。

..关于他..是的，找到一种不与他一起工作并且不与他的工作联系在一起的方法。似乎他对工作有一种典型的自私态度。您不能与这样的人一起工作，只能观察他们的工作并整理他们（就像您目前一样）。

我以前看过，

而且我几乎愿意打赌：这种类型的人只会显得 “快”，因为他的脑袋里有一套经过实践检验的“模式”。业务范围应用程序的99％是CRUD，是基本内容。

他可能会从自己现有的代码中使用大量“复制和粘贴”（这没错）。

但..

当他遇到任何遥不可及的复杂事物时，它就会掉下来，为什么？因为它不再适合任何基本的“模式”。

有点挑战...

我会在侧面创建一个项目，这个复杂的项目确实可以从OOP和代码重用中受益。

然后向他展示该项目，并要求他为功能实现该功能。

然后，我敢打赌，如果他按照自己的方式实现它，那么他的代码几乎肯定会比原来大10倍，比原来大10倍。

从业务方面来看。

您需要花费更多时间来生成错误代码。您产生的收入较少，因此很烂。

如果随着时间的流逝您可以将其撤消，则可以将其撤消。

但是，也许，也许，这个过时的程序员实际上可以教给您一些有关快速生成代码的知识，这些代码是如此的没有错误？也许他的技术并不像您想象的那么古老？

我怀疑有人可以在没有很好的实践的情况下生成如此出色的代码。您也许可以学习这些实践，并将其应用于“最佳实践”和您了解的新潮事物。

如果您的经理不是程序员，请尝试使用他会理解的术语。

• 我们应该使用sourecontrol，因为如果不这样做，恢复时可能会遇到很大的问题

• 我花了x倍的时间，因为他拒绝遵循一些相当基本的程序。

另一方面，请确保您不会太过完美，即这是我们必须遵循的最佳做法。您的同事可能有很多补充，您可能只需要缓慢地朝正确的方向轻推他即可。

好像您的同事从未在团队中发展过。那种独奏大师的伙伴不允许良好的团队互动。因此，请告诉您的上司，并尝试与喜欢这样做的伴侣讨论优缺点。如果您能做的更好，那就更好了，但是如果他拒绝了，那就去指挥一下

像在这里一样简单而简单地与您的经理交谈。这里有增长的潜力-如果您的同事很好，正如您所说的那样，那么让他开始转换为使用具有适当的OO概念的源代码控制和.Net并没有太大的说服力。

我将与其他人交谈，以更全面地了解您所处的位置。也许那里存在一些分离，这样他的代码就不必与其他代码混合太多，因为有可能以一种可以将其隔离的方式将他隔离到自己的区域中，尽管这对于像董事或首席信息官而不是开发商。

您可能想与他交谈，以了解他构建了什么样的大型系统，因为有些大型企业系统往往是很多构建基块，因此意大利面条式代码可能会泛滥成灾，“哦，这就是为什么OOP可以很好！” 尽管有时候确实需要这样做，但事实证明，在自己的工具箱中查看如何使用它会很有用。

冷漠可能是另一个怀疑者，看看这是否就是为什么他会拒绝我认为在设计代码方面我会认为基本的东西，但也许我受了太多的Kool-aid。

挑战他（以一种很好的方式）以证明你的能力，向他展示工具和实践的凉爽一面。不要光顾。

例如，也许他不相信版本控制是一种帮助，而是向他展示了如何进行分支/合并以及如何在不需要大量文件的情况下进行多种实验性功能。

关于OOP，向他展示一些很酷/复杂的设计模式，例如命令模式，任务模式以及如何为他节省宝贵的时间，以及您的整个团队。

如果您对他一点儿都不感兴趣，那么……他可能是个败笔，但话又说回来，您将拥有为您的团队服务的工具，并且您的表现将超越他。尝试使用一个存储库软件，该软件可以显示/通过电子邮件发送您的经理可以看到的提交消息，这将为您的经理带来透明度，并使您的同事置身事外（bitbucket.org拥有免费的私有存储库，如果您使用Mercural，则可以使用无限的空间）。

最后，不要试图用言语来说服，而是要采取无可辩驳的行动，这是对付固执的人恕我直言的最佳方法（逆向心理学有时也起作用，大声笑）。

好吧，您提到的技术显然是不错的，但是您还需要问自己是否是否将其推向意识形态。我发现年轻的程序员确实对他们在大学里学到的东西有些福音。记住，这些技术之所以好是因为结果：版本控制可实现并发开发，更清晰地跟踪设计，开发，测试，错误修正阶段。如果您的项目确实是短期的，那么其中很多根本就是不合适的，并且最终会使您的敏捷性降低。最佳实践根本不是意味着要使用所有可能的最佳实践。例如，至少在某些时候，抽象绝对可以是更多的责任而不是帮助。当您具有较长的开发时间线，复杂的代码和多个程序员时，版本控制才最有意义-这种协同作用很难零零散散地吸引。

我认为开始工作的地方是留意潜在的重用-随着项目的进行，考虑共同点或更普遍的框架。试图走出项目的前沿将是一项有力的举措，并且可能会让您运用更多的技术...

您应该请您的主管为每个人做一个关于“版本化”软件为什么很好的演示。不要单挑你的同事。

我本人对源代码控制软件表示怀疑，因为我看到人们一直在滥用它，以此来避免工作。

我的同事们不断融合，不断踩着彼此的脚趾。但是，关于它的好处的良好友好的演讲将是一件好事，并将激发讨论。