Дело в том что там строки к числам были преобразованы, это дает ускорение при сравнении, сравнение строк значительно более медленная операция, вроде как достаточно очевидно
То что код на английском - стандарт я знаю, вопрос в другом, а правильно ли это? ведь все рекомендации к разработке в первую очередь предназначены для них, а весь мир подстраивается, к примеру, если бы у нас была развита информатика как в штатах, мы в нашу сферу влияния могли бы войти славянские страны и те кто кириллицу использует
В DDD есть принцип Единный Язык (Ubiquitous Language)
Эксперты предметной области (Domain Experts) и разработчики программного обеспечения работают вместе, чтобы создать общий язык для разрабатываемых бизнесс-сфер. Тут не может быть противопоставления, это единная команда. Разработка программного обеспечения это инвестиция в бизнес, а не просто статья расходов. Усилия, прилогаемые к созданию Единого Языка (Ubiquitous Language), помогают распространить глубокое понимание Домена (Domain) среди всех членов команды.
и выходит так что эта часть не работает вне англоязычных странах, потому что будет все равно 2 языка, англ и национальный язык
Единный Язык (Ubiquitous Language): Эксперты предметной области (Domain Experts) и разработчики программного обеспечения работают вместе, чтобы создать общий язык для разрабатываемых бизнесс-сфер. Тут не может быть противопоставления, это единная команда. Разработка программного обеспечения это инвестиция в бизнес, а не просто статья расходов. Усилия, прилогаемые к созданию Единого Языка (Ubiquitous Language), помогают распространить глубокое понимание Домена (Domain) среди всех членов команды.
вот не опытному было бы проще даже без понимания, просто поискать по названию бизнес-сущности, а не по ее переводу, тем более как ниже указали есть британский и американский англ, в которых одно и тоже будет называться по разному
Дело не в знании англ, я специально подчеркнул про бизнес-логику, однозначный перевод бизнес терминов на англ довольно сложно перевести, ИНН какой-нибудь к примеру, склад тоже может быть как store или warehouse, и это только что-то простое, а если бизнес связан с медициной, там нужны специфичные знания англ.
чуть более сложных названий можно ссделать комментарий на русский, но его его придется дублировать в гетерах/сеттера/dto
Задачи ставит бизнес на русском вот и выходит бессмысленный перевод туда-сюда, перевод ради перевода
А зачем вообще переводить на англ? если бизнес на русском и разработчики тоже русскоязычные, было бы логичней писать бизнес-логику на русском, а не мучаться со словарями для терминов
Писать на русском не привычно, но код внезапно был бы более понятный чем couriersShiftsDuration, ordersPerCourierLabourHour, Health permit, Nutrition facts
Как-то все упускают один момент из виду, бизнес-логику есть смысл описывать в русских терминах, чтобы туда-сюда это все не переводить, особенно если следовать DDD
Дело в том что там строки к числам были преобразованы, это дает ускорение при сравнении, сравнение строк значительно более медленная операция, вроде как достаточно очевидно
кому необходим его знают)
в России достаточно материала на русском чтобы стать программистом без знания англ, а дальше гул транслейт в помощь
А зачем его вообще делали?
То что код на английском - стандарт я знаю, вопрос в другом, а правильно ли это? ведь все рекомендации к разработке в первую очередь предназначены для них, а весь мир подстраивается, к примеру, если бы у нас была развита информатика как в штатах, мы в нашу сферу влияния могли бы войти славянские страны и те кто кириллицу использует
1) в русском и так часто есть вкрапления английских слов, например e-mail, Mysql, XML, HTTP, KFC, McDonalds и др слова, бренды и аббривиатуры
2) я против транскрипции, мы же не поляки
3) ваш пример выглядел бы так:
обработчик->вОчередь(платежка)
или вроде тогоUPD для добавления внешних библиотек в целом стоит использовать свои интерфейсы см паттерн мост (Bridge)
Экстракорпоральное оплодотворение (ЭКО), штрихкод, Контрольно-кассовая машина (ККМ)
В DDD есть принцип Единный Язык (Ubiquitous Language)
Эксперты предметной области (Domain Experts) и разработчики программного обеспечения работают вместе, чтобы создать общий язык для разрабатываемых бизнесс-сфер. Тут не может быть противопоставления, это единная команда. Разработка программного обеспечения это инвестиция в бизнес, а не просто статья расходов. Усилия, прилогаемые к созданию Единого Языка (Ubiquitous Language), помогают распространить глубокое понимание Домена (Domain) среди всех членов команды.
и выходит так что эта часть не работает вне англоязычных странах, потому что будет все равно 2 языка, англ и национальный язык
Единный Язык (Ubiquitous Language): Эксперты предметной области (Domain Experts) и разработчики программного обеспечения работают вместе, чтобы создать общий язык для разрабатываемых бизнесс-сфер. Тут не может быть противопоставления, это единная команда. Разработка программного обеспечения это инвестиция в бизнес, а не просто статья расходов. Усилия, прилогаемые к созданию Единого Языка (Ubiquitous Language), помогают распространить глубокое понимание Домена (Domain) среди всех членов команды.
вот не опытному было бы проще даже без понимания, просто поискать по названию бизнес-сущности, а не по ее переводу, тем более как ниже указали есть британский и американский англ, в которых одно и тоже будет называться по разному
Дело не в знании англ, я специально подчеркнул про бизнес-логику, однозначный перевод бизнес терминов на англ довольно сложно перевести, ИНН какой-нибудь к примеру, склад тоже может быть как store или warehouse, и это только что-то простое, а если бизнес связан с медициной, там нужны специфичные знания англ.
чуть более сложных названий можно ссделать комментарий на русский, но его его придется дублировать в гетерах/сеттера/dto
Задачи ставит бизнес на русском вот и выходит бессмысленный перевод туда-сюда, перевод ради перевода
А зачем вообще переводить на англ? если бизнес на русском и разработчики тоже русскоязычные, было бы логичней писать бизнес-логику на русском, а не мучаться со словарями для терминов
Писать на русском не привычно, но код внезапно был бы более понятный чем couriersShiftsDuration, ordersPerCourierLabourHour, Health permit, Nutrition facts
В DDD постулируется, что нужно писать на языке бизнеса, а если бизнес не англоязычный и алфавит не латинский?
Как-то все упускают один момент из виду, бизнес-логику есть смысл описывать в русских терминах, чтобы туда-сюда это все не переводить, особенно если следовать DDD