Антипатерн проектирования: оракул
Абстракция как универсальный ответ на любой вопрос
Есть ли жизнь на марсе или нет жизни на марсе, нам доподлинно неизвестно, поэтому давайте сформируем абстрактную фабрику
Третьего дня я написал небольшую статью про антипатерн который часто встречаю, предложил исправление. Обсуждение в комментариях к статье подняли в моей памяти одну тему, которую я бы хотел предложить к обсуждению тут. Почему разработчик хочет предсказать будущее, к нему подготовиться в виде дизайна абстракций.
Давайте начнем с терминов, к которым я буду обращаться:
- аргумент
- понятие , оно не хорошее и не плохое, а как же канатация?
- спекуляция
И дальше наше воображение начинает строить замысловатые картины будущего - новые требования функционального и не функционального характера, повышения частоты запросов к сервису, нерадивые коллеги и все в этом духе. И почему то я часто вижу, что ответом на такой ментальный вызов для программистов является попытка сделать дизайн таким образом, чтобы всем этим требованиям удовлетворить сейчас: написать абстракции, построить дизайн под возможные изменения брокера сообщений, абстрагировать от всего. Но разве нет тут ошибки суждения? Почему, во первых, разработчик думает что все это будет? Во вторых, почему он думает что они будут именно такими? В третьих, если требования будут такими как он предположил, почему он думает что его абстракции окажутся верными? А если верными, то почему бизнес сегодн должен платить за то, что сегодня не нужно, а нужно через год?
Так многое может пойти не так и в моем понимании, все эти суждения лишь спекуляции. И вот почему.
Разумно считать, что код должен быть поддерживаемым, тестируемым и тд.
Чистая функция лучше не чистой Стейтлес лучше чем стейтыул Без базы лучше чем с базой
Если можно код не писать, то лучше не писать.
У всего должно быть обоснование