tgoop.com/itextrapolation/724
Last Update:
Попробую публично апеллировать Вове Рожкову и его мысли, что названия фундаментальных штук, вроде микросервисов должны быть максимально понятными по содержанию и не нужно придумывать красивых новых слов для всего подряд. Вова называет такие названия «кринжовыми» и избегает их.
Безусловно, название должно отражать суть происходящего, это даже не обсуждается. А придумывать новые слова или новые значения нужно для тех штук, которым нет удобного слова или словосочетания. Например, был себе джаваскрипт такой, существовал, а потом у него появилась особого вида функция, которая асинхронно вызывает другую функцию. Ну есть же термин «функция высшего порядка» там, а у нас тут асинхронный вызов функций. Ну назови ты её «async higher-order function» и всё. Зачем же придумывать для неё отдельное слово «Promise»? Но вот придумали, потому что этот вот промис планировался, как особого вида функция и что это не просто «async higher-order function».
А дело в том, что так в человеческих языках и придумываются новые слова и новые значения. Для тех штук, которые долго объяснять по сути и длинно читать по составу люди находят красивые и лаконичные слова, чтобы быстро коммуницировать друг с другом. Конечно, важно не придумывать искусственный язык, чтобы заставлять на нём всех общаться, а идти на поводу у естесственного общения и придумывать названия для папочек и репозиториев такие, какими их называют люди между собой.
В одном проекте мы назвали сущность, которую пользователь через интерфейс запрашивал у менеджера и заполнял поля «Request». Вроде бы логично, пока не оказалось, что в фреймворке был баг и в некоторых случаях глобально доступная переменная внутри языка шаблонов «request» возвращала экземпляр http-запроса, а не нашу локальную переменную request = Request.find(params[:id]). Пришлось придумывать синоним Demand и менять внутреннюю терминологию. Для душнил уточню, что в интерфейсе для пользователя, конечно же, остался request 🙂 С тех пор я стараюсь избегать общих терминов и слов, которые можно было бы трактовать двояко.
В другом проекте было несколько ролей пользователя со своими интерфейсами. Ну, скажем, ORM-модели назывались стандартно User, Project и Company, а вот неймспейсы для каждого пользователя тогдашний архитектор назвал Egg, Chicken и Ranch, подразумевая, что в Ranch можно создать себе Chicken, а в курице — яйцо. Преимущество перед UserApp было огромным, потому как поиск файлов с префиксом egg прятал то, чего не хотелось видеть. Да и интуитивно понятно что из себя представляло каждое из приложений.
А третий пример про особого вида микросервисы в ещё одном проекте, где мы себе придумали такие микросервисы, которых и пристрелить было не жалко и запускать можно было бы когда угодно. Ну, умирали они часто, ну и хрен бы с ними. Там и другие микросервисы были разные, важные и ответственные, но вот эти вот были на особом счету и с особой структурой работы с ними. Назвали мы их сначала «быстродохнущими микросервисами», а потом кто-то назвал их «Леммингами» и оно прижилось так хорошо, что стало префиксом в названии каждого такого микросервиса. Ну, там «lemming_auto_subscription» или «lemming_story_history».
Короче, нельзя придумывать названия просто так. Этимология любого названия обязательно должна быть.
BY Экстраполяция IT
Share with your friend now:
tgoop.com/itextrapolation/724