6

我目前在一家公司工作,我们正在那里进行 Perl 开发。但是代码真的很乱,使用了非常古老的 Perl 习语,所以我决定慢慢清理它并向我的同事传授 Modern::Perl、优秀的软件设计、OOP - 抽象、耦合、继承、SOLID 原则等。有一个缺点,我在这里只工作了一个月,所以我在这里很新。

我的问题是:我可以(如果可以的话)说服他们考虑从普通的 Perl OO 切换到 Moo(se) 吗?它有什么优点?我需要非常好的理由让他们考虑。

使用这些模块是否有很大的性价比?我从经验中知道,使用这些模块非常舒服(特性也非常好),但我担心他们会因为性能原因而拒绝切换。

所以。有什么优势吗?您如何向被困在 2000 年前时代的 Perl 开发人员描述它?

4

2 回答 2

9

特别是对于 Moose, PerlMonksStackoverflow上有一些关于性能的有趣讨论。它的要点似乎是 Moose 有一个显着的启动惩罚,但在那之后并不多。

但是,我认为这里有一个更大的问题:什么时候应该重写现有代码?

选择新工具/方法时需要考虑两个不同的阈值:

  1. 工具/方法 XYZ 是有益的,所以我们应该在编写新代码时使用它。
  2. 工具/方法 XYZ 非常有用,我们必须重写现有代码才能使用它。

很多很多人都犯了一个错误,即使用他们喜欢的范式重写一大堆完美的代码,而现有的范式就很好。这不仅是浪费工作,而且有引入新错误并使最终产品比以前更糟的危险。

更改现有代码库使用的对象系统接近于对代码的基本重写。这是一个主要的成本和风险,你需要一个很好的理由来这样做。不仅仅是“Moose 更适合编写代码”。

当需要编写一段与遗留代码完全不同的新代码时,这可能是尝试 Moose 的好时机。但我怀疑更改所有现有代码并不是真正合理的。(此外,从实际让人们倾听您的想法的角度来看,小的增量更改会更好地工作,无论如何)。

于 2015-03-05T12:43:37.207 回答
4

我首先要问-您的同事是否理解您所说的这些术语的含义以及为什么它们是好东西?采用新范式总是会遇到困难的挑战,因为即使您的“新方式”在各方面都更好……您将创建一个仍然需要维护的遗留代码库。或者重做。

如果某人已经建立了从 bash 脚本到 perl hacking 的 Perl 理解,那么说服他们“去 OO”……可能是一个挑战。他们很可能 - 非常正确地 - 指出,虽然切换有优势,但“最小公分母”是适用的。与了解“Moose”的人相比,了解“非 Moose”perl 的人很多。(不过,这可能对你有利——指出这是一项有用的技术专长,可以提高他们未来的就业能力)

毕竟,今天仍然使用 shell 脚本是有原因的——因为它们是解决当前问题的简单、直接和可访问的解决方案。

所以首先 - 介绍你的计算机科学原理。让您的同事“接受”您概述的内容。这需要时间。大概很多时间吧。如果代码风格已经 15 年没有改变,那意味着那里的编码人员对事物的方式感到满意。

然后,您需要向您的同事证明,为什么“您的方式”更好,足以让他们费心去学习它。新的“东西”一直在出现,总有人想尝试新的、很酷的东西。在他们看来,你会像这个人。就他们而言,目前的“房屋风格”运作良好。

您可能会发现以您的新风格实施新事物是令人信服的。让他们“买进”你的做法作为概念证明。您也可能会发现其他几个程序员也喜欢这个想法。

但无论如何——你必须接受这样一个非常现实的可能性,即没有人愿意支付你将通过这样做而创造的“遗产”的技术债务。在您的组织中使用一组有限的编码范例可以带来很多业务优势。你需要考虑如何让两者都投入使用。

虽然这不是一个新的讨论——OO 编程总是有一些人不明白这一点——他们看到的是开销,而不是好处。我们使用 OO 的原因并不是因为它更高效。这是因为它是构建健壮、可靠和可测试代码的好方法。这将是您采用 Moose 的“宣传”。我建议您查看各种形式的测试,并准备一个测试套件的演示,因为这些是大多数编码人员讨厌的东西:)

于 2015-03-05T12:52:24.830 回答