如何将 COBOL 程序员转变为现代程序员 [关闭]答案

【问题标题】：How to transform COBOL programmers into modern day programmers [closed]如何将 COBOL 程序员转变为现代程序员 [关闭]
【发布时间】：2009-07-09 17:39:53
【问题描述】：

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

方法多屏
大量全局变量或其现代化身为单例模式
方法开始时大约有 30 个变量定义
全局变量而不是参数
不使用工厂方法，而是使用巨大的 switch 语句
因为“还有足够的空间”而滥用数据库表列
...

这些人并不愚蠢，他们中的大多数人都很聪明。但是向他们解释现代编码实践就像向盲人描述颜色一样。您有什么经验或技巧可以在不冒犯他们的情况下教给他们更现代的方法吗？

【问题讨论】：

+1：像对待人一样对待他们。我昨晚在武术课上第一次使用双节棍。天哪，那是多么令人愉快的谦卑练习。

标签： cobol

【解决方案1】：

了解代码外观的最佳方法是阅读好的代码。尝试以自己的编码风格树立榜样，并在代码审查期间轻轻指出他们的错误。这本质上只是一个观点问题。俗话说，如果你唯一的工具是一把锤子，那么每个问题看起来都像钉子。这些程序员根据他们所使用的语言来看待一切，因此即使在编写 Java 时，他们的思维过程也是在 COBOL 中进行的。他们的编码风格只是他们思维过程的反映。

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

【讨论】：

阅读书籍是程序员被低估的资源。
不过，请注意 RTFM 综合症。如果你的贡献是“你应该在学校读更多的书”，那么交流很快就会中断。
Beautiful Code 这本书有一些好的代码示例，虽然不是每个人都会喜欢所有的示例。
Beautiful Code 并不适合所有人。很多 SO 用户似乎不赞成它：stackoverflow.com/questions/184138。您可能想在购买前阅读评论。

【解决方案2】：

给他们买一本《Code Complete》，让他们写一篇读书报告。

【讨论】：

【解决方案3】：

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

非常长的方法：看，我查看了您的长方法并意识到您在两个地方使用了相同的逻辑。我打破了这一点，现在您不必输入相同的代码两次。此外，我们只需对该部分进行一次测试。
全局变量和每个方法开头的许多定义：看，我已将您的变量移到更接近其使用点的位置。现在，我编写的这个测试代码对你的代码产生了副作用，它带有一个会杀死系统的空指针，但它不能对我的代码产生副作用。
巨变：有时，巨变很难避免（有时您不应该）。也就是说，如果您尝试构建一个对象，那么“工厂”这个词就可以说明问题。看，我的工厂方法实际上和你的工厂做同样的事情，但是我让多态性（例如）取代了一些 switch-case 管理。更少的代码 = 更少的错误 = 我们准时回家。

顺便说一句，我从来没有成功地将阅读作业分配给工程师（尽管 Kathy 提出了重构，这是这类事情的绝佳来源）。对我有用的是我阅读书籍，使用建议的技术，展示成功以及它如何让我的生活更轻松，然后，当“如何难道你知道如何解决所有这些事情？！”进入，告诉他们有一本操作指南。聪明的人会很快把它从你手中夺走，你会在这个过程中失去皮肤。

【讨论】：

【解决方案4】：

多年前，当我担任 C 和 C++ 商业培训课程的讲师时，我意识到我和 COBOL 程序员之间可能永远不会有思想交流。我刚刚完成了关于 malloc() 和 free() 的课程部分，令大多数下注者普遍满意，当课程中的一个 COBOL 人走过来问：

“但是这个‘记忆’是什么东西？我为什么要使用它？”

更具建设性的是，根据经验，COBOL 程序员经过培训可以考虑两件事：

记录
您对记录所做的事情

这其实离 OO 不远了，我认为你需要了解的基本思想是，记录的类型会有细微的不同，你需要对它们做不同的事情，以及最好的处理方式这样做就是把记录和需要做的事情放在一起来创建对象。

【讨论】：

哈哈！ +1 让咖啡从我的鼻子里冒出来...... :-)
太棒了。我想知道现在有多少 Java 程序员会问同样的问题……
感谢 McWafflestix 对我做同样的事情。 (8
有一天，软件世界将回到 COBOL 的思维方式.. 你有记录，你做事要记录。其他一切都只是hardwarese computery gobbledegook。无论如何，企业为什么要关心 malloc。你提到的“对象”也将结束。毕竟，OOP 只是我们为克服左/右脑不平衡而发明的另一种方法。（PS。我不知道我刚才说了什么。在当时看来是一件好事。）

【解决方案5】：

让他们编写 Java；并拥有强大的代码审查标准。当他们的多页方法因为不是好代码而没有通过代码审查时，向他们解释为什么它不是好代码。在某些时候，他们可能会生气；我认为改变长期“养成”的习惯是不可能的。但只要审阅者保持合理和一致，他们就会随着时间的推移开始明白这一点。经验确实是此类事情的唯一解决方案，而这确实是获得经验并得到指导的唯一方法（而不是从错误中吸取教训）。

【讨论】：

【解决方案6】：

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

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

【讨论】：

【解决方案7】：

我强烈怀疑他们的心态是“什么可行”的心态，而不是“什么是做到这一点的最佳方式”的心态。如果他们正在做的事情似乎有效，那么他们可能并没有你想象的那么糟糕。

我同时使用 COBOL 和 .Net 代码。我的个人经历遇到了很多例子，我想以比我的主管更好的方式做某事，而我的主管完全是 COBOL 思维模式。在很多情况下，他提倡一种更简单的选择，这可能并不优雅，但却是正确的决定。通过正确的决定，我的意思是，对公司更好。对于团队和应用程序的好处，您需要牢记以下几点：

有效吗？如果他们正在做的工作，没有比您的代码更多的问题，并且他们可以尽可能轻松地维护它，那么这可能只是一种偏好。如果不是这样，那么你可以指着你的代码说，“这更容易维护，看看它只花了 30 分钟就修复了，而且没有问题吗？”不要试图在其中摩擦他们的鼻子，而是以身作则。说“看看这对我有什么用”比“你应该这样做，因为这会为你完成一些事情”要好得多。
大家能看懂吗？使用最新最奇特的方法进行编程可能看起来很酷，但如果一半的团队无法在不引入两倍错误的情况下调试您的代码，那是因为他们只是不知道这种做事方式应该如何工作。确保你引入新事物的速度不会超过团队吸收它们的速度。当您不使用 LINQ 或任何新事物时，情况可能会变得更糟，但这对公司来说是正确的举措。
需要吗？吻。或者正如阿尔伯特·爱因斯坦所解释的那样，“一切都应该尽可能简单，但不能简单。”

【讨论】：

【解决方案8】：

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

【讨论】：