Один из моих любимых примеров, который вспомнился недавно.
Есть операция refund, и с ней компания живет несколько лет. И вот приходит осознание и момент, когда появляется стойкое желание и необходимость, кроме возврата на всю сумму, совершать еще и частичные - partial refund! Но «мы же не будем смотреть в прошлое» и разбирать кто там был частичный, а кто полный, поэтому, рождается гениальная идея:
— А давайте просто добавим full_refund.
Он будет для всех в ком мы уверены, а странное и неполное оставим как refund. Ну а что? Работает же.
Потом проходит полгода… 3 года…
Все читают refund как “возврат”. Аналитики строят отчеты, разработчики пишут правила, саппорт ищет проблемы.
А потом внезапно выясняется, что refund вообще-то всегда означал частичный возврат — например, без комиссии. Полный возврат — это только full_refund. А в формуле расчета суммы на конкретный тип операций возврата была допущена ошибка, которая ВСЕГДА удерживала сумму комиссий.
И начинается увлекательная археология 💩
Чтобы стало еще веселее, в UI refund уже показывают как Partial refund, потому что пользователям так понятнее, а полный, как Refund (дизайнеры «экономили место»)! В базе одно название, в интерфейсе третье. Красота😍
Самое смешное, что обычно это происходит не потому, что кто-то плохо проектирует системы. Просто в какой-то момент всем становится лень делать миграцию и разбираться в исторических атавизмах.
А нейминг, как назло, запоминает эту лень на годы.
Поэтому если сущности/процессы бывают полными и частичными — называйте их симметрично сразу.
partial_refund
и
full_refund
намного скучнее. Зато потом никто не будет проводить раскопки в отчетах, а вас не буду пытаться этими же отчетами пристукнуть!
PS Когда ночью во время инца пытаешься понять по отчетам что там 😳, не только 3я рука вырастит!
💬А у вас какие любимые «парочки» в нейминге?