我首先要问-您的同事是否理解您所说的这些术语的含义以及为什么它们是好东西?采用新范式总是会遇到困难的挑战,因为即使您的“新方式”在各方面都更好……您将创建一个仍然需要维护的遗留代码库。或者重做。
如果某人已经建立了从 bash 脚本到 perl hacking 的 Perl 理解,那么说服他们“去 OO”……可能是一个挑战。他们很可能 - 非常正确地 - 指出,虽然切换有优势,但“最小公分母”是适用的。与了解“Moose”的人相比,了解“非 Moose”perl 的人很多。(不过,这可能对你有利——指出这是一项有用的技术专长,可以提高他们未来的就业能力)
毕竟,今天仍然使用 shell 脚本是有原因的——因为它们是解决当前问题的简单、直接和可访问的解决方案。
所以首先 - 介绍你的计算机科学原理。让您的同事“接受”您概述的内容。这需要时间。大概很多时间吧。如果代码风格已经 15 年没有改变,那意味着那里的编码人员对事物的方式感到满意。
然后,您需要向您的同事证明,为什么“您的方式”更好,足以让他们费心去学习它。新的“东西”一直在出现,总有人想尝试新的、很酷的东西。在他们看来,你会像这个人。就他们而言,目前的“房屋风格”运作良好。
您可能会发现以您的新风格实施新事物是令人信服的。让他们“买进”你的做法作为概念证明。您也可能会发现其他几个程序员也喜欢这个想法。
但无论如何——你必须接受这样一个非常现实的可能性,即没有人愿意支付你将通过这样做而创造的“遗产”的技术债务。在您的组织中使用一组有限的编码范例可以带来很多业务优势。你需要考虑如何让两者都投入使用。
虽然这不是一个新的讨论——OO 编程总是有一些人不明白这一点——他们看到的是开销,而不是好处。我们使用 OO 的原因并不是因为它更高效。这是因为它是构建健壮、可靠和可测试代码的好方法。这将是您采用 Moose 的“宣传”。我建议您查看各种形式的测试,并准备一个测试套件的演示,因为这些是大多数编码人员讨厌的东西:)