Как убедить членов команды не использовать синглтоны?

Question

Я член команды, которая значительно выросла за последние два года.Три члена «старой команды» более двух лет работают над библиотекой, которой теперь должна пользоваться вся остальная команда.Они вложили много эго в эту библиотеку.К сожалению, оказалось, что они завалены синглетонами.

Синглтоны не позволяют нам писать тестируемый код.TDD важен для некоторых членов команды, но допускается только тремя создателями библиотеки.До сих пор мы пробовали следующее, чтобы убедить их избавиться от синглетонов:

• Выявлены проблемы с синглетами (глобальное состояние, сильная связь, трудно проверить)
  • Возражения былиотклонено, потому что текущий код работает.
• Продемонстрировано, что время от времени наши тесты (использующие библиотеку / синглтоны) не выполняются
  • Отклонено, потому что мы, очевидно, "не знаем, как работать с синглетонами"
• Предоставлена ​​альтернативная реализация
  • Отклонено, поскольку их текущий код уже работает
• Обсуждается с начальством по поводу проблем
  • Superior не является разработчиком программного обеспечения и должен выбирать между двумя «действительными» взглядами на проблему.Доверяет старшим членам команды больше.

Мы должны использовать эту библиотеку, потому что она уже заменила центральную часть нашей программы.Видите ли вы другой способ справиться с ситуацией?

Answer 1

Ваши проблемы с кодовой базой библиотеки не будут решены с помощью технических аргументов или технических подходов. Чтобы решить ваши проблемы с синглетами, пока будет работать чисто техническое решение. Но если вы хотите убедить «старую» команду не использовать одиночные игры и работать вместе с остальной командой, чтобы серьезно относиться к своим проблемам, вам определенно понадобится больше, чем просто технология.

Постарайтесь увидеть всю ситуацию с их точки зрения. Они усердно работали в течение двух лет, чтобы внедрить в эту библиотеку базу знаний, и им, надеюсь, понравилась эта работа. И теперь ваша «новая» команда приходит и говорит им, что внедрение, которое они потратили на два года своей жизни, является технической чушью. Как бы вы отреагировали в этой ситуации? Скажи, спасибо, эти синглтоны - действительно худший образец, который мы использовали? Нет, не совсем ...

Я бы порекомендовал вам прочитать Техническое изменение вождения и попытаться найти стратегию, как убедить их. Между тем, мой лучший совет: уважайте их работу, старайтесь посмотреть на ситуацию с их точки зрения, постарайтесь убедить одного за другим, а не команду, и создайте оболочку вокруг этого «унаследованного» кода.

Answer 2

Обычный подход опытного разработчика состоит в том, чтобы обновить свое резюме / резюме и начать искать другую работу, прежде чем осознает, что система не может быть достаточно надежной для доставки, доставляется в любом случае и становится бесконечным черепком не-золото, которое кто-то должен постоянно поддерживать. «Кто-то» должен быть одним из старших разработчиков с 40-летним пенсионным правом на защиту - «предложение, от которого он не может отказаться».

Может быть, я чрезмерно циничен, потому что мой последний проект сам превратился в чудовище без золота за одну ночь после безобидных изменений, или, может быть, я помню, что произошло десятилетия назад, когда я встал на обзорной встрече и заявил: Эта работа не может работать так, как она была задумана »(с тех пор, как я только что вышел на работу раньше или сделал это как контрактная работа).

Answer 3

(Вы не указали свой язык или платформу, поэтому я буду использовать 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 при работе всей системы.

(Кроме того, эти синглтоны даже реализованы правильно? Вы можете получить больше бай-инов, если покажете, что шаблон синглтона не только неудачен с точки зрения тестирования, но также может быть плохо реализован ... ) * +1010 *

Answer 4

На мой взгляд, вы должны рассматривать эту библиотеку как внешнюю зависимость вашего кода (например, сторонней библиотеки) и кода соответственно.

Это означает, что, как упоминал Джон Скит, проектируйте свой код так, чтобы он был изолированным и тестируемым без внешней библиотеки. Разработайте пару интерфейсов (чисто виртуальных классов), которые фиксируют требуемые контракты, которые вы ожидаете от них выполнить, а также напишите пару интеграционных тестов, которые осуществляют связь между вашим кодом и этой библиотекой. В идеале, коммуникационная поверхность должна быть как можно меньше, возможно, только для пары адаптеров или мостов, которые реализуют ваши интерфейсы.

Тогда возникает проблема согласования "контракта", когда вы указываете части библиотеки, которые работают не так, как ожидалось, и (надеюсь) ждут исправления или соответственно адаптируют свой код. Вы можете обнаружить ошибки и семантические несоответствия таким образом, что может привести к параллельной эволюции вашего кода и библиотеки.

Если ваш код является единственным потребителем этой библиотеки, вы должны диктовать, что от нее ожидается, и она должна адаптироваться к вашим потребностям, а не наоборот. , Если они затем предоставляют ожидаемую услугу, тот факт, что они используют синглтоны или еще много чего, становится неактуальным.