Чтобы делать хорошую пиццу (и не только) в сотнях заведений каждый день, нужно помогать нашим сотрудникам не отвлекаться на множество мелочей, которые сопровождают этот нелёгкий процесс. Мы решаем это через IT и маркетплейс приложений ускорит этот процесс.
StartAt — ’начинать в ’, по-человечески лучше в прошедшем времени. Или мы используем periodFrom, если это фильтр. Просто start для временного отрезка не самый удачный выбор. Да и без разницы фронтенд или бекенд —суффиксы нужны. Для методов REST есть описанные стандарты.
Идея статьи не в этом. Нет серебрянной пули, чего-то одного, что всё решит. Инженеру обязательно погружаться в предметную область. Хорошее знание языка сильно поможет, но не решит проблему с неймингом. И инструменты, как системно работать с неймингом, как продавать эту идею, как поддерживать.
По поводу number уже ответили дельно, это специфичное слово, лучше его как «суффикс» не использовать. По поводу множественного числа, пусть вас не смущает. Например в наименованиях путей в REST очень рекомендуется использовать множественное число: /shops/{id}. Что и в случае с REST, когда у нас есть «каталог» с сущностями, так же и с массивом, который содержит сущности, действует принцип вложенности и отражается в наименованиях.
Спасибо, что поделились. Я искал подобные статьи, но слово «именования» для поиска не использовал, поэтому статью не видел. Вот такая ирония про нейминг.
Замечание справедливое, но мы так сознательно сделали. Во всём API возвращаем TimeSpan в секундах и пишем этот момент везде в спецификациях. Внутри системы мы оперируем типом TimeSpan.
В статье тоже говорю про это «если идёт тяжело — погрузитесь сильнее, узнайте больше деталей». Возможно стоит отложить принятие финальных решений. По поводу «следа». Если на проекте недавно, то, конечно, лучше продолжать делать как было. Но при должном погружении, к сожалению, видишь, что никакой глубокой мысли не было. Системная работа с неймингом сразу бросается в глаза.
Возможно вы знаете секрет как мотивировать иностранца купить франшизу, вложить средства в открытия ресторанов и при этом в обязательном порядке выучить русский. И вроде хочется начать, но не знаю с чего.
Вы всё правильно понимаете. Есть ставка почасовая. Ночью или в праздничные дни применяется повышенный коэффициент, на который умножается ставка. Например коэффициент ночью = 1.2 Да, английский контекстный. Домены помогают однозначно понимать такую терминологию. RatePerHour находится внутри домена Incentives.
Извините, но это ложная альтернатива: «не учат язык = считают нас хуже». До 20 века международным языком был французский, сейчас английский. Нашим разработчикам приходилось читать инструкции по немецки, когда нужно было интегрироваться с немецкими системами оплаты. Было больно, без претензий к немецкому. Просто даже второй язык выучить не то, чтобы просто.
Называй понятно, но как этого добиться? В этом и есть сложность, про это и есть статья. Чтобы было понятно даже бабушке, нужно опереться на какую-то систему, которая уже существует. Изобретение собственных велосипедов, как правило, помогает обогнуть какую-то локальную «неровность» с названиями, но не построить процесс на сотни человек. Переменные — это про код. Нейминг — шире: код, документация, аналитика, тест-кейсы, события и тд.
Если условия позволяют и всем удобно, можно принять за правило и транслит. Однако мы используем языки и фреймворки, паттерны, термины, которые не принято переводить. Транслитерация тоже по-своему сложна. Я вроде Arsenii по правилам транслитерации, но никогда так своё имя не писал. И всё это вносит неопределённость вместо пользы. А ещё и воспринимается иначе: vykladka vs deployment. Тут же остаётся добавить, что мы читаем документации, статьи, книги на английском (их существенно больше, чем на русском и они свежее). А ещё open source, где с таким подходом не пройдёшь ревью. Идеальные переводы как недостижимый идеал. Но это не значит, что не стоит к этому стремиться. Это тоже часть порядка. И я бы даже сказал, что единство терминологии > точность перевода.
Практику разделения проекта на домены применяете? Чтобы для каждого свой словарик составлять. В масштабах большого проекта и словарь поддерживать тяжело и разработчики начинают специализироваться больше на каком-то одном участке.
Не исключено, что вы шарите лучше. Тем не менее premiums был совершенно сознательно выбран. В плане транслита — плохо масштабируется. Прочувствовать подобный опыт можно, если читать на турецком, например. Такие слова даже запомнить тяжело, что уже говорить о том, чтобы не опечататься или использовать их в коммуникации. Хотя вроде латиница.
Чтобы делать хорошую пиццу (и не только) в сотнях заведений каждый день, нужно помогать нашим сотрудникам не отвлекаться на множество мелочей, которые сопровождают этот нелёгкий процесс. Мы решаем это через IT и маркетплейс приложений ускорит этот процесс.
Маркетплейс и приложения в нём как раз нужны, чтобы пиццы становилось больше)
Очень рад, что вам пригодилось!
StartAt — ’начинать в ’, по-человечески лучше в прошедшем времени. Или мы используем periodFrom, если это фильтр. Просто start для временного отрезка не самый удачный выбор. Да и без разницы фронтенд или бекенд —суффиксы нужны.
Для методов REST есть описанные стандарты.
У китайского языка очень сильное ограничение — нет алфавита.
Идея статьи не в этом. Нет серебрянной пули, чего-то одного, что всё решит. Инженеру обязательно погружаться в предметную область. Хорошее знание языка сильно поможет, но не решит проблему с неймингом. И инструменты, как системно работать с неймингом, как продавать эту идею, как поддерживать.
По поводу number уже ответили дельно, это специфичное слово, лучше его как «суффикс» не использовать.
По поводу множественного числа, пусть вас не смущает. Например в наименованиях путей в REST очень рекомендуется использовать множественное число: /shops/{id}. Что и в случае с REST, когда у нас есть «каталог» с сущностями, так же и с массивом, который содержит сущности, действует принцип вложенности и отражается в наименованиях.
Спасибо, что поделились. Я искал подобные статьи, но слово «именования» для поиска не использовал, поэтому статью не видел. Вот такая ирония про нейминг.
Тоже так делаем. Если в объекте есть несколько идентификаторов и имён, то лучше добавить контекста.
Замечание справедливое, но мы так сознательно сделали. Во всём API возвращаем TimeSpan в секундах и пишем этот момент везде в спецификациях. Внутри системы мы оперируем типом TimeSpan.
В статье тоже говорю про это «если идёт тяжело — погрузитесь сильнее, узнайте больше деталей». Возможно стоит отложить принятие финальных решений.
По поводу «следа». Если на проекте недавно, то, конечно, лучше продолжать делать как было. Но при должном погружении, к сожалению, видишь, что никакой глубокой мысли не было. Системная работа с неймингом сразу бросается в глаза.
Возможно вы знаете секрет как мотивировать иностранца купить франшизу, вложить средства в открытия ресторанов и при этом в обязательном порядке выучить русский. И вроде хочется начать, но не знаю с чего.
Вы всё правильно понимаете. Есть ставка почасовая. Ночью или в праздничные дни применяется повышенный коэффициент, на который умножается ставка. Например коэффициент ночью = 1.2
Да, английский контекстный. Домены помогают однозначно понимать такую терминологию. RatePerHour находится внутри домена Incentives.
Извините, но это ложная альтернатива: «не учат язык = считают нас хуже».
До 20 века международным языком был французский, сейчас английский. Нашим разработчикам приходилось читать инструкции по немецки, когда нужно было интегрироваться с немецкими системами оплаты. Было больно, без претензий к немецкому. Просто даже второй язык выучить не то, чтобы просто.
Вы встречали когда-нибудь «промежуточный коэффициент, по которому начисляется зарплата»? Возможно я не в курсе, что такое существует.
Называй понятно, но как этого добиться? В этом и есть сложность, про это и есть статья. Чтобы было понятно даже бабушке, нужно опереться на какую-то систему, которая уже существует. Изобретение собственных велосипедов, как правило, помогает обогнуть какую-то локальную «неровность» с названиями, но не построить процесс на сотни человек.
Переменные — это про код. Нейминг — шире: код, документация, аналитика, тест-кейсы, события и тд.
Если условия позволяют и всем удобно, можно принять за правило и транслит.
Однако мы используем языки и фреймворки, паттерны, термины, которые не принято переводить. Транслитерация тоже по-своему сложна. Я вроде Arsenii по правилам транслитерации, но никогда так своё имя не писал. И всё это вносит неопределённость вместо пользы. А ещё и воспринимается иначе: vykladka vs deployment. Тут же остаётся добавить, что мы читаем документации, статьи, книги на английском (их существенно больше, чем на русском и они свежее). А ещё open source, где с таким подходом не пройдёшь ревью.
Идеальные переводы как недостижимый идеал. Но это не значит, что не стоит к этому стремиться. Это тоже часть порядка. И я бы даже сказал, что единство терминологии > точность перевода.
Практику разделения проекта на домены применяете? Чтобы для каждого свой словарик составлять. В масштабах большого проекта и словарь поддерживать тяжело и разработчики начинают специализироваться больше на каком-то одном участке.
основной файл стилей назывался temporary_new.css
Не исключено, что вы шарите лучше. Тем не менее premiums был совершенно сознательно выбран.
В плане транслита — плохо масштабируется. Прочувствовать подобный опыт можно, если читать на турецком, например. Такие слова даже запомнить тяжело, что уже говорить о том, чтобы не опечататься или использовать их в коммуникации. Хотя вроде латиница.