Чистый код в Go - правила хорошего тона для разработчика | GoGetPodcast №5

[@artemsukharenko4877]

Ребята, спасибо! В эти темные времена как пилюлька для мозга - так приятно послушать!

[@takagiro-space]

Мне вот нравится этот дядька Глеб. Прям внушает доверие. Такого хочется слушать и прислушиваться.

[@paul.inglsmit]

100%

[@worldfree1190]

Очень приятные собеседники. Хочется слушать и слушать

[@БекнурБеккалиев-д1т]

Супер! Спасибо за ваш труд!

[@Moonsheen]

Нашел Ваши подкасты только сейчас, и для меня, как для только обучающегося, они - просто чудо. Очень жду подкаст про обработку ошибок

[@SergeyPryada]

Отличная фоновая музыка. Пока слушал подкаст, медленно разделся, и слушал голым.

[@nikolay_tuzov]

Ну наконец-то, хоть кто-то! В этом и была задумка ❤️

[@MajotradeNet]

Спасибо! Внимательно слушаю все ваши подкасты! Очень интересно! Начинаю изучать golang и, с помощью вашего подкаста, расширяю кругозор.

[@МихаилТуманов-э3х]

Привет! Ты с нуля или уже имеется другой опыт разработки? Я вот начинаю с нуля, сейчас чтобы не распыляться на все - прохожу курс на степике и некоторые темы полтягиваю на Ютьюбе. Как у тебя проходит обучение?

[@eleimt]

Спасибо за ваш труд!

[@togzhanserikbayeva8146]

Ещё не смотрела данное видео, но смотрела другие. Хочу выразить вам огромную благодарность за ваш труд и креативный подход к обучению❤. У вас реальный талант учителя, всегда полезно и понятно, почти с первого раза! Наверное единственный канал с колокольчиком у меня 😂

[@alex4everyours]

Спасибо за выпуск! 👍

[@petery6775]

26:10 - всё, не выдержал! там другой книжки не хватает.. третья должна быть "чистый прожект менеджер" а ну и четвёртую можно - "чистый заказчик"! конфликт интересов.. капиталистических на лицо! если вам удаётся работать в условном БМВ у которого денег завались на нормальный инженеринг - это прекрасно. это замечательно.. вопрос неправильно стоит- не "почему" - а "ГДЕ" возникает плохой грязный код? там где его берут, там где его покупают. там где ему "место". посмотрев первую треть могу переформулировать вашу тему так - "пишите хороший код, даже если за это вам не платят." как вам такой заголовочек? вот попробуйте ответить теперь на вопрос - зачем комуто это делать. за плохой код - платит (расплачивается) заказчик. да и за хороший - тоже заказчик! заказчик ( госплан, рынок, капиталист, дядя вася ) - определяет, задаёт планку качества продукции. обладая идеей, целью, ресурсами для её реализации. заказчик ставит цель нанимает (или сам является) тех диром тех дир - нанимает толковую команду, которой ставит толковые задачи, и строго с них спрашивает и вуаля! у вас ест место где может появится хороший код программисты тут как птицы. есть зерноядные, есть насекомо. вы обсуждаете как птицам сменить рацион. сделав волевое усилие. чтобы походить на других. как воробьям ловить рыбу в море клювом. а это вообще не тот процесс. вы сделайте нужный тип кормушки, в нужных условиях - а дальше черёд за появлением нужных Вам птиц.

[@nikolay_tuzov]

❤ Если у вас есть желание поддержать развитие канала: www.patreon.com/tuzov boosty.to/nikolay.tuzov 👾 Мой канал в Telegram: t.me/ntuzov 🗣 Наш чат: t.me/+zsSZ63wEJDs3NGVi - здесь присутствуют участники всех выпусков 👀 Golang Digest: t.me/golang_digest - мои регулярные подборки интересных материалов по Go.

[@VakaramGolang]

Вот это мы посмотрим на велике под пивко =) Круто спасибо за труд Мастодонты кода =)

[@zenderfufikoff]

Если нечто нельзя определить как константу, то вероятно правильнее сделать доступ к этому через функцию.

[@javascuft]

Вы лучшие, спасибо

[@TheDavBag]

а можно от Глеба про профнепригодность в программировании, как это понять?

[@itemun]

Не в первый раз смотрю вас, ребята. Очень приятная атфосфера, компетентные люди. Но: почти два часа я ждал системные рекомендации по чистому коду в Go (переложение книги дяди Боба для гоферов) и так и не дождался, к сожалению. Какие-то фрагменты были, но тема не раскрыта, как мне кажется. Повторите, пожалуйста :)

[@ПавелВаракута-с6ъ]

Метрики оценки "чистого" кода все же существуют и предоставлены дядей Бобом в книге "Чистая архитектура". Но там же он сам делает оговорку, что это не догма и существуют другие способы количественной оценки. В целом это про направление зависимостей.

[@ВиталийКравченко-я4б]

В детстве, мама мне говорила: пиши сначала на черновик, потом я проверю и будешь писать на чистовик.

[@VladimirS-h9o]

Даниил, а HtDP это ли не книжка по микроархитектуре? Сформулирована она для новичков в формате упражнений, но как бэ она же как раз об этом. Нет?

[@eligolin9947]

Идеальная (или почти) "Локальность кода" бывает - это функциональное программирование. 😉

[@VladimirS-h9o]

Даниил, если при смене вашей позиции в команде команда должна менять микросервисы на монолит и монорепу, то здесь, кажется, не в развитии вкуса дело, а в вашем отношении к контролю и командности. Если на вас замыкается весь проект, то что будет после вашего ухода из него? Есть, знаете ли, примеры. Выразительно плохие.

[@viktoralferov2874]

Приветствую. Хороший код - оптимальный код (ничего лишнего). Но получение оптимального решения требует времени, а у нас бизнес, шпайш машт флоу. Вывод: причина грязного кода (без bidlo coder human factor) - отсутствие достаточного времени и/или отсутствие периодического рефакторинга, что опять же время.

[@jentryrunman2179]

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..

[@AlexeyPetushkov]

Непонятна часть про плохой код из-за расплывчатой задачи. Делаете в команде стадию кларификации и проработки требований до уровня который можно дать миду. Это - типовая задача синьора, не говоря уже о лиде.

[@trueskvoz]

ставь лайк если потянулся за книгой чистый код на полке

[@TheDarkprof]

Не хватает видео про обработку ошибок!

[@inv2004]

Посмотрел, и, немного запутался. Такое ощущение что участники говорят не о о конкретной известной абстракции чистого кода, а о каком-то хорошем или плохом коде, но не особо имеющего отношения к самой абстракции из книжки

[@alexalex-jj2sy]

Понравился момент почему обход мапы рондомный , я не читал документацию но примерно знаю теорию по этой структуре , если я правильно понял , то он не рандомный, а зависящий от хеша ключа по которому строиться индекс бакета , то создаётся впечатление рандома , я прошел собес ?)

[@nikolay_tuzov]

У меня на канале есть видос про Мапы в Го, там этот момент подробно объясняется

[@alexalex-jj2sy]

@@nikolay_tuzov я посмотрел ) честно говоря я так и не понял, зачем там генератор случайных чисел , ну в чем соль , неужели если обойти с чала будут проблемы ?)

[@niklkelbon3662]

@@alexalex-jj2sy потому что язык го проектировали не самые умные люди, если ты не менял мапу, то дважды пройти и получить один и тот же обход это логично и правильно

[@zakharka3938]

@@niklkelbon3662 Поинтересуйтесь на досуге чем известны авторы Го помимо самого языка прежде чем определять их в "не самые умные люди".

[@GeatMaximus]

класс

[@valitovgaziz]

DB это всегда константа?)

[@flamehowk]

Проблема чистого кода - это всегда проблема двух недостатков, существенных для всех современных языков программирования кроме ассемблеров: 1) Язык, который позволяет один и тот же алгоритм реализовать многими различными способами. 2) Язык, в котором нет встроенного форматирования по единожды заданным нормам. Все что выше этого, касается напрямую программиста, но эти проблемы гораздо проще выявить и решить: 1) Программист написал НЕ рабочий код или код, которые не реализует поставленную задачу корректно (ошибки на тех или иных данных, как пример). 2) Программист написал рабочий код, который не удовлетворяет требованиям производительности. Всё... Отсюда выводы: Отсутствие чистого кода - это свидетельство несовершенства языков программирования. Отсутствие корректного кода - это свидетельство несовершенства системы подбора, подготовки, экзаменации и квалифицирования программистов. Отсутствие производительного кода - это свидетельство несовершенства системы отбора и внедрения в использование лучших алгоритмов.

[@courtneywilson3652]

!IMHO! Как-то слабоватый конец. Контексты, логер, бизнес-логика... тут просто разделение ответственности, [S]OLID. Логер в контексте - мне так не нравиться, ну вот как Даниил сказал "явное лучше НЕ явного". Контекс с логером - каждый раз извлекать из контекста или один раз задать и не париться (в хендлере, например).

[@gooseman5578]

короче они даже не знают, ЧТО такое чистый код название - чистый бэйт

[@nikolay_tuzov]

Почему байт? Если вы хотите простой и четкий ответ на довольно сложный ответ, т.е. "волшебнюю пилюлю", то вам к инфоцыганам. А мы просто обсудили эту тему, поделились своими мыслями и пониманием вопроса. А дальше уже каждый сам сделаем свои выводы.

[@gooseman5578]

@@nikolay_tuzov, воды вы налили на 2 часа

[@АртёмБондарев-д5э]

Мысли правильные, но местами токсичные)

[@sergiocoder]

без яндексовского чуввка как-то скучно