flat-file - 如何说服编程团队放弃旧方法？

Question

这更像是一个面向业务的编程问题，我似乎无法弄清楚如何解决。我与一个使用 BASIC 超过 20 年的程序员团队一起工作。我被请来帮助在 .NET 中编写相同的软件，只有更新和现代实践。问题是我似乎无法让其他 3 名团队成员(所有 BASIC 程序员，尽管现在也有 .NET)了解如何正确地创建关系数据库。这是他们无法理解的事情:

我们基本上有一个跟踪客户标签信息的事务。我们需要能够跟踪当前交易和过去的交易。在旧系统中，使用了一个平面文件数据库，其中一个表包含客户当前基本交易的记录，另一个包含客户所有先前交易以及重要货币信息的交易。为了防止冗余，他们会用历史交易覆盖当前交易——(历史文件首先更新，然后是当前的。)这完全没有必要，因为你只需要一个交易表，但我的主管或我的其他两个同事中的任何一个- worker 似乎无法理解这一点。我究竟如何才能说服他们看到光明，这样我们就不必做大量荒谬的工作并最终多次访问数据表？感谢您的输入!

Answer 1

首先，我必须承认，从您的描述中，我并不完全清楚现有结构中的数据结构和逻辑流实际上是什么。这对我来说确实意味着，也许您也没有向您的同事明确说明自己，因此您的首要任务之一必须是能够以口头或最好以书面和图表的方式解释当前情况和提议的替代人选。请将此视为一种观察，而不是对您的问题的任何批评。

其次，我确实发现有 20 年经验的程序员不了解关系数据库和事务是非常了不起的。平面文件编码很久以前就退出了主流——我在 1988 年第一次在商业环境中处理关系数据库，到 90 年代中期它们已经很普遍了。您从事什么行业和产品类型？在我看来，您可能正在处理某种嵌入式或其他“不寻常”系统，在这种情况下，您确实需要确保您没有某种通信问题并且您正在俯瞰一头大大象尚未向您指出的问题-您不会成为第一个因未获得适当信息而以某种方式成立的团队的“顾问”。也就是说，这种古老的商店仍然存在——我当前的一个客户系统接口(interface)到一个用 COBOL 编码的基于平面文件的系统，是的，管理起来简直是 hell ；-)

最后，如果您完全确定自己的立场并且您面对的团队不会接受您的建议 - 如果您可以抽出时间演示代码是一个好主意 - 那么您可能不得不接受优雅地决定并移动一个。我自己在这个位置上我会尝试抽象出这个问题 - 例如，数据库更新是否可以移动到存储过程中，以便更新两个表的代码在 SP 中，并且可以在以后修改以移动到您的架构而无需相应的应用程序更改？确保您的论点得到妥善记录和记录，以便以后有机会时可以重新审视它们。

您不会是第一个因为办公室政治而不得不实现次优解决方案的编码人员 - 将其用作您自己处理此类情况的个人发展的学习经验，并同情自己认为您将获得额外报酬的想法工作。通常，此类争论中的决定因素不是逻辑，而是您自己带来的“声誉权重”——听起来您被带进来对您的团队没有太大的影响力，所以您在您在后续情况下获得足够的声誉之前，您可能必须通过擅长执行他们同意做的事情来获得声誉 - 您需要先进行 retrofit !