Есть же DDD, который требует наличие единого языка в рамках домена. С этим, кстати, есть интересная проблема -- одна и та же, по сути, сущность реального мира, по-разному называется в каждом отделе, а значит имеет и разные названия на уровне кода. Например в одном из последних проектов у нас было так, что пользователи системы обозначались десятком разных терминов, так как каждый отдел называл их по-разному, соответственно у нас в коде эти сущности были обозначены как Lead, Customer, User, Client, Partner и т.д. При том, что, например, Partner для одного отдела это клиент компании, а для другого отдела тоже есть сущность Partner, которая обозначает уже поставщика. С Customer и Lead тоже так -- для кого-то Lead это клиент компании, а для кого-то клиент клиента компании. Но при всей внешней сложности это сильно упрощает взаимодействие команды разработки с остальными отделами компании.
В своём видео я больше говорю, не то что программисты говорят друг другу, а например, мы работаем по скраму и у нас каждый день общие мероприятия, как между собой, так и с участием заказчика, например: каждый день с утра "стендап" где разработчики рассказывают что сделала и что будут делать сегодня (на этой встрече кучу людей не только разработчики. 1н раз в неделю "груминг" это когда с заказчиком разбираем что конкретно нужно делать в задачах из бэклога. 1н раз в 2е недели мы делаем демонстрацию что было сделано, тут вообще кучу людей от заказчика. Я молчу что на всех встречах аналитики, разные руководители и т.д. И ТЕПЕРЬ ПРЕДСТАВЛЯЕТЕ РАЗРАБОТЧИК НАЧИНАЕТ С ЭТИМИ ЛЮДБМИ ГОВОРИТЬ КАК НА КОРЕЙСКОМ? Они ничего не понимают. Поэтому даже если в в общении между собой будете говорить простыми словами - это только улучшит ваше общение между разработчиками, не говоря об общении с аналитиками, заказчиками, руководителями.
@@Kulibins1 а я и не говорил ничего про общение между программистами, я и говорю про DDD. Этот подход как раз и подразумевает Единый Язык Домена, то есть единую терминологию в рамках конкретного бизнес-процесса и не важно кто участвует в бизнес-процессе -- программисты, менеджеры, бухглатера, директора - это сути дела не меняет и на термины влиять не должно. При чем терминология должна быть ориентирована именно на бизнес-процессы реального мира. То есть если в реальном мире конкретный отдел называет пользователя Клиент, то и в коде модуля для этого конкретного бизнес-процесса, сущность должна называться Client. То же самое и с действиями/событиями. Если в реальном мире процесс называется "отгрузка заказа", то и в коде метод должен называться "shipmentOfOrder". Отсюда и возникает ситуация, когда вроде бы одно и то же действие или одна и та же сущность имеют несколько разных названий, так как названия ориентированы на терминологию тех отделов, для которых создавались эти компоненты системы. Этой методологии уже лет 20, если не больше
@@mclotos Вот и в разговоре не нужно говорить "шипмент оф ордер" а нужно говорить "отгрузка заказа", а разработчики часто начинают говорить английскими терминами, вот что так делать не нужно и суть моего видео.
@@Kulibins1 да. это максимально тупо. Хотя зависит от компании. Я вот работал в нескольких компаниях, где менеджеры вполне себе говорили терминами на английском языке и так им было проще, поэтому отделу разработки пришлось учить инглиш, чтобы понимать манагеров =)))
Вы приводите какие-то очень специфичные редкие случаи, когда с заказчиком нужно говорить о потоках. Обычно с заказчиком происходит обсуждение именно его заказчика предметной области и оно происходит в специфичных терминах именно заказчика, а не программиста. С менеджерами разговариваем на менеджерском: таски, перформанс, дедлайн и т.п. Никто не умер от общения на менеджерском. Ну, а программистам в идеале бы только на английском бы и разговаривать. От этого становится лучше нейминг обьектов в коде и следовательно кратно улучшается читаемость кода, легче понимать назначение объектов и функций, сильно упрощается поддержка кода. К тому же проще коммуницировать с коллегой из любой точки мира.
Пишу микросервис по автозапчастям. На русскоязычных сайтах я заметил что , путь к ресурсам в URL описаны русскими словами. Пример ".../maslyanye-nasosy-i-detali-k-nim/" В коммерции так можно делать?
А кто запрещает? им как удобно так и делают. Главный критерий это что бы код работал без багов, 2) это масштабируемость 3) это производительность. А уж формализованность по возможности, но это моё мнение, кто-то меня за это дико раскритекует
Всем привет, выбираю между двумя языками C# и Go, учить собираюсь для back-end. С шарпом уже знаком, учил на 2 курсе универа, знаю на уровне до ООП. Можно ли начинать свой путь в IT с Go или лучше продолжить учить C# и пытаться найти свою первую работу с ним?
Учи реально что нравится. Go можно буквально за один день весь "выучить" (без фреймварков и библиотек), c# гораздо продвинутей и сложнее соответственно. Главное это знания библиотек/фреймворков и опыт. Мне конечно больше c# нравится
Чтобы говорить одинаково, как раз и надо использовать английские названия. Переводов может быть несколько, а у некоторых терминов вообще нет устоявшихся переводов.
Как раз и вижу очумело-удивлённые лица заказчиков, когда разработчик пытается им что-то объяснить, поэтому и нужно именно говорить проще, кроме того многие термины были придуманы у нас, а уж потом их "придумали" и там.
Программирование должно быть только на англ, на русском все таки смешно. Особенно комментарии на русском в коде, это, конечно дно адовое. Нравится русский - пишите на 1С. Вся литература и цивилизованный мир говорит на английском. Лично, я, когда входил в программирование уже свободно владел английским. Return переводят на русский, как возвращать. Т.е. что-то брало в долг и затем возвращало. Поэтому, чтобы не возникало такого идиотизма нужен английский. Русский и программирование - это как молоток из пластилина. С русскими/российскими компаниями вообще лучше не связываться, хотят платить в деревянных и даже слышать о USDT не хотят.
@@exactly4234 а почему я должен писать комментарии на английском? в коде который никогда не будет использоваться в международном проекте? Кроме того я не носитель английского, как и многие. Я даже больше скажу 1) у нас служба безопасности завернула всех соискателей кто был релокантом и вернулся, 2) кто даже просто работал на иностранную компанию. И кстати есть требование к коментированию кода, комментирая на английском 100% команды должно свободно владеть английским писменным, что не реализуемо, я провёл >100 собеседовпний и народ на элементарные вопросы не отвечает, не то что свободное знание английского. ЗЫ: комментарии не пишутся: "цикл", "возвращать" и т.д.
Умение объяснять технические вещи человеческим языком - это хороший скилл, ой то есть навык 👍
Давно не было роликов. Ждём ещё.
Через неделю буду в отпуске, запиши побольше.
шикарный офис! :))
Этот офис дома 😁, вон даже лежанка, моего сабачка, а он сбежал не захотел сниматься
Полностью согласен! Правильная и важная тема 👍
Александр, купи петличку за 3-4 тыс рублей, +50% к качеству подачи материала будет если не больше
Петличка есть. хотел попробовать записать на insta 360.
Есть же DDD, который требует наличие единого языка в рамках домена.
С этим, кстати, есть интересная проблема -- одна и та же, по сути, сущность реального мира, по-разному называется в каждом отделе, а значит имеет и разные названия на уровне кода. Например в одном из последних проектов у нас было так, что пользователи системы обозначались десятком разных терминов, так как каждый отдел называл их по-разному, соответственно у нас в коде эти сущности были обозначены как Lead, Customer, User, Client, Partner и т.д.
При том, что, например, Partner для одного отдела это клиент компании, а для другого отдела тоже есть сущность Partner, которая обозначает уже поставщика. С Customer и Lead тоже так -- для кого-то Lead это клиент компании, а для кого-то клиент клиента компании.
Но при всей внешней сложности это сильно упрощает взаимодействие команды разработки с остальными отделами компании.
В своём видео я больше говорю, не то что программисты говорят друг другу, а например, мы работаем по скраму и у нас каждый день общие мероприятия, как между собой, так и с участием заказчика, например: каждый день с утра "стендап" где разработчики рассказывают что сделала и что будут делать сегодня (на этой встрече кучу людей не только разработчики. 1н раз в неделю "груминг" это когда с заказчиком разбираем что конкретно нужно делать в задачах из бэклога. 1н раз в 2е недели мы делаем демонстрацию что было сделано, тут вообще кучу людей от заказчика. Я молчу что на всех встречах аналитики, разные руководители и т.д. И ТЕПЕРЬ ПРЕДСТАВЛЯЕТЕ РАЗРАБОТЧИК НАЧИНАЕТ С ЭТИМИ ЛЮДБМИ ГОВОРИТЬ КАК НА КОРЕЙСКОМ? Они ничего не понимают. Поэтому даже если в в общении между собой будете говорить простыми словами - это только улучшит ваше общение между разработчиками, не говоря об общении с аналитиками, заказчиками, руководителями.
@@Kulibins1 а я и не говорил ничего про общение между программистами, я и говорю про DDD. Этот подход как раз и подразумевает Единый Язык Домена, то есть единую терминологию в рамках конкретного бизнес-процесса и не важно кто участвует в бизнес-процессе -- программисты, менеджеры, бухглатера, директора - это сути дела не меняет и на термины влиять не должно. При чем терминология должна быть ориентирована именно на бизнес-процессы реального мира. То есть если в реальном мире конкретный отдел называет пользователя Клиент, то и в коде модуля для этого конкретного бизнес-процесса, сущность должна называться Client. То же самое и с действиями/событиями. Если в реальном мире процесс называется "отгрузка заказа", то и в коде метод должен называться "shipmentOfOrder". Отсюда и возникает ситуация, когда вроде бы одно и то же действие или одна и та же сущность имеют несколько разных названий, так как названия ориентированы на терминологию тех отделов, для которых создавались эти компоненты системы. Этой методологии уже лет 20, если не больше
@@mclotos Вот и в разговоре не нужно говорить "шипмент оф ордер" а нужно говорить "отгрузка заказа", а разработчики часто начинают говорить английскими терминами, вот что так делать не нужно и суть моего видео.
@@Kulibins1 да. это максимально тупо. Хотя зависит от компании. Я вот работал в нескольких компаниях, где менеджеры вполне себе говорили терминами на английском языке и так им было проще, поэтому отделу разработки пришлось учить инглиш, чтобы понимать манагеров =)))
Вы приводите какие-то очень специфичные редкие случаи, когда с заказчиком нужно говорить о потоках. Обычно с заказчиком происходит обсуждение именно его заказчика предметной области и оно происходит в специфичных терминах именно заказчика, а не программиста.
С менеджерами разговариваем на менеджерском: таски, перформанс, дедлайн и т.п. Никто не умер от общения на менеджерском.
Ну, а программистам в идеале бы только на английском бы и разговаривать. От этого становится лучше нейминг обьектов в коде и следовательно кратно улучшается читаемость кода, легче понимать назначение объектов и функций, сильно упрощается поддержка кода. К тому же проще коммуницировать с коллегой из любой точки мира.
Я написал в описании ролика про то как так получается что приходится говорить простыми словами.
Шедулер и скедулер - это англ и американская формы произношения
Не знал, думал, что сказали как пишется. Американцы наверное как мы, точно так же каверкают слова 🤣
Скеджюлер )
нет такого произношения ни в британской версии английского, ни в американской, ни в киви, ни в оззи, не нужно выдумывать.
Пишу микросервис по автозапчастям. На русскоязычных сайтах я заметил что , путь к ресурсам в URL описаны русскими словами. Пример ".../maslyanye-nasosy-i-detali-k-nim/"
В коммерции так можно делать?
А кто запрещает? им как удобно так и делают. Главный критерий это что бы код работал без багов, 2) это масштабируемость 3) это производительность. А уж формализованность по возможности, но это моё мнение, кто-то меня за это дико раскритекует
@@Kulibins1 Спасибо.
Всем привет, выбираю между двумя языками C# и Go, учить собираюсь для back-end. С шарпом уже знаком, учил на 2 курсе универа, знаю на уровне до ООП. Можно ли начинать свой путь в IT с Go или лучше продолжить учить C# и пытаться найти свою первую работу с ним?
Учи реально что нравится. Go можно буквально за один день весь "выучить" (без фреймварков и библиотек), c# гораздо продвинутей и сложнее соответственно. Главное это знания библиотек/фреймворков и опыт. Мне конечно больше c# нравится
Чтобы говорить одинаково, как раз и надо использовать английские названия. Переводов может быть несколько, а у некоторых терминов вообще нет устоявшихся переводов.
Как раз и вижу очумело-удивлённые лица заказчиков, когда разработчик пытается им что-то объяснить, поэтому и нужно именно говорить проще, кроме того многие термины были придуманы у нас, а уж потом их "придумали" и там.
Вам надо что-то делать с микрофоном. Это издевательство над ушами слушателей😢
этот звук с камеры. я решил проверить, как будет. буду на микрофон следующие записывать
@@Kulibins1 за видео спасибо. Всё по существу.
Программирование должно быть только на англ, на русском все таки смешно. Особенно комментарии на русском в коде, это, конечно дно адовое. Нравится русский - пишите на 1С. Вся литература и цивилизованный мир говорит на английском. Лично, я, когда входил в программирование уже свободно владел английским. Return переводят на русский, как возвращать. Т.е. что-то брало в долг и затем возвращало. Поэтому, чтобы не возникало такого идиотизма нужен английский. Русский и программирование - это как молоток из пластилина. С русскими/российскими компаниями вообще лучше не связываться, хотят платить в деревянных и даже слышать о USDT не хотят.
@@exactly4234 а почему я должен писать комментарии на английском? в коде который никогда не будет использоваться в международном проекте? Кроме того я не носитель английского, как и многие. Я даже больше скажу 1) у нас служба безопасности завернула всех соискателей кто был релокантом и вернулся, 2) кто даже просто работал на иностранную компанию. И кстати есть требование к коментированию кода, комментирая на английском 100% команды должно свободно владеть английским писменным, что не реализуемо, я провёл >100 собеседовпний и народ на элементарные вопросы не отвечает, не то что свободное знание английского. ЗЫ: комментарии не пишутся: "цикл", "возвращать" и т.д.