如何将COBOL程序员转变为现代程序员

Question

我在一个企业环境中工作，在这个环境中，开始使用COBOL IMS和CICS进行编程的人主导着思维模式。今天，他们中的大多数都使用Java等更现代的语言编程。但是，如果你看看他们的代码和设计决策没有太大的改变

• 方法很多屏幕
• 大量的全局变量或其现代化的单身模式
• 方法开头约30个变量定义
• globals而不是参数
• 而不是使用工厂方法一个巨大的开关语句
• 滥用数据库表列，因为“剩余空间足够”
• ...

这些人并不愚蠢，他们中的大多数都非常聪明。但向他们解释现代编码实践感觉就像为盲人描述颜色。你是否有任何经验或技巧可以教他们一种更现代的方法，而不是冒犯他们？

Answer 1

了解代码外观的最佳方法是阅读优秀的代码。尝试使用您自己的编码风格设置示例，并在代码审查期间轻轻指出其错误。这基本上只是一个观点问题;就像俗话说的那样，如果你拥有的唯一工具是锤子，那么每个问题看起来都像钉子一样。这些程序员根据他们所经历的语言来查看所有内容，因此即使在编写Java时，他们的思维过程也在COBOL中。他们的编码风格仅仅反映了他们的思维过程。

除此之外，让每个人都阅读Code Complete。

Answer 2

购买一份“代码完整版”并让他们写一本书报告。

Answer 3

一次使用一个反例来解释为什么为什么你的方式更好，更少痛苦，帮助他们按时回家，等等。一个人去一个非常重要。但是，如果你真的想要有机地发展文化的话。一些例子：

• 很长的方法：看，我看了你的长方法​​，并意识到你在两个地方使用相同的逻辑。我打破了这一点，现在你不必两次输入相同的代码。另外，我们只需要测试一次。
• 每个方法开头的全局变量和许多定义：请参阅，我已将变量移近其使用点。现在，我编写的这个测试代码使用系统查杀空指针对您的代码产生副作用，但这不能使我的副作用。
• 巨人开关：有时候，一个巨大的开关很难避免（有时你不应该）。也就是说，如果你正在尝试构建一个对象，那么“工厂”这个词就是在讲述。看，我的工厂方法有效地做了与你工厂相同的事情，但我让多态（例如）取代了一些switch-case管理。更少的代码=更少的错误=我们准时回家。

顺便说一句，我从来没有成功地为工程师分配阅读任务（尽管凯西提出了重构，这对于这类事物来说是一个很好的来源）。对我来说有用的是我阅读书籍，使用建议的技巧，展示成功以及如何让我的生活更轻松，然后，当“如何”的挫败感难道你知道如何解决所有这些问题吗？！“介绍，告诉他们有一本入门书。聪明的人会迅速将它从你的手中撕下来，你会在这个过程中失去皮肤。

Answer 4

我意识到，在我和COBOL程序员之间可能永远不会有思想会议，很多年前，当我还是一名教授C和C ++商业培训课程的讲师时。我刚刚完成了关于malloc（）和free（）的课程部分，大多数下注者都满意，当课程中的一个COBOL家伙过来问道：

“但这个'记忆'的东西是什么？我为什么要用呢？”

稍微有点建设性，ny经验是COBOL程序员经过培训可以考虑两件事：

• 记录
• 您对记录所做的事情

这实际上离OO并不太远，我认为你需要了解的基本想法是会有微妙的不同类型的记录，你需要对它们做不同的事情，以及最好的处理方式这就是将记录和需要完成的事情放在一起来创建对象。

Answer 5

让他们写Java;并拥有强大的代码审查标准。当他们的多页方法没有通过代码审查，因为它不是好代码时，请向他们解释为什么它不是好代码。在某些时候，他们可能会生气;我认为改变那些已经“长时间”安排而没有烦恼的习惯是不可能的。但只要审稿人保持合理和一致，他们就会逐渐看到这一点。经验确实是这种事情的唯一解决方案，这实际上是获得经验并指导经验的唯一方式（而不是从错误中吸取教训）。

Answer 6

除了代码完成（可能在此之后），让他们阅读Refactoring: Improving the Design of Existing Code（至少介绍）。它讨论了标准代码气味以及如何修复它们。

然而，听起来他们需要的是对如何以面向对象的方式思考的概述。我不确定那本书最好的是什么。

Answer 7

我强烈怀疑他们的心态是“有用的”，而不是“这是做什么的最佳方式”的心态。如果他们正在做的事情似乎有效，也许他们并没有像你想象的那样糟糕。

我使用COBOL和.Net代码。我的个人经历遇到了很多例子，我希望以一种更好的方式做事，而不是我的主管，他完全处于COBOL心态。在很多情况下，他提出了一个更简单的选择，这可能不是很优雅，但却是正确的选择。通过正确的决定，我的意思是，对公司来说更好。关于对团队和应用程序有益的事项，您需要记住以下几点：

• 有用吗？如果他们正在做的工作，没有比你的代码更多的问题，并且他们可以尽可能容易地维护它，那么它可能只是一个偏好。如果情况并非如此，那么您可以指向您的代码并说：“这更容易维护，看看它只需要30分钟来修复它没有问题？”不要试图揉鼻子，而是以身作则。最好说“看看这对我有用”，而不是“你应该这样做，因为会为你做点什么”。
• 每个人都能理解吗？使用最新的最方法的方法编程可能看起来很酷，但如果团队的一半不能在不引入两次错误的情况下调试代码，那是因为他们只是不知道这种做事方式应该如何工作。确保你不会比团队吸收新东西更快地引入新东西。当你不使用LINQ或任何新东西时，这可能会加剧，但这对公司来说是正确的举措。
• 需要吗？吻。或者正如阿尔伯特爱因斯坦所说的那样，“一切都应尽可能简单，但不能简单。”

Answer 8

你能让他们开始以某种方式开发好代码吗？做一些小改动？