Делюсь болью. Я последние 5 лет на разных уровнях у разработчиков, лидов и техдиректоров, активно встречаю такой паттерн:
Ну давай просто выделим общее и переиспользуем это в другой системе/проекте.
Мы ведь уже написали систему перемещения для ботов, давайте для игрока её тоже переиспользуем.
У нас ведь уже есть backend-сервис по обработке match-3 логики, давайте его же тупо используем в другой игре 😵
Может казаться, что нужно просто скопировать/вставить решения из одного места или создать общий класс.
И черт, это не работает нормально в большинстве случаев.
🔸 Если вы делаете что-то общее, то сначала нужно понять, какие зависимости это общее в себя принимает и отдаёт
Если вы сделаете прямой copy/paste, придётся писать кучу обёрток, чтобы подружить новую систему с текущей.
Поэтому чтобы действительно такое было возможно, нужно заранее проектировать не только саму систему абстрактно, но и её зависимости 🤯
А это значит, что нужно изначально планировать проектирование ключевых абстракций проекта.
Например:
🔹 Весь cross-cutting context. Логирование, конфиги, аналитика, обработка ошибок.
Либо придётся кучу мест рефакторить, либо заранее согласовывать единое API для переиспользования между проектами.
🔹 Коммуникация с сервером — пример посложнее.
Но суть простая: вы не хотите при переносе дублировать логику обработки ошибок, контрактов взаимодействия и тянуть лишние транзитивные зависимости (другой HTTP-плагин, например).
И это важно тупо потому, что это заставляет поддерживать задублированные решения по проекту 🤢
🔹 Изменился формат логирования или когда логи пишутся, а когда нет
🔹 Добавился новый обработчик исключений, формат контракта или обработка краевого случая
Вот иди свищи по проекту 10 копий и вкостыливай фикс и туда.
При этом ладно этот фикс в коде, ха, это ещё изи, а если ты решил общий микросервис такой выделить…
🔻Чем больше расстояние между зависимостями — тем сложнее и дороже в них вносить изменения.
🔸 Не всё, что кажется общим, таковым является
Избитый троп:
Ну тут сделаем абстрактно, чтобы другие системы, вдруг, взяли и переиспользовали эту логику.
Ну нет, это не работает.
Если заранее не понимать, как именно система будет переиспользоваться, и не переиспользовать сразу — оно не будет работать.
Это происходит из одного простого факта:
🔹 Скорость изменения требований разная для каждой из систем.
То, что вчера виделось как общее, сегодня жёстко заточено под что-то конкретное, т.к. переиспользуемость стоит времени, сил, денег и тщательного планирования.
Или по другому:
То что вчера казалось легко можно переиспользовать, сегодня требует узкого и конкретного решения.
Так что всё, пожалуйста, я снимаю со всех, кто читает этот пост, «проклятие переиспользуемости» 😘
С этого момента вы можете не писать системы так, чтобы вдруг когда-то их кто-то использовал и сократил себе время.
🔻 Наконец-то можно писать системы, которые заточены на выполнение своей задачи и не раздувают сложность проекта на ровном месте.
Но если переживаете, вот правило трёх:
Пока система или её часть не переиспользуется как минимум в трёх независимых местах — ничего общего выделять не нужно.
А если есть требование — выровняйте уровень знаний, покажите цену такого решения, сделайте #проектирование@UniArchitect, внедрите и пользуйтесь на здоровье, все только спасибо скажут.
Ставь 👍 если тебе заходит такого рода контент!
Ты знаешь кому переслать эту статью 💪
#проект_в_разработке@UniArchitect