17

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

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

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

4

8 回答 8

20

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

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

于 2009-07-09T17:43:55.303 回答
11

给他们买一本“Code Complete”，让他们写一份读书报告。

于 2009-07-09T17:43:39.623 回答
10

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

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

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

于 2009-07-09T18:07:04.927 回答
8

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

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

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

  • 记录
  • 你对唱片所做的事情

这实际上离 OO 并不太远，我认为您需要了解的基本思想是，记录的类型会略有不同，您需要对它们做不同的事情，而处理这种情况的最佳方法是把记录和需要做的事情放在一起来创建对象。

于 2009-07-09T17:56:12.390 回答
4

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

于 2009-07-09T17:52:54.003 回答
3

除了 Code Complete（可能在那之后），让他们阅读重构：改进现有代码的设计（至少是介绍）。它讨论了标准代码异味以及如何修复它们。

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

于 2009-07-09T18:06:04.150 回答
3

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

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

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

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

于 2009-07-09T18:08:02.227 回答