Всё верно. Мы выбрали максимально общее incentives, потому что это агрегат, внутри которого есть wages, premiums и прочее. Пока отправляем весь нейминг на ревью нашим международным бизнес-девелоперам, которые шарят что там как именуется правильно (уточню, что пока это касается внешних API и новых проектов). Очень важен контекст, просто сторонний переводчик может не так перевести. И вот имея накопленный словарь уже можем смелее сами орудовать терминами. Так что да, это сложно и научить каждого разработчика так переводить не получится. Нужно находить возможность построить такой процесс внутри организации.
Мы называем зарплатой всё, любой вид вознаграждений. Десятилетия социализма отразились в нашем языке. В то время как в английском salary — это фиксированное ежемесячное вознаграждение за умственный труд. У таксиста не может быть salary и у рабочего на заводе тоже.
С такой стороны я на свой текст не смотрел. Действительно, выразительные средства языка можно использовать лучше. Хотя отсылка к песне Любэ здесь чуть меньше подходит, на мой взгляд. У русского языка мощная система, она переваривает в себе любые заимствования. Как и любой другой язык он живёт и развивается. Когда-то кандидат филологических наук посоветовал мне не переживать по поводу неуместного употребления слова «одел». Если так удобно, то люди так будут говорить и станет это нормой в языке. Возможно и «суржик» так же приживётся. Заимствованные слова — это ведь не всегда аналоги ещё. Многих терминов в нашем языке просто нет. Или они обозначают что-то похожее, но не в точности то же самое.
Ходить в крестовые походы и спорить у кого культура правильная — дело сугубо личное. Можно одно и то же явление рассматривать и как результат эмансипации и как «расчеловечивания». Вопрос этики в разработке интересный. Кто-то делает онлайн-казино, кто-то бы не стал бы. Возможно вопрос нейтральности для вас принципиальный.
Да, хочется лаконичности. Но это не всегда возможно. Например, когда у вас контракт, состоящий из очень разных метрик. Тогда нужно тащить в нейминге весь контекст этой метрики.
Отлично! Через нейминг увидели, что домен несовершенно спроектирован. А история там такая, что сначала в енуме было 2 значения, а потом, в одной стране потребовалось выделить велосипедистов отдельно.
Неоднократно было: формализуешь бизнес-процесс и оказывается, что проблема решается менеджментом. Сам факт того, что к тебе приходят «сделайте нам конкретно это» должен вызывать подозрение.
Да, такой вариант тоже корректен. Но «рабочие часы» больше нам подходят, культура компании такова, что «человекочасы» коробят, так не говорим. Про американский английский крутое замечание!
Перевод бизнес терминологии — это не базовый английский. Софт для бухгалтерий в СНГ пишется на русском. И это ок, потому что слишком специфичен, такой софт сложно адаптировать под другие регионы не только из-за правовых особенностей, но и из-за особенностей рынков, где доминируют другие платформы.
Обращу внимание, что статья говорит не только про аккуратность в нейминге. Изменить нейминг через горячие клавиши далеко не всегда удастся. Представьте, что с вашим API взаимодействуют сотни внешних систем. Да даже если десяток — уже сложно. А если одну и ту же переменную использовали для разных целей, потому что не поняли её предназначение? Избыточные процессы мешают. Но бывает, что проблема в том, что люди выполняют какие-то действия не понимая, для чего это нужно. Статья как раз доносит, почему важно вкладываться в нейминг. Это совсем не nice to have история. По поводу проверки бизнес-логики во время ревью. Это не лишнее, но, всё же, лучше отладить процессы тестирования. И посмотреть в сторону пирамиды тестирования, где есть не только юнит-тесты.
Синхронно = голосом. Например, если проводить ревью и оставлять комменты в гитхабе, то это может сильно затянуться. Для того, чей код ревьюят, это выматывающая история, когда в PR раз за разом прилетают уточнения или он не понимает, что от него хотят. Если замечаний по неймингу много или есть сложные моменты, лучше обсудить голосом, возможно сразу добавить в словарик что-то новое. Опыт показал, что текстом всё идёт долго и процесс начинает казаться мешающей формальностью. После того, как команда научится, словарик составится, будет проще.
Было бы логично, если продукт никогда не будет выходить в другие страны. У нас сейчас 17 стран и в этих странах разработчики (которые пользуются API например) — они совсем не знают русский.
С опытом чувствуешь баланс длина/понятность. Но, пока опыта нет, предпочтительнее длинно, чем непонятно.
Всё верно. Мы выбрали максимально общее incentives, потому что это агрегат, внутри которого есть wages, premiums и прочее.
Пока отправляем весь нейминг на ревью нашим международным бизнес-девелоперам, которые шарят что там как именуется правильно (уточню, что пока это касается внешних API и новых проектов). Очень важен контекст, просто сторонний переводчик может не так перевести. И вот имея накопленный словарь уже можем смелее сами орудовать терминами. Так что да, это сложно и научить каждого разработчика так переводить не получится. Нужно находить возможность построить такой процесс внутри организации.
Мы называем зарплатой всё, любой вид вознаграждений. Десятилетия социализма отразились в нашем языке. В то время как в английском salary — это фиксированное ежемесячное вознаграждение за умственный труд. У таксиста не может быть salary и у рабочего на заводе тоже.
С такой стороны я на свой текст не смотрел. Действительно, выразительные средства языка можно использовать лучше. Хотя отсылка к песне Любэ здесь чуть меньше подходит, на мой взгляд. У русского языка мощная система, она переваривает в себе любые заимствования. Как и любой другой язык он живёт и развивается. Когда-то кандидат филологических наук посоветовал мне не переживать по поводу неуместного употребления слова «одел». Если так удобно, то люди так будут говорить и станет это нормой в языке. Возможно и «суржик» так же приживётся. Заимствованные слова — это ведь не всегда аналоги ещё. Многих терминов в нашем языке просто нет. Или они обозначают что-то похожее, но не в точности то же самое.
Ходить в крестовые походы и спорить у кого культура правильная — дело сугубо личное. Можно одно и то же явление рассматривать и как результат эмансипации и как «расчеловечивания». Вопрос этики в разработке интересный. Кто-то делает онлайн-казино, кто-то бы не стал бы. Возможно вопрос нейтральности для вас принципиальный.
За пожелание спасибо. Но запрошу конкретику:
что конкретно вызывает коробление?
как бы это звучало красиво?
Для бизнеса в другой культурной среде это может быть критично
Да, хочется лаконичности. Но это не всегда возможно. Например, когда у вас контракт, состоящий из очень разных метрик. Тогда нужно тащить в нейминге весь контекст этой метрики.
Отлично! Через нейминг увидели, что домен несовершенно спроектирован.
А история там такая, что сначала в енуме было 2 значения, а потом, в одной стране потребовалось выделить велосипедистов отдельно.
В статье есть такой пример - зарплата. Переведёте это как salary и будет ошибка.
Неоднократно было: формализуешь бизнес-процесс и оказывается, что проблема решается менеджментом. Сам факт того, что к тебе приходят «сделайте нам конкретно это» должен вызывать подозрение.
Да, такой вариант тоже корректен. Но «рабочие часы» больше нам подходят, культура компании такова, что «человекочасы» коробят, так не говорим.
Про американский английский крутое замечание!
Перевод бизнес терминологии — это не базовый английский.
Софт для бухгалтерий в СНГ пишется на русском. И это ок, потому что слишком специфичен, такой софт сложно адаптировать под другие регионы не только из-за правовых особенностей, но и из-за особенностей рынков, где доминируют другие платформы.
Обращу внимание, что статья говорит не только про аккуратность в нейминге. Изменить нейминг через горячие клавиши далеко не всегда удастся. Представьте, что с вашим API взаимодействуют сотни внешних систем. Да даже если десяток — уже сложно. А если одну и ту же переменную использовали для разных целей, потому что не поняли её предназначение?
Избыточные процессы мешают. Но бывает, что проблема в том, что люди выполняют какие-то действия не понимая, для чего это нужно. Статья как раз доносит, почему важно вкладываться в нейминг. Это совсем не nice to have история.
По поводу проверки бизнес-логики во время ревью. Это не лишнее, но, всё же, лучше отладить процессы тестирования. И посмотреть в сторону пирамиды тестирования, где есть не только юнит-тесты.
Синхронно = голосом. Например, если проводить ревью и оставлять комменты в гитхабе, то это может сильно затянуться. Для того, чей код ревьюят, это выматывающая история, когда в PR раз за разом прилетают уточнения или он не понимает, что от него хотят. Если замечаний по неймингу много или есть сложные моменты, лучше обсудить голосом, возможно сразу добавить в словарик что-то новое. Опыт показал, что текстом всё идёт долго и процесс начинает казаться мешающей формальностью. После того, как команда научится, словарик составится, будет проще.
Было бы логично, если продукт никогда не будет выходить в другие страны. У нас сейчас 17 стран и в этих странах разработчики (которые пользуются API например) — они совсем не знают русский.