Comments 11
Мне кажется проблема надумана и вытекает из того, что автор пытается совместить название и описание в одной сущности.
Как представлю Git clone для С проекта с названием 'Multiplier Façade' и его сборку с использованием make - так дрожь пробирает. UTF-8 до сих пор не везде, а разный регистр и пробелы в именах - это верный способ запутаться. Одна система позволяет пробелы в именах, другой надо дефисы, а третья - только подчеркивания, как разделители.
А если серьезно, здравый смысл никто не отменял. И Domain-Driven Development нам в помощь. Говорим об крупно масштабной архитектуре - используем функциональные имена, выделили сферы ответственности, назначили исполнителей, сопоставили функционал и декомпозицию, проекты и репозитории уже допустимо обозначать короткими именами, аббревиатурами и сокращениями, спускаемся еще ниже и внутри команды разработки компоненты создали внутреннюю утилиту для локальных нужд - хоть в карту Швеции тыкаем, и, как Икея, имя выбираем. Все равно эта утилита сдохнет, когда автор перейдет в другую компанию.
Вот надо отрендерить пдф: как назвать сервис? Я назвал его rtpsrs. Понятно ли это название? Не думаю. Сделать его читаемым? Не выйдет. Потому что пдф сервисов уже 3 или 5 есть для разных задач. А уместить всеописаниевназваниесервисабудетудобновкоде?
Духота какая-то: ну добавь пару строк в description репы, зато насколько приятнее обсуждать будет, что Танос завис, или Hitman прибил лишний кластер)
Про подход к неймингу еще в "Совершенном Коде" Стива Макдоннелла было расписано подробно.
Анекдот на тему.
Во время разработки ОС ДИСПАК в проекте были строгие правила создания идентификаторов (максимум 6 заглавных русских букв). Таблица управляющих символов — ТУС, главный управляющий символ — ГУС, и т.д. Молодежь подсуетилась и создала объект, который по всем правилам получил идентификатор ЖПЧШЦ. Все было хорошо, но потом Тюрин увидел это...
Согласен, что наименование должно отражать область ответственности и быть унифицированным.
Кроме funny-naming есть и другие варианты сделать плохо.
Например, называть всё "одинаково". При этом IntMultiplier будет состоять из InputUtility, QueuingUtility (с очередями, ведь, работает), NumberUtility и ResponseUtility.
Или называть всё "беспорядочно". Когда название отдельно взятой компоненты вроде бы нормальное, но разные компоненты названы по разным принципам.
Между этими двумя одинаково непонятными крайностями есть куда более разумный подход: использование уже существующих у человека ассоциаций для упрощения понимания что за что отвечает. Например:
Супермен - супервизор, который всеми управляет
Спайдермен - краулер веб страниц для индексирования
Постмен - рассылает почту
Флешмен - рассылает нотификации
Айронмен - управляет железками
Бэтмен - помогает расследовать инциденты
Иксмен - соединяет микросервисы единой шиной сообщений
а что на счёт обратной ситуации, вы назвали сущность Хлеборезка, а затем к ней вынужденно прикрутили функционал колки дров. Мне по душе веселые имена потому, что они побуждают заглянуть в доки сущности. Хотя конечно нужно подходить сбалансировано
Записки архитектора. Как давать имена приложениям и сервисам