Привет! Ты с нуля или уже имеется другой опыт разработки? Я вот начинаю с нуля, сейчас чтобы не распыляться на все - прохожу курс на степике и некоторые темы полтягиваю на Ютьюбе. Как у тебя проходит обучение?
Ещё не смотрела данное видео, но смотрела другие. Хочу выразить вам огромную благодарность за ваш труд и креативный подход к обучению❤. У вас реальный талант учителя, всегда полезно и понятно, почти с первого раза! Наверное единственный канал с колокольчиком у меня 😂
26:10 - всё, не выдержал! там другой книжки не хватает.. третья должна быть "чистый прожект менеджер" а ну и четвёртую можно - "чистый заказчик"! конфликт интересов.. капиталистических на лицо! если вам удаётся работать в условном БМВ у которого денег завались на нормальный инженеринг - это прекрасно. это замечательно.. вопрос неправильно стоит- не "почему" - а "ГДЕ" возникает плохой грязный код? там где его берут, там где его покупают. там где ему "место". посмотрев первую треть могу переформулировать вашу тему так - "пишите хороший код, даже если за это вам не платят." как вам такой заголовочек? вот попробуйте ответить теперь на вопрос - зачем комуто это делать. за плохой код - платит (расплачивается) заказчик. да и за хороший - тоже заказчик! заказчик ( госплан, рынок, капиталист, дядя вася ) - определяет, задаёт планку качества продукции. обладая идеей, целью, ресурсами для её реализации. заказчик ставит цель нанимает (или сам является) тех диром тех дир - нанимает толковую команду, которой ставит толковые задачи, и строго с них спрашивает и вуаля! у вас ест место где может появится хороший код программисты тут как птицы. есть зерноядные, есть насекомо. вы обсуждаете как птицам сменить рацион. сделав волевое усилие. чтобы походить на других. как воробьям ловить рыбу в море клювом. а это вообще не тот процесс. вы сделайте нужный тип кормушки, в нужных условиях - а дальше черёд за появлением нужных Вам птиц.
❤ Если у вас есть желание поддержать развитие канала: www.patreon.com/tuzov boosty.to/nikolay.tuzov 👾 Мой канал в Telegram: t.me/ntuzov 🗣 Наш чат: t.me/+zsSZ63wEJDs3NGVi - здесь присутствуют участники всех выпусков 👀 Golang Digest: t.me/golang_digest - мои регулярные подборки интересных материалов по Go.
1:28:38 Очень странное утверждение, что логировать внутри функции не нужно, а достаточно wrap'ить ошибку и возвращать. Этим можно обойтись, если вы собираетесь логировать только level=Error, но как быть с Debug/Info? Кроме того в лог ты часто можешь дать сильно больше информации, в т.ч распечатать весь объект/стейт и тд, что оборачивать в ошибку не станешь. В остальном между передать logger через ctx или request_id через ctx и инжектить внутри разницы действительно немного, но вот некоторые доводы: обычный go context.Context имеет сложность O(N) на get, а это означает, что если вам в логе нужны не 1 поле, я 5-10, вы постоянно делаете это за O(N), что конечно время мизерное, но не забывайте устройство context.Context и его вложенную природу, это может быть весьма затратно искать в нем key..
Не в первый раз смотрю вас, ребята. Очень приятная атфосфера, компетентные люди. Но: почти два часа я ждал системные рекомендации по чистому коду в Go (переложение книги дяди Боба для гоферов) и так и не дождался, к сожалению. Какие-то фрагменты были, но тема не раскрыта, как мне кажется. Повторите, пожалуйста :)
Метрики оценки "чистого" кода все же существуют и предоставлены дядей Бобом в книге "Чистая архитектура". Но там же он сам делает оговорку, что это не догма и существуют другие способы количественной оценки. В целом это про направление зависимостей.
Даниил, если при смене вашей позиции в команде команда должна менять микросервисы на монолит и монорепу, то здесь, кажется, не в развитии вкуса дело, а в вашем отношении к контролю и командности. Если на вас замыкается весь проект, то что будет после вашего ухода из него? Есть, знаете ли, примеры. Выразительно плохие.
Приветствую. Хороший код - оптимальный код (ничего лишнего). Но получение оптимального решения требует времени, а у нас бизнес, шпайш машт флоу. Вывод: причина грязного кода (без bidlo coder human factor) - отсутствие достаточного времени и/или отсутствие периодического рефакторинга, что опять же время.
Понравился момент почему обход мапы рондомный , я не читал документацию но примерно знаю теорию по этой структуре , если я правильно понял , то он не рандомный, а зависящий от хеша ключа по которому строиться индекс бакета , то создаётся впечатление рандома , я прошел собес ?)
@@nikolay_tuzov я посмотрел ) честно говоря я так и не понял, зачем там генератор случайных чисел , ну в чем соль , неужели если обойти с чала будут проблемы ?)
@@alexalex-jj2sy потому что язык го проектировали не самые умные люди, если ты не менял мапу, то дважды пройти и получить один и тот же обход это логично и правильно
Непонятна часть про плохой код из-за расплывчатой задачи. Делаете в команде стадию кларификации и проработки требований до уровня который можно дать миду. Это - типовая задача синьора, не говоря уже о лиде.
Проблема чистого кода - это всегда проблема двух недостатков, существенных для всех современных языков программирования кроме ассемблеров: 1) Язык, который позволяет один и тот же алгоритм реализовать многими различными способами. 2) Язык, в котором нет встроенного форматирования по единожды заданным нормам. Все что выше этого, касается напрямую программиста, но эти проблемы гораздо проще выявить и решить: 1) Программист написал НЕ рабочий код или код, которые не реализует поставленную задачу корректно (ошибки на тех или иных данных, как пример). 2) Программист написал рабочий код, который не удовлетворяет требованиям производительности. Всё... Отсюда выводы: Отсутствие чистого кода - это свидетельство несовершенства языков программирования. Отсутствие корректного кода - это свидетельство несовершенства системы подбора, подготовки, экзаменации и квалифицирования программистов. Отсутствие производительного кода - это свидетельство несовершенства системы отбора и внедрения в использование лучших алгоритмов.
Посмотрел, и, немного запутался. Такое ощущение что участники говорят не о о конкретной известной абстракции чистого кода, а о каком-то хорошем или плохом коде, но не особо имеющего отношения к самой абстракции из книжки
!IMHO! Как-то слабоватый конец. Контексты, логер, бизнес-логика... тут просто разделение ответственности, [S]OLID. Логер в контексте - мне так не нравиться, ну вот как Даниил сказал "явное лучше НЕ явного". Контекс с логером - каждый раз извлекать из контекста или один раз задать и не париться (в хендлере, например).
Почему байт? Если вы хотите простой и четкий ответ на довольно сложный ответ, т.е. "волшебнюю пилюлю", то вам к инфоцыганам. А мы просто обсудили эту тему, поделились своими мыслями и пониманием вопроса. А дальше уже каждый сам сделаем свои выводы.
Мне вот нравится этот дядька Глеб. Прям внушает доверие. Такого хочется слушать и прислушиваться.
100%
Ребята, спасибо! В эти темные времена как пилюлька для мозга - так приятно послушать!
Очень приятные собеседники. Хочется слушать и слушать
Нашел Ваши подкасты только сейчас, и для меня, как для только обучающегося, они - просто чудо. Очень жду подкаст про обработку ошибок
Спасибо! Внимательно слушаю все ваши подкасты! Очень интересно! Начинаю изучать golang и, с помощью вашего подкаста, расширяю кругозор.
Привет! Ты с нуля или уже имеется другой опыт разработки? Я вот начинаю с нуля, сейчас чтобы не распыляться на все - прохожу курс на степике и некоторые темы полтягиваю на Ютьюбе. Как у тебя проходит обучение?
Отличная фоновая музыка. Пока слушал подкаст, медленно разделся, и слушал голым.
Ну наконец-то, хоть кто-то! В этом и была задумка ❤️
Супер! Спасибо за ваш труд!
Ещё не смотрела данное видео, но смотрела другие. Хочу выразить вам огромную благодарность за ваш труд и креативный подход к обучению❤. У вас реальный талант учителя, всегда полезно и понятно, почти с первого раза! Наверное единственный канал с колокольчиком у меня 😂
Спасибо за ваш труд!
Спасибо за выпуск! 👍
Вот это мы посмотрим на велике под пивко =)
Круто спасибо за труд
Мастодонты кода =)
26:10 - всё, не выдержал!
там другой книжки не хватает.. третья должна быть "чистый прожект менеджер"
а ну и четвёртую можно - "чистый заказчик"!
конфликт интересов.. капиталистических на лицо!
если вам удаётся работать в условном БМВ у которого денег завались на нормальный инженеринг - это прекрасно. это замечательно..
вопрос неправильно стоит- не "почему" - а "ГДЕ" возникает плохой грязный код?
там где его берут, там где его покупают. там где ему "место".
посмотрев первую треть могу переформулировать вашу тему так - "пишите хороший код, даже если за это вам не платят."
как вам такой заголовочек?
вот попробуйте ответить теперь на вопрос - зачем комуто это делать. за плохой код - платит (расплачивается) заказчик.
да и за хороший - тоже заказчик!
заказчик ( госплан, рынок, капиталист, дядя вася ) - определяет, задаёт планку качества продукции. обладая идеей, целью, ресурсами для её реализации.
заказчик ставит цель
нанимает (или сам является) тех диром
тех дир - нанимает толковую команду, которой ставит толковые задачи, и строго с них спрашивает
и вуаля! у вас ест место где может появится хороший код
программисты тут как птицы. есть зерноядные, есть насекомо. вы обсуждаете как птицам сменить рацион. сделав волевое усилие.
чтобы походить на других. как воробьям ловить рыбу в море клювом.
а это вообще не тот процесс. вы сделайте нужный тип кормушки, в нужных условиях - а дальше черёд за появлением нужных Вам птиц.
❤ Если у вас есть желание поддержать развитие канала:
www.patreon.com/tuzov
boosty.to/nikolay.tuzov
👾 Мой канал в Telegram: t.me/ntuzov
🗣 Наш чат: t.me/+zsSZ63wEJDs3NGVi - здесь присутствуют участники всех выпусков
👀 Golang Digest: t.me/golang_digest - мои регулярные подборки интересных материалов по Go.
Вы лучшие, спасибо
1:28:38 Очень странное утверждение, что логировать внутри функции не нужно, а достаточно wrap'ить ошибку и возвращать. Этим можно обойтись, если вы собираетесь логировать только level=Error, но как быть с Debug/Info? Кроме того в лог ты часто можешь дать сильно больше информации, в т.ч распечатать весь объект/стейт и тд, что оборачивать в ошибку не станешь.
В остальном между передать logger через ctx или request_id через ctx и инжектить внутри разницы действительно немного, но вот некоторые доводы: обычный go context.Context имеет сложность O(N) на get, а это означает, что если вам в логе нужны не 1 поле, я 5-10, вы постоянно делаете это за O(N), что конечно время мизерное, но не забывайте устройство context.Context и его вложенную природу, это может быть весьма затратно искать в нем key..
Не в первый раз смотрю вас, ребята. Очень приятная атфосфера, компетентные люди. Но: почти два часа я ждал системные рекомендации по чистому коду в Go (переложение книги дяди Боба для гоферов) и так и не дождался, к сожалению. Какие-то фрагменты были, но тема не раскрыта, как мне кажется. Повторите, пожалуйста :)
Даниил, а HtDP это ли не книжка по микроархитектуре? Сформулирована она для новичков в формате упражнений, но как бэ она же как раз об этом. Нет?
а можно от Глеба про профнепригодность в программировании, как это понять?
Метрики оценки "чистого" кода все же существуют и предоставлены дядей Бобом в книге "Чистая архитектура". Но там же он сам делает оговорку, что это не догма и существуют другие способы количественной оценки. В целом это про направление зависимостей.
Идеальная (или почти) "Локальность кода" бывает - это функциональное программирование. 😉
Даниил, если при смене вашей позиции в команде команда должна менять микросервисы на монолит и монорепу, то здесь, кажется, не в развитии вкуса дело, а в вашем отношении к контролю и командности. Если на вас замыкается весь проект, то что будет после вашего ухода из него? Есть, знаете ли, примеры. Выразительно плохие.
Если нечто нельзя определить как константу, то вероятно правильнее сделать доступ к этому через функцию.
В детстве, мама мне говорила: пиши сначала на черновик, потом я проверю и будешь писать на чистовик.
Приветствую. Хороший код - оптимальный код (ничего лишнего). Но получение оптимального решения требует времени, а у нас бизнес, шпайш машт флоу. Вывод: причина грязного кода (без bidlo coder human factor) - отсутствие достаточного времени и/или отсутствие периодического рефакторинга, что опять же время.
Понравился момент почему обход мапы рондомный , я не читал документацию но примерно знаю теорию по этой структуре , если я правильно понял , то он не рандомный, а зависящий от хеша ключа по которому строиться индекс бакета , то создаётся впечатление рандома , я прошел собес ?)
У меня на канале есть видос про Мапы в Го, там этот момент подробно объясняется
@@nikolay_tuzov я посмотрел ) честно говоря я так и не понял, зачем там генератор случайных чисел , ну в чем соль , неужели если обойти с чала будут проблемы ?)
@@alexalex-jj2sy потому что язык го проектировали не самые умные люди, если ты не менял мапу, то дважды пройти и получить один и тот же обход это логично и правильно
@@niklkelbon3662 Поинтересуйтесь на досуге чем известны авторы Го помимо самого языка прежде чем определять их в "не самые умные люди".
Непонятна часть про плохой код из-за расплывчатой задачи. Делаете в команде стадию кларификации и проработки требований до уровня который можно дать миду. Это - типовая задача синьора, не говоря уже о лиде.
Не хватает видео про обработку ошибок!
ставь лайк если потянулся за книгой чистый код на полке
DB это всегда константа?)
Проблема чистого кода - это всегда проблема двух недостатков, существенных для всех современных языков программирования кроме ассемблеров:
1) Язык, который позволяет один и тот же алгоритм реализовать многими различными способами.
2) Язык, в котором нет встроенного форматирования по единожды заданным нормам.
Все что выше этого, касается напрямую программиста, но эти проблемы гораздо проще выявить и решить:
1) Программист написал НЕ рабочий код или код, которые не реализует поставленную задачу корректно (ошибки на тех или иных данных, как пример).
2) Программист написал рабочий код, который не удовлетворяет требованиям производительности.
Всё...
Отсюда выводы:
Отсутствие чистого кода - это свидетельство несовершенства языков программирования.
Отсутствие корректного кода - это свидетельство несовершенства системы подбора, подготовки, экзаменации и квалифицирования программистов.
Отсутствие производительного кода - это свидетельство несовершенства системы отбора и внедрения в использование лучших алгоритмов.
класс
Посмотрел, и, немного запутался. Такое ощущение что участники говорят не о о конкретной известной абстракции чистого кода, а о каком-то хорошем или плохом коде, но не особо имеющего отношения к самой абстракции из книжки
!IMHO!
Как-то слабоватый конец.
Контексты, логер, бизнес-логика... тут просто разделение ответственности, [S]OLID.
Логер в контексте - мне так не нравиться, ну вот как Даниил сказал "явное лучше НЕ явного". Контекс с логером - каждый раз извлекать из контекста или один раз задать и не париться (в хендлере, например).
короче они даже не знают, ЧТО такое чистый код
название - чистый бэйт
Почему байт? Если вы хотите простой и четкий ответ на довольно сложный ответ, т.е. "волшебнюю пилюлю", то вам к инфоцыганам. А мы просто обсудили эту тему, поделились своими мыслями и пониманием вопроса. А дальше уже каждый сам сделаем свои выводы.
@@nikolay_tuzov, воды вы налили на 2 часа
Мысли правильные, но местами токсичные)
без яндексовского чуввка как-то скучно