Страницы

вторник, 23 августа 2016 г.

Принцип YAGNI

На ru.stackoverflow.com недавно был задан вопрос, который, ИМХО, стоит вашего внимания: Нарушает ли OCP и DIP (из SOLID) принцип YAGNI?. Ниже представлен немного более развернутая версия моего ответа.

Разные принципы проектирования направлены на решение противоречащих друг другу задач проектирования. Можно сказать, что разные принципы «тянут» дизайн в разные стороны и нужно найти правильный вектор, наиболее полезный в данном конкретном случае. SRP толкает в стороны простого решения, а OCP – в сторону изоляции компонентов, а DIP – направлен на построение правильных отношений между типами.

Следование одному принципу может привести к нарушению другого. Так, например, любое наследование *можно* рассматривать как нарушение SPR, поскольку теперь за одну ответственность (рисование фигур) отвечает целая группа классов. Принципы DIP и OCP, которые часто требуют наследования, могут привести к появлению дополнительных «швов», т.е. интерфейсов/базовых классов в системе, что, опять-таки, приведет к нарушению SRP и/или ISP.

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

Принцип YAGNI (You Aren’t Gonna Need It) – это более фундаментальный принцип («принцип высшего порядка» или «метапринцип»), который поможет понять, когда следовать принципам/паттернам/правилам, а когда нет.

В основе принципа YAGNI лежит несколько наблюдений:

1. Программисты, как и люди в целом, плохо предсказывают будущее.

2. Затраты, сделанные сейчас могут быть оправданными или неоправданными в будущем.

3. Ни одно гибкое решение не будет достаточно гибким.

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

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

Хороший дизайн заключается в простом решении, когда изменения требований ведут к линейным трудозатратам.

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

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

Инвестиции в продуманность интерфейса программирования библиотеки (API) – будут оправданны, поскольку стоимость внесения изменений очень высока. Стоимость же выделения интерфейса/базового класса в приложении является практически одинаковой сегодня или через год. Но через год данное выделение будет более оправданным экономически и практически. Мы не делали лишнюю работу раньше времени, а значит можем сосредоточить усилия на чем-то важным в данный момент. К тому же, через год у нас появится больше информации на предмет того, каким именно должен быть базовый класс или интерфейс, поскольку они будут основаны на реальных, а не воображаемых требованиях.

Решение проблемы по мере поступления позволяет сосредоточиться на задачах, актуальных сегодня и позволяет избежать работы, которая может и не понадобиться совсем.

18 комментариев:

  1. С распространением ПО и прикладного программирования, появилось очень много всевозможных "евангелистов", которые продают "серебряные пули" для решения всех проблем. У новичка создается впечатление, что без SOLID, паттернов и прочего, его проект будет не по "фен-шую". Схожий эффект можно наблюдать у аудиофилов, когда 2 метра бескислородной меди ценой за 1k$/метр добавят в звук красок, сочности, выражение и тепла.
    Принципы, паттерны и прочие практики - инструментарий, который надо использовать по мере необходимости, а главное оптимально. Каждый инструмент/практика решают конкретную проблему, если проблема не наблюдается, то и не надо применять инструмент.

    В примере иерархии фигур мне больше всего не нравится метод Shape.Draw. Фигуру рисует рисовальщик, а не сама, это основное нарушение SRP, фигура в себе содержит просто набор графических примитивов, которые может взять кто угодно и напечатать их координаты либо их нарисовать. Мы таким образом делали UI на DirectX.
    Вообще в последнее время я практически не вижу инженерного/научного подхода к созданию ПО, который набирал обороты в начале 2000.

    ОтветитьУдалить
    Ответы
    1. Слава, спасибо за коммент.

      По поводу shape.draw: здесь все довольно любопытно. Как я написал в статье, само понятие "единственной ответственности" может меняться по мере усложнения системы. И когда что-то было столь простым, как вывод на консоль, то эта ответственность могла вполне помещаться в один тип, то по мере усложнения, вполне нормально выделение рисования в отдельную иерархию.

      Удалить
  2. У меня больше года крутится похожий вопрос в голове: не противоречит ли практика TDD принципу YAGNI? Я много раз пытался сесть на hype-train TDD, но мне не удалось совсем не из-за «надо привыкнуть к специфичному workflow», а вот этот вот их любимого «TDD будет форсировать раз закладывать нужную гибкость сразу, преимущественно путем выделения интерфейсов». А кто сказал, что эта гибкость мне нужна или будет нужна?

    ОтветитьУдалить
    Ответы
    1. *форсировать вас закладывать

      Удалить
    2. Максим, мне кажется, что с TDD дело обстоит скорее наоборот. TDD "изобретено" Кентом Беком - большим сторонником YAGNI (он, собственно, его и популяризировал путем популяризации XP).

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

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

      Но, как я неоднократно писал, я не использую TDD, хотя и постоянно использую юнит-тесты.

      Удалить
    3. А какие критерии для того чтобы использовтаь TDD для начала?
      По мне TDD может хорошо лечь на зрелый продукт, с добавление N+1 фича, но на практике я так не делал.
      На начальном этапе продукта я не уверен, что одновременное написание юнит тестов и кода являются оптимальной тратой ресурсов. Пусть у юзера будет что-то нестабильное работающее и сформирует представление, нежели, чем ничего.
      На практике юнит тестами, мы покрываем, лишь необходимый функционал: критичный, широко используемый и т.д.
      В общем как всегда и для любого инструмента, область применения, целесообразность, какую проблему решаем и т.д.

      Удалить
    4. Ваши ответы прояснили ситуацию, спасибо!

      Из-за темы юнит-тестов и интерфейсов я вспомнил еще один свой давний вопрос. Допустим, у меня есть класс, а в нем есть приватный метод, который что-то сложное считает. Я хочу сделать для него парочку юнит-тестов, но ортодоксальные последователи всяких там TDD восклицают, что дескать риальные пацаны не юнит-тестируют приватные методы.

      Что делать? Делать его публичным и терпеть, что метод публичен, хотя никому не нужен (пока или вообще)? Тестировать скрытый метод, не слушая пуристов? Тестировать исключительно публичные методы, надеясь, что это покроет автоматически и приватный код?

      Удалить
    5. Когда у нас стоит задача типа "нужно протестировать приватный метод". Мы выделем алгоритм в отдельный клас "стратегию". И тестируем её отдельно.

      Удалить
    6. Слава: вот небольшая история по поводу использования тестов в начале работы над проектом.

      Мелкомягкие проводят вселенские хакатоны раз в год, и в прошлом году мы с камрадами работали над альтернативой reference.microsoft.com с эластик-серчем и девицами. Я занимался бекэндом и с самого начала добавил тесты на слой доступа к данным. Это не было TDD, но тесты были рано. Ребята вначале довольно косо на меня смотрели. Ведь это хакатон, на который у нас есть три дня. Какие, нафиг, тесты? Но они окупились, поскольку упростили добавление новых фич даже в столь коротком спринтерском темпе, как хакатон.

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

      Удалить
    7. Именно только/преимущественно на слой доступа к данным? Потому что эта часть во всей системе одна из наиболее центральных, а также сравнительно стабильна?

      Удалить
    8. Поскольку я занимался именно им, то и добавлял именно туда.

      Мой поинт в том, что выгоды будут практически всегда, даже в кроткосрочной перспективе.

      При отсутствии нвыка, выгод не будет. Но при его наличии - он будет обязательно (с прагматичным подходом, ессно).

      З.Ы. на начальных этапах о стабильности говорить сложно. Дизайн был стабилен, а реализация - нет.

      Удалить
    9. Кстати да, поговорить на эту тему изначально как раз и толкнул тот факт, что юнит тестирование сильно толкает на "лишние" абстракции от которых порой противно.

      Удалить
  3. Сергей, тут как всегда принцип разумного. Слой доступа к данным - сервисная функциональность, дефект в которой может быть очень обнаружимим.
    В добавлении тестов "потом" не вижу ничего страшного, если код написан хорошо, то требуется мало усилий чтобы его покрыть тестами. И в моей практике, потом обычно наступает, когда часть функционала уходит юзерам, вот тогда и можно подумать о тестах.

    ОтветитьУдалить
    Ответы
    1. Слава, я согласен, что когда код написан хорошо, то тесты добавить легко.
      Просто бывает это редко, чтобы он был настолько хорошо написан:)

      Удалить
  4. > Инвестиции в продуманность интерфейса программирования библиотеки (API) – будут оправданны, поскольку стоимость внесения изменений очень высока. Стоимость же выделения интерфейса/базового класса в приложении является практически одинаковой сегодня или через год.

    В некоторых случая через год у API или даже в целом продукта может быть большое количество пользоватей и изменить его будет не так уж просто. Но по большому счету согласен со статье, спасибо!

    ОтветитьУдалить
    Ответы
    1. Про API мысль была именно такая: что поменять его почти наверняка будет сложно, ибо его цель - реюз. Код приложения (если это не библиотека), обычно не является "опубликованным" и не обладает кучей клиентов, а значит обычно менять его значительно легче.

      Удалить
  5. У вас опечатка "Так, например, любое наследование *можно* рассматривать как нарушение SPR," SPR -> SRP

    ОтветитьУдалить