В чём разница между сочинением третьеклассника и статьёй в крупном таблоиде? Любой из нас сходу определит, что есть что. Даже если оба текста описывают одно и то же событие. А чем отличается код сеньора от кода мидла?
Разница в мелочах. В мелочах, которые при взгляде сверху дают совершенно другую картину. Лид статьи от профессионального редактора притянет внимание, структура и ход повествования доведут нас до последнего абзаца. Наш взгляд не споткнётся, мы буквально пролетим по тексту, улавливая суть каждого предложения. Так же и код сеньора нам покажется незамысловатым, словно прописные истины. Мы почти не приложим усилий, чтобы понять его. Невозможно написать качественный, читаемый, поддерживаемый код без навыка давать хороший нейминг.
Нейминг — часть архитектурной работы. Наименования классов и переменных мигрируют в названия таблиц баз данных, улетают с событиями, проникают в другие системы через API. Проще сменить имя в паспорте, чем исправить контракт, который имеет тысячи использований. Ошибки в нейминге быстро масштабируются, увеличивая сложность системы на ровном месте. Зачастую их исправление стоит колоссальных усилий и средств. Не стоит забывать про документацию, тест-кейсы, аналитику.
Что касается самого кода, то это отражение того, как мы поняли предметную область. Понимание предметной области, её задач и проработка решений — это то, что делает инженер в IT. Чтобы отразить предметную область, мы используем нейминг, даже если специально об этом не задумываемся.
Одной из проблем нейминга является непонимание, почему это так важно. В статье мы посмотрим на то, к чему приводит отсутствие системы нейминга и какие выгоды мы приобретаем, если в проекте построен процесс работы с ним.
Второй проблемой является отсутствие под рукой лёгких инструментов, чтобы быстро и понятно называть, каких-то простых приёмов. И в этой статье я поделюсь такими приёмами. Здесь не будет очередной теории нейминга, которую нужно разбирать и доносить до коллег. Я описываю простой процесс, позволяющий одинаково понимать домен, а все инструменты вы сможете использовать сразу же после прочтения. Их эффективность оказалась для меня поразительной — надеюсь, вы испытаете те же чувства, когда примените в своей команде.
Распространённые ошибки
Возможно, вы встречали подобные подборки ошибок в книгах и статьях. Этот список по-своему уникален тем, что специфичен для разработчиков, у которых английский не является родным языком.
Название переменной ничего не говорит о её предназначении
let data = {} // FIXME rename to requestPayload
let n = 1; // FIXME rename to startIndex
let var1 = "Something"; // FIXME rename to eventName
let value = {...data}; // FIXME rename to user
let array = [var1]; // FIXME rename to firedEvents
let info = var1 + " happened"; // FIXME rename to alertMessageПеременная — это какие-то данные, какое-то значение, но не стоит её так и называть. Конкретизируйте. Что за значение мы хотим в ней хранить? Так и назовём переменную. Даже если мы пишем дженерик, то можно дать более конкретное название.
Избыточные названия
const addedDateTime = new DateTime(); // FIXME rename to addedAt
const basket = {
basketId: 0, // FIXME rename to id
items: []
}В название добавляется тип переменной или избыточный префикс названия объекта. В итоге мы читаем код как «добавлено дата время» или «корзина — айди корзины». Код должен читаться без таких запинок «добавлено в 12:00», «корзина: айди: 4, элементы: […]».
Названия без контекста
const user = {
id: 11,
source: "linkedin", // FIXME rename to leadSource
state: "Philadelphia", // FIXME rename to countryState
status: "unemployed" // FIXME rename to employmentStatus
}Только благодаря значениям мы поняли, что за source имеется в виду, в каком смысле употреблены state, status. Без значений всё усложняется — придётся отвлекаться и уточнять, о чём идёт речь.
Неправильный перевод
public enum TravelMode // FIXME rename to TransportType
{
Driving = 0, // FIXME rename to Vehicle
Walking = 1, // FIXME rename to OnFoot
Bicycling = 2 // FIXME rename to Bicycle
}Часто одни и те же термины имеют разное происхождение в разных языках. Мы, русскоязычные, сможем догадаться, что это особенности перевода, что речь идёт о том, как курьер доставляет заказ. Но носитель другого языка, с большой вероятностью, окажется в тупике.
Калька со своего языка
var orderHandoverTime = {
preparationTime: 651, // FIXME rename to cookingTime
heatedShelfTime: 30,
pizzeriaId: 3, // FIXME rename to unitId
}
var staffMember = {
id: 52,
medicalBookEnd: false, // FIXME rename to isHealthPermitExpired
INN: "" // FIXME rename to taxIdentificationNumber
}
var employeeDinner; // FIXME rename to staffMeal
var salary; // FIXME rename to incentivesИногда в русском одно и то же слово может обозначать разные объекты или действия, но в английском нет. Более того, некоторые заимствованные слова обрели разный смысл. Самым популярным примером может быть пара магазин — magazine. Смысл слов совпадает, если мы говорим про магазин к винтовке, но магазин с товарами мы уже переведём как shop (здесь стоит отметить, что magazine является заимствованием для обоих языков).
В примере разработчик перевёл «приготовление» как preparation, хотя речь о готовке еды. Ошибки можно избежать, если подобрать синонимы. Более специфичное слово «готовка» показало бы точный перевод.
Отдельной темой стоит бизнесовая или нишевая терминология, перевод которой совсем не прост. Гугл-транслейт, с большой вероятностью, приведёт нас не к тем переводам. Например, то, что мы называем «зарплата», в других странах даже формулируется иначе. В общем случае это «вознаграждения».
В примере есть и более прямолинейные случаи перевода. Естественно, медкнижка — это исключительно русскоязычный термин.
Недостаточно точный термин
var avgWaitingTime = 2000; // FIXME rename to avgHeatedShelfTime
var avgServiceTime = 5000; // FIXME rename to avgDeliveryOrderFulfillmentTime
var avgDeveliryTime = 3000; // FIXME rename to avgOrderTripTime
var orderType: "restaurant" // FIXME rename to salesChannel
// also rename "restaurant" to "Dine-in"Здесь мы видим неудачный нейминг в области с метриками времени у доставки заказов. В каждой строке возникают уточняющие вопросы «время ожидания чего?», «в какой момент отсчёт этого времени начался и в какой закончился?», «сервисное время? что имелось в виду?», «доставка — это от момента приёма заказа или от момента его готовности?». Такой нейминг порождает баги. Не все дотошно выясняют точное назначение каждой переменной.
Как правило, такой нейминг возникает от низкой погружённости в предметную область. Все мелкие нюансы выясняет инженер: от какого момента считать время на тепловой полке, от какого момента считается время доставки и тд.
Отдельный разговор про orderType. Один и тот же объект можно характеризовать с разных сторон. Заказ может быть отложенный или требующий немедленного приготовления, может быть отменённый или доставленный вовремя. Type может обозначать что угодно, лучше конкретизировать.
Абстрактные названия
var unitDeliveryEfficiency = {
onePerTaskRate: 2, // FIXME rename to tripsWithOneOrderCount
twoPerTaskRate: 4, // FIXME rename to tripsWithTwoOrdersCount
threePerTaskRate: 0, // FIXME rename to tripsWithThreeOrdersCount
fourPerTaskRate: 1, // FIXME rename to tripsWithFourOrdersCount
morePerTaskRate: 0 // FIXME rename to tripsWithFiveOrMoreOrdersCount
}По названию свойств сложно догадаться, о чём идёт речь. Почему бы не назвать свойства именем метрики, которую они несут? Не нужно придумывать лишние обозначения, которые не применяются в реальной жизни.
Но проблемный нейминг создал здесь ещё один прецедент — внимание на последнее свойство в объекте. Мы решили группировать те редкие случаи, когда курьер берёт более 4 заказов в одну поездку. Если чуть-чуть изменить наши правила, например, добавить поездки с 5 заказами, то все метрики поедут. А такую ошибку совершить очень просто, ведь название свойства ни к чему не привязано.
На этом проблемы не закончились. Разработчик пошёл дальше и вывел на UI метрику в колонку «Более 4 заказов за поездку». «Более 4» — это 5. Надо так и писать: «5 и более заказов за поездку». Это лишнее действие в уме для разработчика и пользователя, которое появилось в результате такой ошибки.
Несколько вариантов для одного термина
В нашей системе можно встретить варианты нейминга одних и тех же терминов.
Заведение: Pizzeria, Restaurant, Store, **Unit**
Самовывоз: Pickup, **Takeaway**, Carryout
Заказ в ресторан: Stationary, **Dine-in**, Restaurant
Выручка: **Sales**, Revenue
Управляющий: **StoreManager**, Manager, Supervisor
Чек: Check, Cheque, ReceiptИ если в некоторых случаях перевод просто некорректный и можно смело исправлять, то с чеком и пиццерией сложнее — сначала нужно договориться и выбрать одно значение.
Игнорирование конвенций нейминга языка программирования или компании
Мы должны знать общие правила нейминга в компании и своего языка программирования. Наш код должен быть достаточно близок к индустрии, из которой будут приходить люди, чтобы его поддерживать и развивать. В то же время в компании может быть своя прослойка правил, чтобы поддержка большой кодовой базы была проще и инженеры могли легко переключаться между проектами.
Нейминг — это понимание предметной области
Представим, что наш домен — хирургический набор. Это сейчас он аккуратно разложен перед нами на изображении ниже. Мы можем учесть все предметы и спроектировать домен. Мы не бросимся орудовать термином scissors налево-направо, так как понимаем, что ножниц много, они предназначены для разных операций. У нас будет всё так, как в жизни: BandageScissors, DissectingScrissors и так далее.
На практике, когда мы садимся за новый проект или подключаемся к существующему, перед нами не только нет подобного изображения, часто нет даже словесного описания. Предметная область, которую мы пытаемся оцифровать, является результатом нашей субъективной интерпретации на основании существующего кода или отрывочных фактов, которые мы сами соединяем в голове. Навряд ли у нас по счастливой случайности есть квалификация в области медицины или мы хотя бы раз видели такой набор. И если мы думаем о терминах на ходу, то плохо себе представляем, что же мы делаем. Отсюда выведем первое следствие:
проблемы с неймингом → проблемы с пониманием предметной области.
Плохой нейминг — это работа, оставленная на потом. В моменте мы не уделили ему достаточно внимания, значит, будем уделять его потом — каждый раз, когда придётся работать с кодом или другими артефактами. Это похоже на захламлённую комнату. Подходя к неймингу несистемно, мы увеличиваем беспорядок. И нам становится всё сложнее ориентироваться, придётся держать много особенностей в голове.
Выведем остальные следствия плохого нейминга:
требуется больше усилий → больше вероятность ошибки;
увеличивается энтропия → код сложнее поддерживать;
разработка идёт медленнее и труднее с нарастающим итогом.
Помимо прочего, так мы тратим собственные когнитивные ресурсы на ориентирование в коде. Тут дело даже не в эффективности. Это бесполезно упущенные время и энергия, которые нам ничто не компенсирует. И эти потери драматичны, поскольку неудачный нейминг прописывается единожды, но проявляет себя многократно и замедляет каждого, кто с ним сталкивается.
Как выстроить работу с неймингом в команде
Перед нами новый проект или уже существующий, которым мы плотно займёмся. До того как мы распишем нейминг, нужно погрузиться в предметную область. Для этого есть разные инструменты: от простого интро или экскурсии на производство до Event Storming или совместного составления User Story Map. Понять предметную область для инженера критически важно. Возможно, вы не раз слышали утверждение, что разработчик точнее знает бизнес-процесс, чем эксперт из бизнеса. Именно потому, что он его не только представляет, но и реализует до мельчайших подробностей. И каждый новый участник команды должен проходить погружение.
После погружения нужно составить словарик. В парадигме DDD это будет Ubiquitous Language. Для составления словарика собирается встреча — максимально все, кто будет участвовать в работе над проектом. Важнейшим критерием должно быть то, что в группе есть и бизнес, и технические эксперты. Драйвит составление словарика и его владение технический эксперт. Примерный состав группы:
менеджер продукта,
разработчик,
инженер по качеству,
дизайнер,
аналитик,
стейкхолдер,
эксперт со стороны бизнеса.
Словарик состоит из сущностей, акторов, процессов из предметной области. Иначе говоря, нам нужно «нарезать» домен на сущности. Выдвигая каждый термин, мы расписываем его определение, что мы понимаем под этим. В процессе формулирования терминов и их определений происходит обмен контекстами между техническими и бизнес-экспертами.
Во время встречи происходит выравнивание картины у всех участников. На нашей практике обнаружилось, что даже у разработчиков одной команды, которые не первый месяц поддерживали продукт, было совершенно разное понимание одних и тех же вещей. Мы были очень рады, что заранее всё это проговорили. Помимо синхронизации на поверхность всплывает множество мелких деталей и вопросов, которые были в голове у кого-то одного, но теперь будут вписаны в общую картину. Более того, мы впервые можем показать бизнесу то, что собираемся делать, ещё не сделав ничего! Наше видение будущей системы уже может быть сопоставлено с ожиданиями стейкхолдеров. Для представителей бизнеса важно и интересно быть вовлечёнными в создание продукта, которым они же и будут пользоваться, который станет их активом.
Вполне может случиться, что найдутся непроработанные детали, которые нужно выяснить и взять на исследование. Паркуем спорные моменты и двигаемся дальше. Как правило, с одной встречи словарик составить не выходит — всегда вылезают какие-то детали, о которых нужно подумать отдельно.
Что делать, если идёт тяжело, термины для словарика не генерируются? Во-первых это нормально. Работа над неймингом — это часть архитектурной работы. Размышляя над терминами и их значением, мы прикидываем архитектуру нашей системы. Опыт тоже играет роль. Но, как правило, это показатель слабой погружённости в предметную область. Погрузитесь сильнее, выясните больше деталей.
Важный момент, что изначально мы составляем словарик на том языке, на котором говорит бизнес. Программы для бухгалтерий так и пишутся на русском. Это логичное решение, поскольку усилия, потраченные на перевод терминологии, которая нужна только для русскоязычного рынка, будут напрасными. Но больше случаев, когда нужно переводить терминологию на английский.
У нас есть глоссарий бизнес-терминов на английском. Лучше, если он будет глобальным для компании. Как упоминалось выше, перевод бизнес и нишевой терминологии — задача нетривиальная. Переводчику нужно обладать экспертизой в бизнесе, чтобы правильно подбирать терминологию. Так что такому глоссарию обязательно нужен владелец, который будет аппрувить или помогать с переводами.
Для перевода мы не пользуемся гугл-транслейтом. Наши инструменты:
multitran.com для перевода,
wooordhunt.ru для поиска английских терминов в контексте,
context.reverso.net для поиска терминов по контексту.
Если вам сложно выбрать из двух-трёх терминов, вбивайте в поиск термины как в примере: staff member vs employee и вы попадёте на форумы, где носители языка помогают разобраться с контекстом употребления.
После того как мы составили словарик, добавляем его прямо в readme проекта. Он должен быть актуальным и лежать на виду, рядом с кодом.
Следующий шаг — это контроль, за это отвечает код-ревью. В процессе код-ревью по неймингу учитываем следующее:
верифицируем все новые термины;
смотрим на нейминг так, словно вы никогда не работали с этим доменом;
из названия должно быть сразу понятно, что это;
у термина не должно быть нескольких трактовок.
Как это назвать? Практические советы
Давать наименования — это навык, и на старте может быть сложно. Однако есть два простых правила, которыми можно пользоваться всегда:
Отталкивайтесь от значения. Выпишите его. Как бы вы это назвали? Начните с русского наименования. Совместите значение и название — должно звучать складно, без лишних слов, на которых «спотыкаешься» — как человеческая речь.
Не можете назвать лаконично — назовите предложением, потом сокращайте:
Количество заказов на курьера в час
→ ordersCountPerCourierPerHour
→ ordersPerCourierLabourHourПример. Назовём массив с объектами. Для начала просто выпишем структуру:
стоп-продажи по причине нехватки ингредиентов:
- ингредиент, из-за которого остановлены продажи: халапеньо
- продажи были остановлены в: 2023-01-05T10:00
- остановка продаж закончилась в: 2023-01-05T15:00
- сотрудник, который остановил продажи: Мельников А.
- сотрудник, который возобновил продажи: Мельников А.
- точка продаж: Сыктывкар-1Теперь переведём:
var stopSalesByIngredients = [{
ingredientName: "jalapeno",
startedAt: "2023-01-05T10:00",
endedAt: "2023-01-05T15:00",
staffNameWhoStopped: "Melnikov A.",
staffNameWhoResumed: "Melnikov A.",
unitName: "Syktyvkar-1"
}]Дополнительные советы, которые помогут сделать нейминг лучше
Явное > неявное. Отвлекитесь на секунду и представьте, что прошёл год. Пронеслась череда событий и вы снова вернулись к этому коду. Вспомните ли вы все нюансы, которые не отразили в названии? Представьте, что видите этот код в первый раз и что не выясняли с болью всякие мелкие особенности, которые могут скрываться за этой конструкцией. Например, переменная содержит время окончания всего цикла или только какой-то стадии цикла. Укажите это явно в обоих случаях. Сколько возможностей для багов можно посеять, если не уточнить и оставить загадку другому разработчику или даже самому себе!
Не стремитесь называть максимально коротко. Нейминг из 3-4 слов — это нормально. Передать конкретику одним словом, чаще всего, нельзя.
Одна переменная — одна цель. Например, вы хотите записать дату и время окончания смены и одновременно по этой же переменной понимать, закончилась ли смена. Никогда так не делайте! Только явное обозначение в другой булевой переменной.
ShiftEndedAt,IsShiftEnded.Отрицание только усложняет, а также это пример неявного поведения. Используйте явные наименования. Не «недоступно», а «доступ запрещён».
Вырабатывайте единую структуру. Например, используйте одинаковые суффиксы и префиксы:
Avg, Count, Percentage, Total, At, Name
unitName, productName
tripsDuration, couriersShiftsDurationИспользуйте глаголы или прилагательные для уточнения контекста:
addedIngredients, removedIngredients, lateOrdersCountСтандартизируйте нейминг для времени. Если система фиксирует какое-то событие, то используйте глагол в прошедшем времени + суффикс
At:happenedAt,startedAt.
Если по умолчанию храните время в UTC (что рекомендуется делать), а в контракте отдаёте локальное, то добавляйте ещё один суффиксLocal:happenedAtLocal.Опирайтесь на словари синонимов и значений.
Что делать с легаси
Если проект требует минимальной поддержки, то инвестиции в переделку нейминга не окупятся. Тут мы принимаем, что каждая задача делается дольше и оставляем всё как есть. Но даже в таком случае можно подчищать места с несколькими наименованиями для одного термина или переменными, смысл которых совершенно непонятен.
Но если мы приходим всерьёз и с большими задачами на легаси, то:
Составляем словарик с новой единой терминологией.
Делаем фасады для всего нового кода, чтобы локализовать область, где останется старый нейминг.
Применяем правило бойскаута — каждый раз понемногу рефакторим нейминг.
Как работать с возражениями
Нам так удобнее называть, нам такие названия понятны.
Я не эксперт в бизнесе, а задачу надо делать сейчас.
Так уже было в проекте.
Проверил в Google Translate, там такой перевод.
Это не так важно, главное качество кода.
Я придерживаюсь мнения, что в IT нет правильных или неправильных решений. Мы стремимся выбирать оптимальное, исходя из наших возможностей и обстоятельств. Порой срезание углов делается преднамеренно, например, когда у нас каждый час на счету и мы готовы потом разгребать все долги. Здесь я сошлюсь на Technical Debt Quadrant Фаулера. Сложно в двух словах объяснить коллегам важность работы с неймингом, особенно если это не тема встречи и об этом раньше сильно не задумывались. Но если мы понимаем, что их аргументы попадают в область Reckless Deliberate (преднамеренное безрассудство), то соглашаться с ними, конечно, не стоит, и начать разговор нужно именно с этого.
Ещё одна рекомендация — не обсуждайте нейминг текстом (во время ревью или составляя словарик), старайтесь делать это синхронно. Иначе это вымотает всех.
Как объяснить ценность бизнесу
Главный плюс для бизнеса — это скорость. Словарик, составленный на старте, эти несколько встреч будут окупать себя многократно: в ходе начальной разработки проекта, при каждом онбординге нового человека и команды, при каждом возвращении спустя несколько месяцев, чтобы добавить новые фичи.
Язык определяет мышление — так формулируется гипотеза лингвистической относительности. Выше мы разбирали проблемы и решения, которые вытекают из этой простой формулировки. К современному инженеру предъявляются гораздо более высокие требования по коммуникативной грамотности, чем к инженерам ещё несколько десятилетий назад. И в IT это особенно чувствуется, ведь всё, что мы делаем — это текст. Осознание значительной гуманитарной составляющей в профессии инженера существенно изменило мой подход к делу.
Конечно, чтобы «третьекласснику» дорасти до «редактора» нужен не только навык крутого нейминга. Мелочи, из которых складывается общая картина, разбросаны по множеству книг, статей, проектов. Однако чистый и понятный код даёт уже очень много. Ещё больше про мелочи в коде рассказывает Роберт Мартин в книге «Чистый код». Если вы ещё не открывали эту книгу или делали это давно, то сейчас самый подходящий момент.
А ещё про нейминг у каждого есть свои байки и казусы, поделитесь ими в комментариях. Вы также можете поделиться этой статьёй с коллегами. Она самодостаточна, чтобы стать отправной точкой к улучшению нейминга в проекте, над которым вы работаете.
Комментарии (220)
Grey6000
00.00.0000 00:00-14А зачем вообще переводить на англ? если бизнес на русском и разработчики тоже русскоязычные, было бы логичней писать бизнес-логику на русском, а не мучаться со словарями для терминов
Писать на русском не привычно, но код внезапно был бы более понятный чем couriersShiftsDuration, ordersPerCourierLabourHour, Health permit, Nutrition facts
xxlagr Автор
00.00.0000 00:00+22Было бы логично, если продукт никогда не будет выходить в другие страны. У нас сейчас 17 стран и в этих странах разработчики (которые пользуются API например) — они совсем не знают русский.
Max_Pershin
00.00.0000 00:00-11Так пусть учат. Чем мы хуже?
xxlagr Автор
00.00.0000 00:00+11Извините, но это ложная альтернатива: «не учат язык = считают нас хуже».
До 20 века международным языком был французский, сейчас английский. Нашим разработчикам приходилось читать инструкции по немецки, когда нужно было интегрироваться с немецкими системами оплаты. Было больно, без претензий к немецкому. Просто даже второй язык выучить не то, чтобы просто.Max_Pershin
00.00.0000 00:00-11Так вы главные - пусть учат. И тут не язык - тут набор терминов. Это же не инструкция а имена переменных. Спутник выучили и остальное выучат. Главное начать.
xxlagr Автор
00.00.0000 00:00+11Возможно вы знаете секрет как мотивировать иностранца купить франшизу, вложить средства в открытия ресторанов и при этом в обязательном порядке выучить русский. И вроде хочется начать, но не знаю с чего.
Max_Pershin
00.00.0000 00:00-12Просто скажите что если посмотреть граф совпадений корней русского языка с остальными индоевропейскими то он будет на втором месте после санскрита.
SteamEngine
00.00.0000 00:00+9Если вам верить, санскрит вообще на первом, но его почему-то мало кто учит. Задумайтесь, почему.
Max_Pershin
00.00.0000 00:00-7Потому что это МЁРТВЫЙ язык!
SteamEngine
00.00.0000 00:00+5Именно. Мёртвый - то есть им не пользуются. И русским в окружении иностранца тоже не пользуются. Так какая для него конкретно разница между санскритом и русским?
Max_Pershin
00.00.0000 00:00-4Опять карму минусят! Опять эти анонимные отравители - душа хабра.
Вот пруфы про санскрит и русский
https://naked-science.ru/article/history/praindoevropejskie-yazyki-okazalis
Max_Pershin
00.00.0000 00:00+1Ещё, кстати русский - один из 5-ти официальных языков ООН.
tyomitch
00.00.0000 00:00+5Кто ещё среди них? арабский и китайский? -- точно, давайте называть переменные по-арабски да по-китайски, чтобы всем европейским программистам было в равной степени больно.
khacsam
00.00.0000 00:00Судя по тенденции на геополитической арене, следующим lingua franca будет арабский или китайский. Что тогда станут делать программисты?
И я бы заглянул ещё на полшага вперёд: в связи с тем, что Госдума приняла закон о запрете применения иностранных слов, за исключением случаев, когда нет эквивалента, что будет, если особо ретивые чиновники/руководятлы начнут применять нормы закона и к коду на ЯП? ))
P.S. Минусаторы, расслабьтесь, это всего-лишь размышления.
Hungryee
00.00.0000 00:00+15Потому что все, что вы написали - это заблуждение. Программист без знания базового английского - не программист, а макака, передвигающая операторы.
Любой такой программист поплывет на задании чуть сложнее чем обычно, когда нужно будет внезапно! заглянуть в документацию к новому материалу.Писать переменные на русском или в транлитерации - неуважение прежде всего к себе, коллегам (даже если они все русскоговорящие) и к IT сфере в общем
Grey6000
00.00.0000 00:00+8Дело не в знании англ, я специально подчеркнул про бизнес-логику, однозначный перевод бизнес терминов на англ довольно сложно перевести, ИНН какой-нибудь к примеру, склад тоже может быть как store или warehouse, и это только что-то простое, а если бизнес связан с медициной, там нужны специфичные знания англ.
чуть более сложных названий можно ссделать комментарий на русский, но его его придется дублировать в гетерах/сеттера/dto
Задачи ставит бизнес на русском вот и выходит бессмысленный перевод туда-сюда, перевод ради перевода
Vizmaros
00.00.0000 00:00+7Даже если опустить все аргументы «Разработчики иностранцы» и тому подобное, останется проблема написания. Транслитерация неудобна в чтении, смена язык для именования переменных излишняя трата времени. Оно действительно стоит затрат, если учесть что опытный разработчик английский понимает достаточно свободно, а неопытному нет разницы между необходимостью переводить и необходимостью понимать ее назначение, в обоих случаях ему смысл переменной одинаково неизвестен
Grey6000
00.00.0000 00:00+2вот не опытному было бы проще даже без понимания, просто поискать по названию бизнес-сущности, а не по ее переводу, тем более как ниже указали есть британский и американский англ, в которых одно и тоже будет называться по разному
thevlad
00.00.0000 00:00+6Проблема в том что у вас наверняка будут библиотеки и возможно сторонний код "на английском". В результате получится мешанина, которая точно никому не поможет.
DivoTech
00.00.0000 00:00+5>смена язык для именования переменных излишняя трата времени
А набирать переменную в пол строки -- не трата времени? А изучать значение каждого слова в нескольких источниках? А составлять словари переменных?
XAHOK
00.00.0000 00:00+2А набирать переменную в пол строки -- не трата времени?
3-5 первых символов, CTRL+SPACE, TAB. Трата времени только при работе в блокноте. И это намного лучше, чем лезешь в код, а там всякие TextBoxN и весь алфавит, в котором хранятся магические данные. Причем сам разработчик уже через неделю не может понять как оно работает.
А изучать значение каждого слова в нескольких источниках?
Для разработчика очень даже полезно, за одно погрузится в предметную область и меньше будет ляпать в коде.
А составлять словари переменных?
А еще использовать всякие аналайзеры, писать стайлбуки и пинать шлангом по пяткам за отступы. У нас и так много обвеса, что бы следить за чистотой кода, что бы была проблема от добавления ко всему этому маленького словарика с основными терминами.
DivoTech
00.00.0000 00:003-5 первых символов, CTRL+SPACE, TAB
В статье приводятся примеры "правильных" названий перменных:
tripsWithOneOrderCount
tripsWithTwoOrdersCount
tripsWithThreeOrdersCount
tripsWithFourOrdersCount
tripsWithFiveOrMoreOrdersCountЯ тут насчитал 10-11 символов до "CTRL+SPACE, TAB". И это далеко не самые страшные случаи при таком подходе
Для разработчика очень даже полезно, за одно погрузится в предметную область и меньше будет ляпать в коде.
Примерно как знание, что Пномпень это столица Камбоджи — может где-то когда-то пригодиться, но количество таких знаний стремится к бесконечности, а польза от них — к нулю
У нас и так много обвеса
Видимо, это потому что процесс важнее результата
Но вообще, смысл моего сообщения был в том, что это всё занимает намного больше времени, чем пеключение языка. Т.е. с таким подходом цель явно не в его экономии
XAHOK
00.00.0000 00:00+2Я тут насчитал 10-11 символов
Или пара нажатий стрелок.
Примерно как знание, что Пномпень это столица Камбоджи
Если вы работаете там, где важно знание, что Пномпень - это столица Комбоджи, то да - это важное знание.
Видимо, это потому что процесс важнее результата
Это потому что мы не пишем одноразовый софт, где вообще пофиг на качество кода. Хороший код тогда, когда новый человек может легко читать его, а что бы он быстро привык писать в общей стилистике, сама среда его бьет за нарушение оформления.
Chamie
00.00.0000 00:00Я тут насчитал 10-11 символов до «CTRL+SPACE, TAB». И это далеко не самые страшные случаи при таком подходе
Там, на самом деле, обычно, не нужно именно первые писать. Можно вводить что-нибудь типа «trwt», чтобы подсказка выдала ранее объявленную «tripsWithTwoOrdersCount».
Hungryee
00.00.0000 00:00+11Ну так запишите ИНН как INN вместо какого-нибудь Tax Number (может быть много вариаций)
Но только проблема будет в том, что само по себе абстрактный INN тоже ни черта не понятная вещь, и придется добавлять комментарии.В случае со складом - создайте класс Warehouse, и в будущем все программисты будут его использовать, никому не придет в голову создавать еще один класс для склада с названием Store. Я вообще не понимаю в чем проблема «можно перевести разными способами», если достаточно создать имя классу всего однажды, и все будут его использовать, и IDE поможет, и документацию (внезапно) можно подключить к кодовой базе.
Не оправдывайте банальную лень придуманными проблемами. В 2024 году не знаешь английский = ты мертвый специалист.
Grey6000
00.00.0000 00:00+7В DDD есть принцип Единный Язык (Ubiquitous Language)
Эксперты предметной области (Domain Experts) и разработчики программного обеспечения работают вместе, чтобы создать общий язык для разрабатываемых бизнесс-сфер. Тут не может быть противопоставления, это единная команда. Разработка программного обеспечения это инвестиция в бизнес, а не просто статья расходов. Усилия, прилогаемые к созданию Единого Языка (Ubiquitous Language), помогают распространить глубокое понимание Домена (Domain) среди всех членов команды.
и выходит так что эта часть не работает вне англоязычных странах, потому что будет все равно 2 языка, англ и национальный язык
Единный Язык (Ubiquitous Language): Эксперты предметной области (Domain Experts) и разработчики программного обеспечения работают вместе, чтобы создать общий язык для разрабатываемых бизнесс-сфер. Тут не может быть противопоставления, это единная команда. Разработка программного обеспечения это инвестиция в бизнес, а не просто статья расходов. Усилия, прилогаемые к созданию Единого Языка (Ubiquitous Language), помогают распространить глубокое понимание Домена (Domain) среди всех членов команды.
lyay
00.00.0000 00:00Полностью согласен. Программист должен говорить на языке заказчика. Иначе время разработки растёт многократно.
Конечно, можно на лету переводить термины туда-сюда, но это пустая трата сил.
Zy2ba
00.00.0000 00:00+4Справедливости ради, видел проект, где в процессе разработки разъехались переводы терминов у фронтенда и бэкенда, так что "никому не придет в голову создавать еще один класс" - слабый аргумент.
Simpre_falta_algo
00.00.0000 00:00-1А ещё англ слова короче. В среднем на одну букву. В тысячах строк кода - это тысячи букв.
Sirion
00.00.0000 00:00-3И сколько букв в английском эквиваленте слова "защищающийся"?)
EVolans
00.00.0000 00:00+1Если у вас код с такими названиями переменных, мне вас жаль.
Sirion
00.00.0000 00:00+2У меня нет, но в целом не вижу ничего странного, если такой нейминг понадобится в коде какой-нибудь рпг.
Вообще я за английский как лингва франка. Но аргумент, что в нём слова короче, довольно глупый. Я могу придумать язык, где все слова однобуквенные. Но в итоге почти все понятия в нём будут выражаться фразами из эн слов.
Arbuzer
00.00.0000 00:00Defender - 8
trinxery
00.00.0000 00:00+5Defender
но это защитник
OneManStudio
00.00.0000 00:00в этом и проблема, проблема даже не в переводе, а в том зачем использовать конкретно такое имя, а не более простое и подходящее. Даже в рамках создания игр такое имя переменной врядли разумно использовать.
Arbuzer
00.00.0000 00:00Context.reverso по запросу "защищающийся" как раз и выдал "defender". Равно, как и "defending". Зависит от контекста, конечно, но имеет место быть
Simpre_falta_algo
00.00.0000 00:00-1Нейминг - это не просто перевод. А деепричастиям и причастиям нечего делать в коде.
XAHOK
00.00.0000 00:00А деепричастиям и причастиям нечего делать в коде.
Псссс, вы только мелкософту не говорите об этом, а то они не в курсе, потому в их злобном дотнете регулярно встречаются всякие IsTerminating и прочие инговые.
xxlagr Автор
00.00.0000 00:00+10Перевод бизнес терминологии — это не базовый английский.
Софт для бухгалтерий в СНГ пишется на русском. И это ок, потому что слишком специфичен, такой софт сложно адаптировать под другие регионы не только из-за правовых особенностей, но и из-за особенностей рынков, где доминируют другие платформы.Hungryee
00.00.0000 00:00-13Назовите, пожалуйста, пример такого термина, что не попадает в категорию базового английского.
Если вы опираетесь на 1С в своих аргументах, то это скорее антипример из ада. Этот софт должен умереть, а программисты 1С/на 1С - пройти курс психотерапии и реабилитации
Grey6000
00.00.0000 00:00Экстракорпоральное оплодотворение (ЭКО), штрихкод, Контрольно-кассовая машина (ККМ)
xxlagr Автор
00.00.0000 00:00В статье есть такой пример - зарплата. Переведёте это как salary и будет ошибка.
ASobolevskiy
00.00.0000 00:00+3Честно говоря, не совсем понимаю, что с salary не так
xxlagr Автор
00.00.0000 00:00+2Мы называем зарплатой всё, любой вид вознаграждений. Десятилетия социализма отразились в нашем языке. В то время как в английском salary — это фиксированное ежемесячное вознаграждение за умственный труд. У таксиста не может быть salary и у рабочего на заводе тоже.
ASobolevskiy
00.00.0000 00:00+3По поводу таксиста соглашусь (правда при условии, что он работает не на некую компанию).
Согласно Collins English Dictionary:
A salary is the money that someone is paid each month by their employer, especially when they are in a profession such as teaching, law, or medicine.
Сумма денег выплачиваемая работнику работодателем ежемесячно, особенно, если сфера деятельности обучение, право или медицина.
В то время как incentives согласно тому же словарю:
1. a motivating influence; stimulus (мотивация, стимул)
2. a. an additional payment made to employees as a means of increasing production (дополнительная оплата работнику, призванная увеличить производительность - т.е. есть фактически премия)
Я так понимаю, что именно вот этот момент и намекает на исключительно умственный труд - "особенно если сфера деятельности обучение, право или медицина"?
А вообще, все это только лишь подтверждает идею о том, что правильный нейминг выбрать довольно сложно)
xxlagr Автор
00.00.0000 00:00+5Всё верно. Мы выбрали максимально общее incentives, потому что это агрегат, внутри которого есть wages, premiums и прочее.
Пока отправляем весь нейминг на ревью нашим международным бизнес-девелоперам, которые шарят что там как именуется правильно (уточню, что пока это касается внешних API и новых проектов). Очень важен контекст, просто сторонний переводчик может не так перевести. И вот имея накопленный словарь уже можем смелее сами орудовать терминами. Так что да, это сложно и научить каждого разработчика так переводить не получится. Нужно находить возможность построить такой процесс внутри организации.NNikolay
00.00.0000 00:00+4Я как бы согласен с идеей статьи, но вот тут на мой взгляд перебор. Неправильно считать, что все англоговорящие коллеги вот прям совершенно верно понимают словарную разницу между incentives и salary. А ещё будут сотрудники из других стран, для которых английский тоже не родной. Я 10 лет в англоязычной среде живу и много видел:) Если термин не совершенно в доску очевидный, то лучше не полениться и уже писать base monthly salary, variable premium и там total fixed and variable monthly pay - ну например, я не сильно долго думал. Куча людей не прочитав словаря скажут, что incentives, bonuses and premiums - это синонимы. Даже если Вы формально правы.
alexeyrom
00.00.0000 00:00Внутри incentives ещё и не-денежная мотивация должна быть. И условно денежная, но не выплачиваемая работнику: медицинская и прочая страховка, обещанное повышение по должности и так далее.
tba
00.00.0000 00:00+1А они точно шарят? Максимально близкий к русской "премии" термин в контексте оплаты за труд это "bonus". "Premium" это премиальный, или, по-русски, первосортный, например "premium ingredients".
Для термина "incentives", как Вы его поясняете в комментарии выше, существует давно устоявшееся C&B - compensation and benefits. И т.д.
Плюньте. Составьте словарик транслита для зарубежных разработчиков - они привыкнут, а вашим будет проще и понятней. Как писал выше медицинских книжек в западном общепите (по крайней мере в той части где приходилось работать) не существует как понятия. Трудовых книжек не существует как понятия. Многих справок не существует как понятия. В части бюрократически-государственных терминов с русским языком сравнится только немецкий. Английский здесь бедноват.tyomitch
00.00.0000 00:00"Premium" это премиальный, или, по-русски, первосортный, например "premium ingredients".
Да, но не только: https://en.wiktionary.org/wiki/premium#Noun
xxlagr Автор
00.00.0000 00:00+2Не исключено, что вы шарите лучше. Тем не менее premiums был совершенно сознательно выбран.
В плане транслита — плохо масштабируется. Прочувствовать подобный опыт можно, если читать на турецком, например. Такие слова даже запомнить тяжело, что уже говорить о том, чтобы не опечататься или использовать их в коммуникации. Хотя вроде латиница.
tba
00.00.0000 00:00+1Турецкие разработчики как раз вовсю используют привычный им турецкий (с английским хуже чем в РФ) и никакого дискомфорта по поводу своего английского не испытывают. Зато все всем понятно. А уж если в проект занесло иностранца (редко, но бывает) и ему непонятно, но почему-то надо разобраться в коде, то выучить сотню турецких слов совсем несложно.
1001
00.00.0000 00:00У турок, видать, комплекс неполноценности недостаточно развит, не то, что у эксСССР...
Rrs
00.00.0000 00:00+2У русских слова заимствованы из всех заметных культур-мультур. Греческий, латынь, французский, немецкий, английский - все это есть в русском языке, именах и даже смыслах. Комплекс неполноценности это страхи, что подростки говорящие на руглише, или программисты, знающие английский и смешивающие слова в рабочем общении могут как-то этой культуре повредить.
comdivuz
00.00.0000 00:00Хотя я выше и написал кому то что переменные надо на английский переводить для того чтобы код читаемый был. Но когда такие комментарии как ваш вижу... Так и хочется спросить кто вы такой в плане экспертизы? Что отправляете флагманскую и вполне рабочую бухгалтерию в ад и не считаетесь с очевидным - есть 100500 продуктов и сайтов и API, в российском сегменте, где есть ИНН. В 99% поле будет называться inn, а не tin, потому что это самое читаемое для всех и понятное. Также и "физлицо" многие обозначат как FL, и не будут морочаться с Person, Human или Individial. Кроме вашего мира радикального есть ещё и практика реальная, в которой много конвенций.
sasha_semen
00.00.0000 00:00А еще есть sap, где проскакивают немецкие корни, например дебит/кредит это внезапно H(aben)/S(oll)
tohodov
00.00.0000 00:00+1Метить каждому сайту ларька в мировые монополисты? Не только лишь все из них будут выходить на мировой рынок, мало кто будет так делать. А значит язык программистов в будущем не изменится и англификация окажется преждевременной оптимизацией за которую будут платить члены команды временем на переспрос.
12rbah
00.00.0000 00:00+6а не мучаться со словарями для терминов
Скорее всего сильное влияние оказывает то, что 90% информации ищется на английском. И тут уже личное мнение, что название переменных вроде PoleznayaNagruzkaZaprosa режет глаз, многие языки конечно поддерживают utf-8 но мешать два языка как-то не очень(опять же мое мнение), ну и в целом в большинстве проектов нейминг +/- предсказуемый и большинство пониамет о чём идёи речь.
tommyangelo27
00.00.0000 00:00+2Плюс подключение библиотек, которые вероятно будут тоже на английском. И получится мешанина, что-то вроде
$handler->sendToQueue($platezhka)Grey6000
00.00.0000 00:00-11) в русском и так часто есть вкрапления английских слов, например e-mail, Mysql, XML, HTTP, KFC, McDonalds и др слова, бренды и аббривиатуры
2) я против транскрипции, мы же не поляки
3) ваш пример выглядел бы так:
обработчик->вОчередь(платежка)или вроде тогоUPD для добавления внешних библиотек в целом стоит использовать свои интерфейсы см паттерн мост (Bridge)
tommyangelo27
00.00.0000 00:00Ну да, вопрос стратегии. Лично я вижу только три варианта:
— придерживаться локальных названий в своей логике, и забить на мешанину;
— придерживаться локальных названий в своей логике, и писать обёртки для библиотек (что само по себе МОЖЕТ иметь смысл, не только из-за языка);
— перейти на английские наименования, чтобы избежать смешения языков.
Лично я придерживаюсь последней стратегии, потому что писать фасады/мосты для подключаемого кода в 80% случаев будет напрасным трудом (в моей работе), а смешивать понятия из разных языков не люблю, перфекционизм мешает.
tommyangelo27
00.00.0000 00:00+6BTW проблема не конкретно в русском языке и кириллице. Для польского программиста код вроде
$zasob->dodajDoKolejki($zamowienie)
выглядит так же кринжово, как для русскоязычного программиста код 1С (говорю как активный потребитель мемов).
Примерно два года назад работал в чисто польской фирме (был единственным иностранцем), и мы пилили проект на польский и чешский рынок. Тикеты в джире на польском, конфлюенс на польском, общение в команде тоже. А код — на английском. Потому что мировой стандарт.Grey6000
00.00.0000 00:00-6То что код на английском - стандарт я знаю, вопрос в другом, а правильно ли это? ведь все рекомендации к разработке в первую очередь предназначены для них, а весь мир подстраивается, к примеру, если бы у нас была развита информатика как в штатах, мы в нашу сферу влияния могли бы войти славянские страны и те кто кириллицу использует
tyomitch
00.00.0000 00:00+8Если бы да кабы‚ да во рту росли б грибы, тогда был бы не рот, а целый огород.
XAHOK
00.00.0000 00:00+2все рекомендации к разработке в первую очередь предназначены для них, а весь мир подстраивается
Все рекомендации пишутся на том языке, который понимает большинство. Если посмотреть научные статьи, то, внезапно, даже китайцы пишут международные статьи на английском, потому что его знают почти все, а не только лишь в Азии.
Да, есть руководства на русском, есть русификации интерфейса, и т.п. Но, все равно, многие возвращают на английский, потому что на нем информации намного больше и не надо на лету в голове картинки переводить, пытаясь англоязычный ман сопоставить с русскоязычным интерфейсом.
в нашу сферу влияния могли бы войти славянские страны и те кто кириллицу использует
Вы чешский или белорусский свободно понимаете? Кирилица != русский язык.
zuek
00.00.0000 00:00Это ещё что! Вот у меня в одном проекте есть такой смешной фрагмент:
Quer = New Query; Quer.Text = Catalogs.ОтчётыWebСервиса.FindByDescription(NameReport,True).ЗапросКБазе;Это после "рефакторинга" обработки web-сервиса 1С на англоязычный синтаксис осталось...
DivoTech
00.00.0000 00:00+2Перевод терминов на уровне носителей языка могут делать только носители языка. Даже хороший программист не всегда знает английский до таких тонкостей (да и не должен). И тратить его время на изучение особенностей названий того же заработка — не очень разумно.
Иногда такие переводы и вовсе могут ввести в заблуждение и привести к ошибкам, хотя вроде как всё это делалось для их избежания.
Так что по этой части нужен явно не тот подход, что указан в статье. Хотя в остальном мысли здравые
tba
00.00.0000 00:00+5Вы совершенно правы.
Проблема не в незнании английского - проблема в недостаточном знании предметной терминологии как на английском, так, зачастую, и на русском. Пример прямо из текста статьи: Health Permit как аналог медицинской книжки. Ближайший русский аналог термина Health Permit - это "Разрешение на соответствие санитарным нормам", выдаваемое Роспотребнадзором предприятию (раньше сертификат СЭС), а не сотруднику. А вот ближайший аналог российской медицинской книжки, теперь называемой санитарная книжка сотрудника, это Health Clearance/Health Certificate и, нет, это не книжка.
Я сам когда-то ратовал за правильные английские названия, но вскоре пришел к выводу: если большая часть разработчиков русскоязычные, то пусть пишут на русском английскими буквами, главное чтобы это было а) понятно и б) чтобы одни и те же понятия разные разрабы называли одинаково (единое понятийное пространство). А для зарубежных коллег, многие из которых, даже владея английским, не владеют терминологией предметной области (тут они ничем не отличаются от "наших") специально выделенный человек пишет пояснения прямо в коде - они очень быстро привыкают.xxlagr Автор
00.00.0000 00:00Если условия позволяют и всем удобно, можно принять за правило и транслит.
Однако мы используем языки и фреймворки, паттерны, термины, которые не принято переводить. Транслитерация тоже по-своему сложна. Я вроде Arsenii по правилам транслитерации, но никогда так своё имя не писал. И всё это вносит неопределённость вместо пользы. А ещё и воспринимается иначе: vykladka vs deployment. Тут же остаётся добавить, что мы читаем документации, статьи, книги на английском (их существенно больше, чем на русском и они свежее). А ещё open source, где с таким подходом не пройдёшь ревью.
Идеальные переводы как недостижимый идеал. Но это не значит, что не стоит к этому стремиться. Это тоже часть порядка. И я бы даже сказал, что единство терминологии > точность перевода.
vassabi
00.00.0000 00:00если вы не 1С пишете, то буквы-то все равно латинские ...
так-то словарик бизнес-терминов все равно будет "имя латиницей - описание на родном языке"
lovermann
00.00.0000 00:00-1Ну, он как обычно бывает: начинаешь бизнес для своего села, а через несколько лет уже осваиваешь материки. Никогда не знаешь, кто будет работать с кодом. Да, и вообще, я удивляюсь тем, кто в код вбивает свой родной язык.
comdivuz
00.00.0000 00:00Ну есть 1с там и язык сам на русском. И названия по русски. Тут такое дело, что имена переменных вплетаются в язык. То есть хорошо читается или "привет, как дела" или "hello, how are you", но не "привет, how дела you"
lyay
00.00.0000 00:00Полностью согласен. Надо исходить из области распространения проекта, времени его жизни, команды поддержки. Если пишешь внутреннюю автоматизацию ларька и полностью передаёшь код заказчику, то русский - самое оно. Работаешь с Египтом, значит пиши по-английски. Потому что арабское письмо не очень.
Survtur
00.00.0000 00:00Ещё одна рекомендация — не обсуждайте нейминг текстом (во время ревью или составляя словарик), старайтесь делать это синхронно.
Поясните, плиз. Я не понял эту фразу. Синхронно - это как? Не понимаю как это противопоставляется обсуждения/ревью?
xxlagr Автор
00.00.0000 00:00+1Синхронно = голосом. Например, если проводить ревью и оставлять комменты в гитхабе, то это может сильно затянуться. Для того, чей код ревьюят, это выматывающая история, когда в PR раз за разом прилетают уточнения или он не понимает, что от него хотят. Если замечаний по неймингу много или есть сложные моменты, лучше обсудить голосом, возможно сразу добавить в словарик что-то новое. Опыт показал, что текстом всё идёт долго и процесс начинает казаться мешающей формальностью. После того, как команда научится, словарик составится, будет проще.
zuek
00.00.0000 00:00Странно... я наоборот придерживался всегда тактики "сохранения следа" - чтобы было понятно, откуда и почему родилось решение, особенно если речь не про то, во сколько сегодня идти на обед, а про что-то важное (а "пространство имён" - по-моему, весьма важный момент). Да, через PR такое футболить - сомнительная идея, но собраться в группе и обсудить с сохранением истории, а если ещё и с посылом "переспать с этим списком" - по-моему, намного продуктивнее "обсудили в курилке"/"пошумели в переговорке".
xxlagr Автор
00.00.0000 00:00В статье тоже говорю про это «если идёт тяжело — погрузитесь сильнее, узнайте больше деталей». Возможно стоит отложить принятие финальных решений.
По поводу «следа». Если на проекте недавно, то, конечно, лучше продолжать делать как было. Но при должном погружении, к сожалению, видишь, что никакой глубокой мысли не было. Системная работа с неймингом сразу бросается в глаза.
JuryPol
00.00.0000 00:00+5Может быть, подразумевались всякие чаты… такая нечаянная иллюстрация важности нейминга
wolfy_str
00.00.0000 00:00-5Как всё таки иногда разражает эти проблемы джунов и синьоров - нейминги, какой фреймфорк использовать и прочие холиварные темы, которые по большей части не имеют смысла. А как доки не так написаны, коммиты не по правилам, а вот доки к тесту не так написаны. Очень сильно раздувает процесс разработки. Все эти придирки к называниям, докам и прочему занимают 95% код ревью. Тогда как по существу на саму логику тратится от 5 до 10, максимум 15% времени, и то 15% я такое не встречал, хотя логика это основа всего, её же практически никто не проверяет. Потому что те же тесты можно так мокировать, что никто не поймёт что программа работает не правильно. Тем более тесты это ручной ввод по типу "2+2" должно быть равно 4. Тут любой алгоритм можно подобрать так что 2+2 будет равно 5, а при должной снаровки можно сделать так что никто ничего не поймёт и тесты будут проходить всегда.
Вообщем действительно есть проблема что саму логику не смотрят и ей почти никогда не уделяют времени, на уровне от джун+ до мидл+, на последних надеются что и так будет работать, насчёт первых не знаю. Но логику подправить никогда практически на это не обращают внимания, уделяя всё внимание неймингу и прочей оболочке. И да рефакторинг это вообще далеко не самая сложная, скорее даже самая простая вещь при должном подходе, переменная которая используется 5, 10, 20 раз меняется за 10-20 секунд вдумчивого подхода.
alexxxnf
00.00.0000 00:00+38Вы себе даже не представляете, какого труда мне стоило прочитать ваш комментарий. Мой мозг постоянно спотыкался о неправильные окончания, склонения, знаки препинания. Такой уж у меня мозг. Мне пришлось сделать над собой усилие, чтобы сосредоточиться на содержании, а не на форме. Я ни в коем случае не обвиняю, просто вот так по-дурацки работает мой мозг.
То же самое относится к код-ревью. Если код написан без соблюдения стилей и нэйминга и у меня есть возможность поручить ревью кому-то другому, то я именно так и сделаю. В противном случае я потрачу на ревью в 3 раза больше времени, чем надо. Просто потому что, если мой мозг замечает дерьмо в коде, то ни на что другое переключить внимание он уже не может.
Так что если вас волнуют когнитивные усилия читателей, пишите красиво. Если не волнуют, пишите, как хотите.
wolfy_str
00.00.0000 00:00+2простите у меня с этим проблемы :( с речью тоже. Но исправить плохой стиль кода как раз не проблема, проблема написать работающую логику. Собственно за час могу сделать рефакторинг, а вот с логикой беда могу и сутки делать одну функцию/метод. В любой среде есть способы рефакторинга, когда за 20 секунд меняем 20 переменных, это делает среда как минимум во всём сервисе.
Да и так как не могу сразу написать комментарий то продолжу. Вполне можно потратить день два чтобы привести код в проекте к нормальному состоянию, тем более рефакторинг идёт в 5 - 10 раз быстрее простого написания кода, а если сравнить как я пишу, то и до 100 раз быстрее. Я вот понимаю все концепции солида чистого кода, но не могу не понимаю логику довольно часто, с этим у меня проблемы.
Survtur
00.00.0000 00:00+2Так вам всего лишь нужно пару раз перечитать и отрефакторить свой собственный комментарий.
xxlagr Автор
00.00.0000 00:00+3Обращу внимание, что статья говорит не только про аккуратность в нейминге. Изменить нейминг через горячие клавиши далеко не всегда удастся. Представьте, что с вашим API взаимодействуют сотни внешних систем. Да даже если десяток — уже сложно. А если одну и ту же переменную использовали для разных целей, потому что не поняли её предназначение?
Избыточные процессы мешают. Но бывает, что проблема в том, что люди выполняют какие-то действия не понимая, для чего это нужно. Статья как раз доносит, почему важно вкладываться в нейминг. Это совсем не nice to have история.
По поводу проверки бизнес-логики во время ревью. Это не лишнее, но, всё же, лучше отладить процессы тестирования. И посмотреть в сторону пирамиды тестирования, где есть не только юнит-тесты.
tetelevm
00.00.0000 00:00+14Переменную не переименовать за 10-20 секунд. Варианты:
поле у бд-модели, которое отвечает за столбец
по 5 вперёд-назад строчкам непонятно, за что именно она отвечает
вызывается где-то в неявном виде (
[getattr(smth, f"get_{field}") for field in smth_fields])этот класс используется у третьих сторон через rpc
В целом, есть ощущение, что вы больше писали новые вещи, чем что-то поддерживали. В этом случае у вас в голове есть логика работы всего кода, с которым взаимодействуете, поэтому нейминг, коммиты, документация и организация кода кажутся не такими уж важными.
У меня обратный опыт, я больше попадал на доработку реализованных систем, и поэтому меня эти вещи крайне важны. Например, как быстро понять, что за что отвечают условные поля
user.tools: integerилиcar.delivery: char, которые появились с коммитомadded new logic? Понять можно, но нужно сначала придётся попрыгать по файлам и поискать по всему проекту (найдите использование поляsmth.typeв проекте), а затем надеяться, что из-за переименования у пользователей не начнёт дублироваться списание денег.Да, я согласен, что логика первична (в реальном мире код лишь инструмент для бизнеса), но знать всю логику вы сможете только если:
вы с самого начала проекта на нём (либо уже давно пришли на него)
он не слишком большой, всю логику возможно охватить
команда небольшая и вы знаете, кто чем занимается
Если же что-то из этого не работает, то понимать всю логику проекта невозможно, и приходится работать не с
логикой, а сконтекстом. А в работе с контекстом как раз и помогают те 85+% шелухи - нейминг, коммиты, документация, организация кода, ... .wolfy_str
00.00.0000 00:00+3Я согласен скорее у меня проблема с пониманием и тем что самой логике уделяют крайне мало внимания не более 10% времени. И если ты не знаешь как написать логику то тогда говорят что ты вообще ничего не умеешь. Напротив на обсуждение довольно понятных вещей уходит львинная часть времени любых обсуждений или code review
Насчёт быстрого переименования и имел ввиду что за 20 осмысленных секунд в IDEA или какой либо другой оболочке вы пользуясь методом Рефакторинга можно изменить переменную во всём сервисе. Это как минимум. Про третьи стороны это да, не подходит.
Надеюсь разъяснил. И да у меня не получается понятно выразить свои мысли, извиняюсь у самого с этим проблемы в жизни :(
Fr0sT-Brutal
00.00.0000 00:00Варианты:
поле у бд-модели, которое отвечает за столбец
по 5 вперёд-назад строчкам непонятно, за что именно она отвечает
вызывается где-то в неявном виде (
[getattr(smth, f"get_{field}") for field in smth_fields])этот класс используется у третьих сторон через rpc
А если где-то в глубине вызовов найдется JSON.serialize(object), то вообще пиши пропало
ggo
00.00.0000 00:00+7Вам надо всего лишь поработать на уже долго живущем проекте, и некоторое время фиксить на нем баги и пилить новые фичи. Где сменились поколения разрабов.
Когда из-за неудачного нейминга, вы полдня ковыряли код, чтобы понять его логику...
После этого полезность правильного нейминга перестанет быть неочевидной.
И про сопроводительный текст для коммитов тоже самое.
Fedorkov
00.00.0000 00:00+2Подписываюсь практически под каждым словом. Я сам во всех своих проектах начинаю с составления глоссария, и только потом перехожу к сбору или уточнению требований.
Один тонкий нюанс, который вы явным образом не затронули: имена всё же бывают слишком длинными. Нейминг из 3-4 слов — это нормально, но не когда все имена такие. Всё же главное в стиле — это лёгкость чтения, и ради него иногда стоит отступиться от педантичной строгости.
Но это требует соблюдения ещё одного принципа, который тоже стоит упомянуть: код надо писать так, чтобы будущие вероятные ошибки, как минимум, мозолили глаза. А ещё лучше — чтобы вылезали на этапе компиляции.
Fedorkov
00.00.0000 00:00+1→ ordersPerCourierLabourHourВсё-таки лингва франка программистов - это американский английский, так что labor. А ещё лучше - ordersPerCourierManHour.
xxlagr Автор
00.00.0000 00:00Да, такой вариант тоже корректен. Но «рабочие часы» больше нам подходят, культура компании такова, что «человекочасы» коробят, так не говорим.
Про американский английский крутое замечание!
Chamie
00.00.0000 00:00ManHour — гендерно не нейтральный.
aleksandy
00.00.0000 00:00+1Как будто это что-то плохое.
xxlagr Автор
00.00.0000 00:00+1Для бизнеса в другой культурной среде это может быть критично
shigorin
00.00.0000 00:00+2Во-первых, не культурной, а контркультурной — если ещё не слышали про отмену тех же математики с физикой как расистских наук. Во-вторых, это проблемы титаника — далеко не все согласны расчеловечиваться, дорожка-то именно туда.
xxlagr Автор
00.00.0000 00:00+1Ходить в крестовые походы и спорить у кого культура правильная — дело сугубо личное. Можно одно и то же явление рассматривать и как результат эмансипации и как «расчеловечивания». Вопрос этики в разработке интересный. Кто-то делает онлайн-казино, кто-то бы не стал бы. Возможно вопрос нейтральности для вас принципиальный.
withkittens
00.00.0000 00:00+1
Fedorkov
00.00.0000 00:00+2Начните с русского наименования. Совместите значение и название — должно звучать складно, без лишних слов, на которых «спотыкаешься» — как человеческая речь.
Часто каша в понятиях становтся очевидной ещё до того, как вникнешь в предметную область, по чисто формальным признакам
Если речь заказчика изобилует оборотами типа "масса для" и "время кроме", то это очевидный симптом косяков в архитектуре или в рабочих процессах, после исправления которых исходную проблему решать уже не придётся.
xxlagr Автор
00.00.0000 00:00+2Неоднократно было: формализуешь бизнес-процесс и оказывается, что проблема решается менеджментом. Сам факт того, что к тебе приходят «сделайте нам конкретно это» должен вызывать подозрение.
YegorP
00.00.0000 00:00Справедливо для начала разработки. Но никаких ресурсов не хватит всякий раз решать проблему на корню. Рано или поздно заказчик приходит с очередной идеей, которая не укладывается в ранее заложенные абстракции, а на закладку новых нет времени. И вот тогда вместо специализированного крепежа вы достаёте гвозди / изоленту / клей да идёте обмазывать всё техническим долгом (в том числе имена в коде).
Chamie
00.00.0000 00:00+5public enum TravelMode // FIXME rename to TransportType
{
Driving = 0, // FIXME rename to Vehicle
Walking = 1, // FIXME rename to OnFoot
Bicycling = 2 // FIXME rename to Bicycle
}A bicycle, also called a pedal cycle, bike, push-bike or cycle,
is a human-powered or motor-powered assisted, pedal-driven, single-track
vehicle
en.wikipedia.org/wiki/Bicyclexxlagr Автор
00.00.0000 00:00Отлично! Через нейминг увидели, что домен несовершенно спроектирован.
А история там такая, что сначала в енуме было 2 значения, а потом, в одной стране потребовалось выделить велосипедистов отдельно.
Hint
00.00.0000 00:00+16Вполне возможно я не прав, но по-моему слишком длинные названия тоже мешают. Такой код сложнее читать. Пока дочитываешь названия, теряешь локальный контекст (я буквально про текущую строку кода и пару соседних). Это про пример из статьи: avgDeliveryOrderFulfillmentTime.
Например:
avgDeliveryOrderFulfillmentTime = superLongVarNameWithAdditionalInfo + anotherOneLongVarName / 2;И ещё я считаю, что чем меньше область видимости, тем короче могут быть переменные. Нормально же использовать i для цикла. Если функция на 5 строк, то зачем переусложнять (понятно, что иногда бывает нужно, но это исключения).
SimSonic
00.00.0000 00:00+1Добавлю, что читать длинные строки трудно. Вместо того, чтобы читать код в плоскости высота+ширина (и тем более листать вправо), легче воспринимаются более вертикальные, одноразмерные конструкции. IMHO, в примере выше разбиение по строкам несколько помогает.
avgDeliveryOrderFulfillmentTime = superLongVarNameWithAdditionalInfo + anotherOneLongVarName / 2;А вообще, тут ещё режет не длина, а отсутствие смысла. Смесь смысла и не-смысла. Если вместо абстрактных superLongVarNameWithAdditionalInfo и anotherOneLongVarName подставить бизнесовые смыслы, внезапно формула становится эмоционально приятнее.
avgDeliveryOrderFulfillmentTime = avgOrderCookingAndPackagingTime + maxOrderCourierDeliveryTime / 2;Но в целом, конечно, да. Короткие скоупы -- очень хорошо. Иногда и i имеет право на жизнь, хотя я стараюсь всё-таки писать orderId :)
xxlagr Автор
00.00.0000 00:00+1Да, хочется лаконичности. Но это не всегда возможно. Например, когда у вас контракт, состоящий из очень разных метрик. Тогда нужно тащить в нейминге весь контекст этой метрики.
yatanai
00.00.0000 00:00Я использую определения в таком случае. Грубо говоря мой код превращается в
int idx = p_arg; //Index of humanityТакже стараюсь максимально сжимать контекст используя всякие штуки по кодстайлу. Грубо говоря
class Foo { int ref; public: int& GetRefCount(); int& r_ref(); }; //C++Где префикс [r_] означает ссылку на объект. В целом читая код понятно что он делает, но вот с "публичным api" приходится возится.
kt97679
00.00.0000 00:00+4Однажды один бывший коллега писал код слушая ну очень прогрессивную музыку. И названия переменным он давал созвучно песням, которые слушал. Код ушел партнерам и они очень удивились, посмотрев внутрь. После этого в наших билдах повилась проверка, которая назвалась bad_words.
shigorin
00.00.0000 00:00+4> В чём разница между сочинением третьеклассника
> и статьёй в крупном таблоиде?
В сочинении может оказаться правда.
PS: меня как переводчика между несколькими языками и разработчика на ещё нескольких от такого суржика (не путать с терминологией) от подобных текстов малость коробит; искренне желаю научиться говорить красиво, тогда и у кода есть шансы стать красивей.xxlagr Автор
00.00.0000 00:00+1За пожелание спасибо. Но запрошу конкретику:
что конкретно вызывает коробление?
как бы это звучало красиво?shigorin
00.00.0000 00:00+1Да вот прям название статьи (но предназначение «зацепить» оно при этом выполнило :)).
Как думаете — «назови меня тихо по имени» не зацепило бы?
А коробит суржик, как и сказал; впрочем, мне доводилось и тернопольчанам таковой вправлять на месте, зная и ту пару языков тоже (тогда и пришёл к выводу, что суржик скорее индикатор ограниченности, поскольку человек смешивает языки, не зная действительно хорошо ни один из них и даже не замечая этого — т.е. злонамерения нет, но и красоты, о которой статья на самом деле, как мне показалось — тоже).
Не примите как наезд — докапываюсь тогда, когда вижу смысл, и благодарен многим тем, кто за всю мою жизнь там или сям решил, что есть смысл докопаться по делу в мой адрес :)xxlagr Автор
00.00.0000 00:00+2С такой стороны я на свой текст не смотрел. Действительно, выразительные средства языка можно использовать лучше. Хотя отсылка к песне Любэ здесь чуть меньше подходит, на мой взгляд. У русского языка мощная система, она переваривает в себе любые заимствования. Как и любой другой язык он живёт и развивается. Когда-то кандидат филологических наук посоветовал мне не переживать по поводу неуместного употребления слова «одел». Если так удобно, то люди так будут говорить и станет это нормой в языке. Возможно и «суржик» так же приживётся. Заимствованные слова — это ведь не всегда аналоги ещё. Многих терминов в нашем языке просто нет. Или они обозначают что-то похожее, но не в точности то же самое.
Chamie
00.00.0000 00:00+2Как думаете — «назови меня тихо по имени» не зацепило бы?
Не иллюстрировало бы проблему трудностей с неймингом. Вы статьи на Лурке читали? Когда любое явление, если его можно проявить лексически, применяется, собственно, к его описанию. Ну, или, например, слово «ачепятка» — вас тоже коробит?
А в плане именно «зацепило», статья с названием «назови меня тихо по имени» может быть о чём угодно, это название практически не несёт информации. Статья с названием «делай нейминг как сеньор» — точно будет про нейминг в разработке и про проблемы с ним, причём, скорее всего, не самые базовые вещи, очевидные даже джунам. Статьи ни о чём/непонятно, о чём — открывать не хочется. Мало ли о чём оно там будет.
evgsavosin
00.00.0000 00:00+1Не стремитесь называть максимально коротко. Нейминг из 3-4 слов — это нормально. Передать конкретику одним словом, чаще всего, нельзя.
Наоборот имеет смысл стремиться это делать, если мы работаем в рамках одного контекста. Здесь вопрос не в стремлении или любви это делать, а в том, насколько это и вовсе уместно на конкретном участке кода. Если вы используете функциональное программирование, то проблем с неймингом будет в несколько раз выше, чем у объектно-ориентированного, у которого есть возможность задавать контекст в рамках конкретного класса.
Нужно найти золотую середину, чтобы чистота кода не страдала, но, в тоже время, чтобы всё было предельно ясно и понятно.
xxlagr Автор
00.00.0000 00:00С опытом чувствуешь баланс длина/понятность. Но, пока опыта нет, предпочтительнее длинно, чем непонятно.
ProRules
00.00.0000 00:00-5Сразу увидел "basket" вместо cart (корзина на сайте)... Эх знали бы ещё эти мудрецы лучше английский ????♂️
haqreu
00.00.0000 00:00+4
ProRules
00.00.0000 00:00+1А самое смешное кстати Если зайти в "Basket" то там написано https://s.mail.ru/Vbx8/EYydMoXzx Your Amazon Cart is empty
warhamster
00.00.0000 00:00+1Вот этим еще можно рассказать, какие они нутупые: https://dictionary.cambridge.org/dictionary/english/shopping-basket
iBljad
00.00.0000 00:00+5Никогда не забуду нейминг вида
String[] massiveString
aldekotan
00.00.0000 00:00Узнаю свой нейминг! :) Тогда я, после нескольких часов в попытках понять для чего предназначен этот и другие массивы, решил помочь себе хотя бы так. Сейчас понимаю, что решение было опрометчивым.
p.s. потом свои труды передал опытному человеку. Его реакцию трудно передать словами
acordell
00.00.0000 00:00+1Спасибо, полезно. Только вот по моему опыту в крупных многолетних проектах не все так просто. Тут зачастую словарь быстро растет как на дрожжах и становится больше похож на произведения Льва Толстого. При этом ранние произведения не всегда стыкуются с поздними. Да и в бизнесе жизнь же тоже совсем не статична, и туда тоже приходят и уходят целые пласты терминов. Иногда это долетает до словаря. А иногда - нет. Плюс, еще, как правило, есть огромный кусок легаси, который в разные годы писали разные команды, и, ясное дело, каждая со своим видением прекрасного... В итоге к словарю получается нужен толмач. Да не один.
В текущем проекте, переломав немеряно копий, пришли к тому, что верхнеуровневый нейминг - часть задачи. Аналитика с архитектурой предлагает свои варианты, разработка - свои. И это утресаем ровно так же, как и все остальные части задачи. Да, конечно, на переменные внутри методов никто не претендует, но имена сервисов, таблицы, столбцы, интерфейсы совместно продумываются со всех сторон. А когда это есть, и есть понимание, что это важно, то и переменные внутри кода как-то называть NNN народ уже особо не тянет. За джунами, конечно, приглядываешь, но с ростом опыта, люди втягиваются, и постепенно бардака становится меньше.
xxlagr Автор
00.00.0000 00:00+1Практику разделения проекта на домены применяете? Чтобы для каждого свой словарик составлять. В масштабах большого проекта и словарь поддерживать тяжело и разработчики начинают специализироваться больше на каком-то одном участке.
acordell
00.00.0000 00:00Да. Несколько, правда, специфично. Вертикальные срезы, под названием "секция". У нас есть особо толстые клиенты, каждый со своей спецификой, ради которых кастомизируется процесс. За каждым таким закреплена отдельная группа. Плюс есть сами по себе специфические секции, которые даже в рамках другого законодательства работают. Под них тоже отдельные люди. Но за этим всем есть ядро системы, которое все это пытается свести в одно и вынуждено с каждым говорить на его языке.
NNikolay
00.00.0000 00:00+2А давайте вспоминать какой кто видел ацкий нейминг. Мой герой это файл в проекте с именем satya.mp3. Satya это имя разработчика запилившего фичу со звуковым файлом.
acordell
00.00.0000 00:00+4Не знаю годится это в примеры или нет, но я как-то накопал в могучем легаси, среди костей динозавров метод:
bool isJopa() { return true; }Который вызывался там из ряда мест, но больше удивило не это, а, так сказать, безвариантность ситуации. То есть, что бы ты не делал, а всегда ж...
XaBoK
00.00.0000 00:00+1Как то в довелось ревьють комит, где разработчик написал функцию прохождения по дереву для проверки иерархии. Часть параметров наследовалось от родителя, что было противоположно обычному ходу дел. Так что было важно при наличии такого параметра "убедить" детей. Ну и вот вам мультикультурность - в родном языке разработчика говорят не родительская нода, а нода отец. Так что на английском у него получилась функция с именем: LookAmIYourFather.
Я не удержался и часть ревью выглядела так:
Max_Pershin
00.00.0000 00:00Называй переменные понятно. Суть не в английском а чтобы было понятно. И всем. И даже моей бабушке. Если бы вы написали заголовок статьи на русском, я бы считал что вы умеете программировать - поскольку такое имя статьи явно понятнее.
xxlagr Автор
00.00.0000 00:00+1Называй понятно, но как этого добиться? В этом и есть сложность, про это и есть статья. Чтобы было понятно даже бабушке, нужно опереться на какую-то систему, которая уже существует. Изобретение собственных велосипедов, как правило, помогает обогнуть какую-то локальную «неровность» с названиями, но не построить процесс на сотни человек.
Переменные — это про код. Нейминг — шире: код, документация, аналитика, тест-кейсы, события и тд.
Max_Pershin
00.00.0000 00:00Давайте конкретнее. Вот RatePerHour - вот как из названия понять - это какой-то промежуточный коэффициент по которому начисляется зарплата или сумма зарплаты в рублях в час?
xxlagr Автор
00.00.0000 00:00Вы встречали когда-нибудь «промежуточный коэффициент, по которому начисляется зарплата»? Возможно я не в курсе, что такое существует.
Max_Pershin
00.00.0000 00:00Но это же "оценка" дословно и как бы значений много - вот откройте словарь английский напечатанный, там идут варианты перевода по убыванию частоты - и "оценка" будет на первом месте. Но а если коэффициент ъ да, есть, в макдоналдс пока у тебя первые 2 месяца коэффициент 0.75 от зарплаты рядового сотрудника, у сотрудника мак-кафе он 1.2, я могу путаться - но примерно, в выходные помножается вообще у всех по трудовому кодексу.
xxlagr Автор
00.00.0000 00:00Вы всё правильно понимаете. Есть ставка почасовая. Ночью или в праздничные дни применяется повышенный коэффициент, на который умножается ставка. Например коэффициент ночью = 1.2
Да, английский контекстный. Домены помогают однозначно понимать такую терминологию. RatePerHour находится внутри домена Incentives.
skywalk7
00.00.0000 00:00+2var avgWaitingTime = 2000; // FIXME rename to avgHeatedShelfTimeВидно, что писал джуниор, сеньор напишет
avgHeatedShelfTimeInMs, ну или использует специальный тип для хранения TimeDelta.xxlagr Автор
00.00.0000 00:00Замечание справедливое, но мы так сознательно сделали. Во всём API возвращаем TimeSpan в секундах и пишем этот момент везде в спецификациях. Внутри системы мы оперируем типом TimeSpan.
XaBoK
00.00.0000 00:00+3Хорошо и по делу. Правильный нейминг - это уже документация. Код читается легко и понятно, что он делает. Спорный момент в "избыточности".
basketId: 0, // FIXME rename to idВозможно мой опыт связан с определенными платформами и языками, но я оооочень рекомендую избегать ambiguous naming. Особенно с такими полями как id и name. Иначе обработка полиморфных коллекций и всякие linq будут источником проблем в долгосрочной перспективе. Каждый рефакторинг будет головняком. То же относиться и к запросам в бд. Имя кого и чего почти всегда не понятно из контекста при массовой обработке данных.
xxlagr Автор
00.00.0000 00:00+1Тоже так делаем. Если в объекте есть несколько идентификаторов и имён, то лучше добавить контекста.
wibotwi
00.00.0000 00:00Согласен. Меня тоже смутило это. clang-tidy например выдаёт ворнинг если название переменной меньше 3 символов. Зачастую такие поля кладутся в базы данных, где очень удобно делать natural join. Также они могут отправляться по сети, или в названия форм на вебке. Постоянно перекладывать в коде из id в basketId и обратно неудобно. Так же слово basketId удобно делать поиск по всем файлам, включая и код и документацию и csv файлы с данными для тестов. Слово id грепать будет то еще удовольствие.
Aldrog
00.00.0000 00:00Зачастую такие поля кладутся в базы данных, где очень удобно делать natural join.
В БД я не эксперт, но даже если там действительно удобнее иметь поле basketId, почему бы не сделать перебрасывание id<->basketId в хранимых процедурах? Как-то странно менять именования в коде приложения ради небольшого удобства DBA.
Также они могут отправляться по сети, или в названия форм на вебке.
А что плохого в отправке json вида
{"basket":{"id":1234,...?Так же слово basketId удобно делать поиск по всем файлам, включая и код и документацию и csv файлы с данными для тестов. Слово id грепать будет то еще удовольствие.
В любом современном редакторе кода можно сделать поиск использований символа. Единственный минус — не найдёт упоминания в комментариях и в коде, тем или иным образом выключенном из проекта.
Ну и если у вас язык с динамической типизацией, то могут быть проблемы.
wibotwi
00.00.0000 00:00Хранимые процедуры не во всех БД есть, и переименовывать в них что-то это безобразие, такой костыль потом никогда не найдешь.
И идея была не "менять код ради БД" а "именовать сущность везде одинакого, включая код, документацию, БД, и так далее". Даже в Slack если я спрошу какой id у вас застрял, меня не поймут если я не уточню что это basketId.
А причем тут json? Речь была про разные плоские протоколы, где нет объектов.
Впервые слышу про любой современный редактор который умеет искать символ в документации (файле README или еще каком тестовом формате типа Tex), в CSV файлах, в XML файлах. В таких файлах даже человек не сразу поймет про какое id идет речь.
Aldrog
00.00.0000 00:00Вся ваша аргументация имеет смысл только при условии, что вообще все поля всех сущностей во всём проекте имеют уникальные имена. На мой взгляд, отслеживать это крайне непрактично и бессмысленно.
И что будете делать, если в ваш стек понадобится добавить язык или протокол, не поддерживающий принятый у вас формат именования? Например, не имеющий case sensitivity, а у вас всё в camelCase.Гораздо разумнее определить простые и однозначные правила конвертации имён для тех случаев, где нужна уникальность или другие особые правила именования. Например, для передачи по плоскому протоколу нескольких объектов, на уровне сериализатора добавляйте к каждому полю имя объекта или типа.
Даже в Slack если я спрошу какой id у вас застрял, меня не поймут если я не уточню что это basketId.
Так спрашивайте про
basket.id. И в документации пишите и ищите не простоid, аbasketиbasket.id. Естественно, простоidдолжен встречаться только в контексте описания самой сущностиbasket, где из контекста и так очевидно, что это заid.
Artem_7
00.00.0000 00:00+2Спасибо за статью. Забавно, что инвайт на Хабр я получил 10 лет назад именно за статью о нэйминге (https://habr.com/ru/post/207102/). Я уже и сам не согласен с частью правил, которые там озвучил. Но большинству следую и по сей день (да, устав бороться с разработчиками, я ,в итоге, сам стал разработчиком).
Стикеры в тему:
"Нэйминг - это фундамент, на котором возводится небоскреб проекта. "
"Не умеешь в нэйминг - меняй профессию"
"Театр начинается с вешалки, а программирование с нэйминга"
xxlagr Автор
00.00.0000 00:00+3Спасибо, что поделились. Я искал подобные статьи, но слово «именования» для поиска не использовал, поэтому статью не видел. Вот такая ирония про нейминг.
Artem_7
00.00.0000 00:00+1Ирония в том, что слово "нейминг" - это транслитерация, которая является антипаттерном при "нэйминге" :) Поэтому я использовал русское слово "именование" в названии статьи. Но плакат назвал Naming Convention. Ирония в квадрате :)
astypalaia
00.00.0000 00:00+1проблемы с неймингом → проблемы с пониманием предметной области
"Истину глаголишь, боярин" (с). Вот прямо сейчас я вынужден отклонять код ревью по причине не понимания разработчиком предметной области. А всего-то казалось делов: взять нужный ISO стандарт, выделить из него суть, и перенести эту суть в код в виде именованных констант. Но нет.
А статья хорошая, спасибо! В смысле все это так или иначе описано в разных известных трудах, но лишний раз навести порядок в мозгу - никогда не повредит.
Tyusha
00.00.0000 00:00Вопрос к спецам (я не профи, программирую по необходимости в научной работе). У меня часто возникают затруднения (скорее внутренний дискомфорт):
1). слово number в названии переменной можно трактовать, как общее количество чего либо, а можно как порядковый номер?
2). Наименование массивов давать во множественном числе или в единственном? Например при инициализации var shops = [ 'Василёк', 'Ромашка', ... ] — выглядит органично. Но там где обращаюсь к конкретному элементу, выглядит уже странно shops[ i ]. Зато хорошо читается конструкция for ( shop in shops ).
Однако часто вижу использование единственного числа в наименовании массивов в довольно прилично написанном и авторитетном коде. Как правильно?
xxlagr Автор
00.00.0000 00:00По поводу number уже ответили дельно, это специфичное слово, лучше его как «суффикс» не использовать.
По поводу множественного числа, пусть вас не смущает. Например в наименованиях путей в REST очень рекомендуется использовать множественное число: /shops/{id}. Что и в случае с REST, когда у нас есть «каталог» с сущностями, так же и с массивом, который содержит сущности, действует принцип вложенности и отражается в наименованиях.
ookami_kb
00.00.0000 00:00+2Общее количество – обычно
countилиqty. Порядковый номер –index, может ещеposition.Или
shops, илиshopList. Простоshopдля массива – имхо, вводит в заблуждение.shops[i]не выглядит странно – это, по сути, "первый из магазинов", "второй из магазинов", вполне органично.
vadim_bv
00.00.0000 00:001) количество — можно amount, amt; порядковый номер — ordinal, ord (ну и num тоже видел)
2) нужно во множественном числе: как раз сразу будет понятно, что речь идёт о массиве/списке.
murad88
00.00.0000 00:00+2До сих пор помню
`bool _isOnlyTrue = true;`
XaBoK
00.00.0000 00:00А как было бы круто если б `bool _isOnlyTrue = false;`
Приходилось видеть всякие константы типа DoNotChangeThisValue с историей изменении чуть ли не каждый день и FirstFunctionToCall где-то в середине списка вызовов в Main... Тот самый вариант бездумного нейминга, когда имя идёт вместо коментария, а смысл и суть функции/переменной остаются загадкой. Просто очередное Magic Value.
MSBlast
00.00.0000 00:00Статью в принципе можно сократить - хорошему программисту необходимы хорошие знания английского языка.
Simpre_falta_algo
00.00.0000 00:00Хорошему специалисту (необязательно программисту) необходимы адекватные знания.
xxlagr Автор
00.00.0000 00:00+1Идея статьи не в этом. Нет серебрянной пули, чего-то одного, что всё решит. Инженеру обязательно погружаться в предметную область. Хорошее знание языка сильно поможет, но не решит проблему с неймингом. И инструменты, как системно работать с неймингом, как продавать эту идею, как поддерживать.
comdivuz
00.00.0000 00:00+2Про basketId - вот не всегда, особенно если это сущность из базы. В БД часто из-за объединений в таблицах делают явные имена полей и их лучше и в коде такими оставить. Также часто бывает, что тип ид это что-то известное, типа cardId какого то, а сущность типа CartHandler синтетическая, и лучше оставить некоторую избыточность, но узнавабелтность. Но статья хорошая много тем закрывает, но 99% назовут поле с ИНН inn, а не tin и будут правы, если софт для России. Всё же главное это конвенции и простота и однозначность прочтения.
uszer
00.00.0000 00:00Как правило, для переменных использую общий подход: первые два символа - тип переменной. Следующие два-три символа - "имя" переменной (как правило - бз глснх). Если переменная используется в функции, текст которой помещается на экран целиком - переменные (особенно "временные", и интенсивно используемые) вообще могут быть в одну букву. Такой подход резко сокращает "геометрические" размеры кода. Наверное, я не думаю о будущих поколениях. Но мне нравится так и эта ламповая вкусовщина уходит корнями в прекрасное далёко, когда символами на переменные не разбрасывались.
nnikolaev
00.00.0000 00:00+1У вас динамический язык программирования, или IDE не показывает тип переменной? Не совсем понимаю зачем сейчас использовать тип переменной в её названии. Вы не используется минификаторы кода? Зачем так жёстко сокращать имена переменных?
uszer
00.00.0000 00:00К сожалению или счастью - сейчас практически не приходится пользоваться никакими "продвинутыми" IDE (mc editor и notepad++ - не в счет).
steaze
00.00.0000 00:00Часть советов уже применял, но всё равно статья полезная, иногда нужно почувствовать, что делаешь правильно, а не как советуют коллеги. Сомнения только возникают когда получаешь, например, даты диапазона с фронта: start и end, в DateTime преобразую уже в startAt и endAt. Ещё сомневаюсь в правильности использования Get при получении данных. По идее это действие, как Add*, Remove* и др. Но когда методов Get* набирается уже больше десяти, начинаешь задумываться, правильно ли так писать.
xxlagr Автор
00.00.0000 00:00StartAt — ’начинать в ’, по-человечески лучше в прошедшем времени. Или мы используем periodFrom, если это фильтр. Просто start для временного отрезка не самый удачный выбор. Да и без разницы фронтенд или бекенд —суффиксы нужны.
Для методов REST есть описанные стандарты.
Tab10id
00.00.0000 00:00+1Моё "любимое" с текущего места работы:
перевели слово "выгрузка" (csv, xml) как "unloading".
Проросло.
babysas
00.00.0000 00:00+2Статья зашла. Включу "встречу по неймингу" в начало работы. Занимаюсь продуктовой аналитикой, naming convention - это обязательная часть работы по разметке продукта событиями и свойствами.
Самая популярная ошибка - разные названия для одних и тех же сущностей, в мой работе это баг, который "как правило" не позволяет делать фильтрацию/разбивку данных или делает ее очень трудоемкой (зависит от инструмента)
Понимание "зачем нужно внятно называть" приходит при просмотре действий пользователей - если с неймингом беда - интерпретировать очень трудоемко.
astypalaia
Еще одна иллюстрация старой истины: в программировании только две проблемы - именование переменных и инвалидация кэша.
А вообще за четверть века в профессиональной разработке я понял, что глобально у кода есть только одна характеристика: человек думал о том, что он кодит, или не думал, а еще точнее - человеку нравится его работа или лишь бы поскорее этот клятый тимлид наконец от меня отстал (в частности с вопросом почему у тебя сущность называется Pizza, хотя на самом деле это Cappuccino - ведь компилятору вообще без разницы)
DrGluck07
Ещё круглые кнопки на Delphi.
alexxz
Это какой-то мем?
DrGluck07
На любом форуме по Дельфям в начале нулевых было много вопросов на тему "как сделать кнопку круглой/овальной/любой формы".
voidMan
И хренова куча сторонних компонентов на эту тему)
shigorin
В разрезе «ремесленник/мастер» оказались интересны "Раздумья ездового пса" В.В. Ершова… можно по ключевым словам «мальчик на тойоте» глянуть именно те места.
Ещё хорошо выходит, когда получается понять задачу на своём месте, глазами заказчика и в шкуре того, кому с этим непосредственно работать — для такого бывает полезно не ограничиться ТЗ, а провести денёк с будущими пользователями, примечая то, что в ТЗ бы попросту не попало, но выяснялось на ходу (это в случае заказной разработки, конечно — хотя и при продуктовой могут быть случаи, когда первые желающие уже известны).
anwender95
Дополню:
В программировании две проблемы — именование переменных, инвалидация кэша и ошибка на единицу)
Tasta_Blud
а как же разыменование нулевого указателя (оно же NullReferenceException), деление на ноль и самое страшное - утечки памяти?
(впрочем, я слишком молода и, возможно, не распознала мем)
mukhinid
Таки-да, мемом является фраза про инвалидацию кеша и именование пременных, а уж на её основе родилась куча вариаций: https://martinfowler.com/bliki/TwoHardThings.html
khajiit
Naming (things) это еще и перечисление. Две сложные вещи: инвалидация кеша и перечисление вещей.
Отчего шутка становится более программистской.
Lukerman
Done)