День 1376. Остановим Овер-Инжиниринг ПО Можем ли мы, как разработчики приложений, перестать овер-инжинерить ПО? Все мы когда-либо это делали. Вот некоторые из ловушек, в которые мы попадаемся, что приводит к овер-инжинирингу. 1. «Что, если» Мы делаем предположения о предметной области. Проблема в том, что мы не подтверждаем их, а они могут быть неверными. Мы обнаруживаем пограничный случай, который, нам кажется, нужно решить в коде. На самом деле это происходит настолько редко, что бизнесу не нужно это автоматизировать. Об этом проще уведомить и исправить вручную. Подтвердите предположения и поговорите с бизнесом! Не пишите сложный код, когда в этом нет необходимости. 2. Излишняя забота о технологии Разработчики любят новые крутые библиотеки, фреймворки и инструменты. Мы можем упустить из виду, зачем вообще пишем код. Мы решаем бизнес-задачи и создаём ценность. Хорошо быть в курсе новейших технологий, чтобы улучшать наши системы. Но мы должны уделять такое же внимание домену, в котором мы работаем. Используйте технологию, которая лучше всего решает проблему. 3. Изобретение велосипедов Вам случалось работать над системой, где был свой кастомный фреймворк, ORM и т.п.? Скорее всего да. Он было документирован? Скорее всего нет. Обычно доморощенный фреймворк много лет назад написал кто-то, кто больше не работает в компании, а теперь застряли с ним вы. Мы любим технологии, но всё, что вы добавляете, — это сложность. Хорошим примером является написание собственной библиотеки обмена сообщениями вместо RabbitMQ/AWS SQS/Azure ServiceBus. Люди часто делают это, не осознавая всей сложности, которую нужно реализовать. Вместо этого используйте проверенную на практике библиотеку. Купите готовое, а не усложняйте систему. 4. Недостаток изначального проектирования Недостаточное понимание предметной области приводит к созданию чрезмерно сложной системы. Это вариант игры «что, если». «Что, если нам нужно сделать X» или «Что, если X изменится, давайте добавим Y». Вам это не понадобится. Не обязательно надолго садиться за проектирование. Исследуйте предметную область, особенно в проекте с нуля, используя что-то простое, например, Event storming. Нужно понять рабочие процессы и различные точки зрения разных людей в бизнесе. 5. DRY без границ Отличным примером того, что DRY ушёл не туда, является то, что вещи становятся слишком абстрактными, пытаясь приспособиться под различные варианты использования, что в итоге приводит к огромной сложности. Например, Службы сущностей (Entity Services). ProductService в системе склада, который содержит всю информацию о продукте: название, цена, стоимость, количество в наличии и т.д. Проблема в том, понятие продукта на складе существует в нескольких разных контекстах. Отдел продаж волнует цена продажи, закупку волнует стоимость, доставку - количество в наличии. Не существует единой сущности продукта, каждый контекст будет иметь свою концепцию, раскрывающую функциональные возможности и данные, которые имеют к ней отношение. 6. Чрезмерная абстракция Кажется типичным желание абстрагироваться от сторонней зависимости, библиотеки или инструмента. На первый взгляд это имеет смысл, и вы создаете свою абстракцию, чтобы код вашего приложения зависел от неё, а не от сторонней утилиты. И если вам когда-нибудь понадобится изменить её, то не придётся менять весь код приложения. Звучит разумно? Однако всё сводится к связанности и управлению ей. Смысл абстракции в том, чтобы упростить базовые концепции, наиболее подходящие для вашего варианта использования. Создание абстракции ограничит вашу способность использовать все возможности, которые зависимость может предложить. Управляйте связанностью! Вертикальные слои и фокус на функционале. Группировка функций по функционалу позволит сузить фокус и принимать локальные решения о том, какие зависимости требуются для каждого функционала. Источник: https://codeopinion.com/stop-over-engineering-software/