我目前正在一家公司工作,我们正在进行Perl开发.然而,代码非常混乱,使用了非常古老的Perl习语,所以我决定慢慢清理它并教我的同事关于Modern :: Perl,良好的软件设计,OOP - 抽象,耦合,继承,SOLID原则等等.有一个缺点,我在这里工作只有一个月,所以我在这里很新.
我的问题是:我可以(如果是这样的话)说服他们考虑从普通的Perl OO切换到Moo(se)吗？它的优点是什么？我需要他们考虑的充分理由.
使用这些模块是否有很大的性价比？我从经验中知道,使用这些模块非常舒服(特性也非常好),但我担心由于性能原因它们会拒绝切换.
所以.有没有优势,你会如何描述那些陷入2000年前时代的Perl开发者？
小智 9
特别是对于Moose,在PerlMonks和Stackoverflow上有一些有趣的性能讨论.它的要点似乎是穆斯有一个重要的启动惩罚,但在此之后并不多.
但是,我认为这里有一个更大的问题:什么时候应该重写现有代码？
选择新工具/方法时需要考虑两个不同的阈值:
当现有的范例很好时,很多人都犯了错误,就是用他们喜欢的范例重写一堆完美的代码.这不仅浪费了工作,而且还有引入新漏洞并使最终产品比之前更糟糕的危险.
更改现有代码库使用的对象系统接近于对代码的基本重写.这是一个主要的成本和风险,你需要一个很好的理由去做.不仅仅是"Moose更好地编写代码".
当编写一段与遗留代码完全分开的新代码时,可能是尝试Moose的好时机.但我怀疑改变所有现有代码并不合理.(另外,从实际上让人们倾听你的想法的角度来看,无论如何,小的增量变化都会好得多).
我首先要问——你的同事是否理解你所说的这些术语的含义以及为什么它们是好事？采用新范例总是面临着艰巨的挑战，因为即使您的“新方式”在各方面都更好……您将创建一个仍然需要维护的遗留代码库。或者重新加工。
如果某人已经从 bash 脚本编写到 Perl 黑客技术建立了对 Perl 的理解，那么说服他们“走向面向对象”可能是一个挑战。他们很可能——非常正确地——指出，虽然转换有好处，但“最小公分母”是适用的。与了解“Moose”的人相比，有很多人了解“非 Moose”perl。（不过，这可能对你有利 - 指出这是一个有用的技术专业，可以提高他们未来的就业能力）
毕竟，今天仍然使用 shell 脚本是有原因的 - 因为它们是解决眼前问题的简单、直接且易于访问的解决方案。
首先，介绍一下你的计算机科学原理。让你的同事“接受”你概述的事情。这需要时间。大概是很多时间。如果代码风格 15 年没有改变，那就意味着那里的程序员对现状感到满意。
然后，你需要向你的同事证明为什么“你的方式”更好，足以让他们费心去学习。新的“东西”不断出现，总有人想尝试新的、很酷的东西。在他们看来，你会像这个人。对他们来说，目前的“房子风格”效果很好。
您可能会发现以您的新风格实施新事物是令人信服的。让他们“接受”你的做法，作为概念证明。您可能会发现其他几个程序员也喜欢这个想法。
但无论如何 - 你必须接受一种非常现实的可能性，即没有人愿意偿还你通过这样做所创造的“遗产”的技术债务。在您的组织中使用一组有限的编码范例可以带来很多业务优势。您需要考虑两者都投入使用将如何发挥作用。
但这并不是一个新的讨论——面向对象编程总是有一些人认为它没有意义——他们看到的是开销，而不是好处。我们使用面向对象的原因并不是因为它更高效。这是因为它是构建健壮、可靠和可测试代码的好方法。这将是您收养驼鹿的“宣传”。我建议您考虑各种形式的测试，并准备一个测试套件的演示，因为这些是大多数程序员讨厌的事情:)
| 归档时间： |
|
| 查看次数： |
935 次 |
| 最近记录： |