Comments 18
1) Пример кода со стратегией непонятный (названия особенно) или неполный.
2) Я бы и с тремя вариантами оставил if-ы, если нет чётких требований/знаний, что в скором времени будут добавляться новые, и, главное, что это единственное место, где надо что-то менять при добавлении нового или изменении старого.
3) Ваш RUG это тот же KISS, только в профиль. Или старый философско-лонический принцип - не создавай сущностей сверх необходимого.
4) А SOLID там никак не упоминается? Устарел или как?
5) В жизни все так и делают. Для этого и существует такая штука как рефакторинг.
Этот пример слишком мал и недостаточно проработан, чтобы его объективно критиковать.
Три варианта можно оставить, но повторения делают код уже трудночитаемым (появился условные параметры).
Применение паттерна Strategy улучшит читаемость.Принцип KISS не поощряет дублирование — он говорит о необходимости упрощать код.
В каком контексте вы хотите применить принципы SOLID?
Согласен.
но повторения делают код уже трудночитаемым
Не увидел варианта без повторений.
Принцип KISS поощряет что угодно, если это делает код проще.
SOLID как часть чистого кода.
Я не приводил других примеров, потому что считал текущий достаточным. Возможно, добавлю ещё примеры позже.
RUG — это не про упрощение, а про то, чтобы позволить себе временные компромиссы, пока они не начнут негативно сказываться на коде.
SOLID — это не «чистый код». Почему?
Потому что Clean Code — это фундаментальный подход, применимый ко всем парадигмам программирования.
А SOLID — это специфический набор принципов, актуальный только для ООП.
Я говорил именно о чистом, понятном коде в целом, а не только об объектно-ориентированном.
Да, в примере используется ООП, но это не значит, что RUG должен обязательно сочетаться с SOLID.
RUG — независимый принцип.
Я реально рад что кто то прочитал и критикует. Спасибо вам)
На ранних этапах разработки важнее просто реализовать логику, исходя из текущих требований, чем пытаться сразу создать «идеальную» абстракцию.
Вам нужно видеть точки расширения вашего приложения и чем раньше вы их видите тем лучше. Программист с архитектурным мышлением лучше чем программист без него.
А драить, киссить и солидировать вы будете только на собеседовании, скорее всего)
Спасибо за объяснение и примеры, но в моей картине мира это выглядит по-другому.
RUG (Repeat Until Good) — это принцип, который говорит: улучшай код итеративно, пока он не станет достаточно хорошим для поставленных целей. Как прогрессивный JPEG.
То есть, наговнякай, чтобы работало хоть как-то, а потом доводи но нужного уровня хорошести.
Спасибо за объяснение и примеры — очень точно подмечено! Особенно понравилось сравнение с прогрессивным JPEG 😊
Можно сказать, что RUG как раз и подразумевает:
сначала сделай вещь, а потом — сделай правильную вещь, когда станет понятно, какой она должна быть.
>AlphaPay = 'ALPHA_PAY'
А вот эта гадость каким принципом оправдывает своё повторение? Терпеть не могу эту манеру дублировать содержимое в названии ключа в енамах, что за мода. Есть же нормальные поводы для выделения данных в переменные типа Pi = 3.14, DefaultId = 1 и подобное, где название объясняет содержимое. Есть нормальные енамы с автоинкрементом, где не надо вручную прописывать значения. Но это ни в какие рамки и нет смысла.
Во-первых, это явно просто пример.
Во-вторых, что именно не так с тем, чтобы сохранить нужный ключ и назвать его так же, как его значение?
Если мы используем это значение в нескольких местах и нам важно явно понимать, с чем мы работаем, разве не логично дать ему именно такое имя?
Ты хочешь сказать, что всё должно называться по-разному, лишь бы было "смыслово отличимо"?
Какой бы дал имя для разных шлюз платежей?
Использовать строковое значение вместо енамов, где они не нужны, пока не сделают "автоинкрементные" строковые енамы в самом языке, чтобы руками не писать дважды одно и то же.
>а потом значение изменится и заменять везде
Автозамена это раз, когда значение изменится, оно перестанет соответствовать названию ключа это два.
Конкретно вот эта практика просто бесит с запихиванием в енамы строк с названием самих себя, противоречие DRY.
Как правило, enum нужен для того, чтобы вынести какие то статусы, константные значения и т.п. Да, ты прав, что можно просто забить на значения и юзать авто-инкремент, НО, когда на проде видишь запись в поле статус 1,2,3,7,20... Как правило ты будешь материть человека, который это написал. Зачем мучить себя и других, когда язык позволяет писать более внятно и понятно, нежели скрывать значения под магическими значениями которые ты сможешь только по коду понять? Думаю есть кейсы когда можно использовать цифры, например Легаси код, где по какой то причине не юзали enum изначально, либо моменты оптимизации, но считаю, что читабельность > оптимизации.
DRY, KISS и YAGNI
А как же BOBODDY?
RUG — малоизвестный, но фундаментальный принцип Clean Code