Question

我是团队成员，在过去两年里已经有了很大的发展。 “旧团队”的三名成员已经在图书馆工作了两年多，现在团队的其他成员都必须使用。他们为这个图书馆投入了大量的自我。不幸的是，结果却被单身人士所困扰。

单身人士使我们无法编写可测试的代码。 TDD对一些团队成员很重要，但只有三位图书馆创建者才能容忍。到目前为止，我们已经尝试以下方法来说服他们摆脱单身人士：

指出单身人士的问题（全球状态，紧耦合，难以测试）
- 反对被拒绝，因为当前的代码有效。
证明我们的测试（使用图书馆/单身人士）不时失败
- 拒绝，因为我们显然“不知道如何与单身人士合作”
提供替代实施方案
- 拒绝，因为他们当前的代码已经有效
与上级一起讨论问题
- Superior不是软件开发人员，必须在两个“有效”视图之间进行选择。更信任老员工。

我们必须使用该库，因为它已经取代了我们程序的核心部分。你还有其他方法可以解决这个问题吗？

Answer 1

（你没有说明你的语言或平台，所以我将以C＃为例。我希望同样的原则适用于其他人。）

您是否可以创建自己的接口和那些适当委派的接口的实现？即使库设计者不愿意实现接口，您也可以始终委托：

// Existing code
public class FooSingleton
{
    public static FooSingleton Instance { get { ... } }

    public void Bar()
    {
        ...
    }
}

public interface IFoo
{
    void Bar();
}

public class SingletonDelegatingFoo : IFoo
{
    public void Bar()
    {
        FooSingleton.Instance.Bar();
    }
}

然后使用常规依赖注入（或其他）来使您自己的代码可测试，仅依赖于IFoo - 并在运行完整系统时注入SingletonDelegatingFoo。

（顺便说一句，这些单身人士是否正确实施？如果你能证明单身人士模式不仅仅是从测试的角度来看，而且还可能被严重执行，你可能会得到更多的支持...... ）

Answer 2

经验丰富的开发人员通常的做法是更新他们的简历/简历并开始寻找另一份工作，然后才意识到系统无法提供足够可靠的交付，无论如何交付并成为一个永无止境的缸不是有人必须不断维持的黄金。 “某人”应该是具有40年养老金权利的老年开发商之一 - “他/她无法拒绝的提议”。

也许我过于愤世嫉俗，因为我的最新项目在一次无害的改变之后一夜之间就变成了一个非金的缸子，或者我记得几十年前我在一次审查会议上站起来并说“这项工作不可能像它的设计一样工作，（从那次经历开始，我刚刚提前退出，或者作为合同工作完成）。

Answer 3

使用技术参数或技术方法无法解决您对库代码库的问题。要解决单身人士的问题，现在可以使用纯技术解决方案。但是如果你想说服“旧”团队不要使用单身人士并与团队的其他成员一起工作，那么认真对待你的问题，你肯定需要的不仅仅是技术。

尝试从他们的角度看待整个情况。他们正在努力工作两年，以实现他们拥有的知识库，并希望他们喜欢这项工作。而现在你的“新”团队即将到来并告诉他们，实施，他们投入了两年的生活，是技术上的废话。在那种情况下你会如何反应？说，呃，谢谢，这些单身人士真的是我们用过的最糟糕的模式吗？不，不是真的......

我建议您阅读Driving Technical Change并尝试找出如何说服他们的策略。与此同时，我最好的建议是：尊重他们的工作，尝试从他们的角度看情况，尝试逐个说服 - 而不是团队，并围绕这个“遗留”代码构建一个包装器。

Answer 4

在我看来，你必须将该库视为代码的外部依赖（如第三方库）和相应的代码。

这意味着，正如Jon Skeet所提到的那样，将您的代码设计为隔离且可测试的，而无需外部库。设计一些接口（纯虚拟类）来捕获您期望它们实现的所需合同，并编写一些集成测试来执行代码与该库之间的通信。理想情况下，通信表面应尽可能小，可能只会降级为实现接口的几个适配器或桥接器。

然后它就成了“合同”协商的问题，你指出库中没有按预期工作的部分和（希望）等待修复或相应调整你的代码。您可能会以这种方式表现错误和语义不匹配，这可能会促使您的代码和库的并行演变。

如果您的代码是该库的唯一使用者，您应该决定对它的期望，并且它应该适应您的需求，而不是其他四处走走。如果他们随后提供您期望的服务，那么他们使用单身或其他东西的事实就变得无关紧要了。

如何说服团队成员不要使用单身人士？

4 个答案: