Чистый код в Go - правила хорошего тона для разработчика | GoGetPodcast №5
Vložit
- čas přidán 8. 06. 2024
- Обсуждаем вопросы, связанные с написанием хорошего кода в Go: нужен ли он? Насколько важен? Экономит ли "грязный код" время? Как научиться писать хороший код? И др.
----
Выпуск на других площадках: tuzov.link/gogetpodcast5
Другие выпуски: gogetpodcast.ru/
❤️ Если у вас есть желание поддержать развитие канала:
/ tuzov
boosty.to/nikolay.tuzov
👾 Мой канал в Telegram: t.me/ntuzov
🗣 Наш чат в Telegram: t.me/+zsSZ63wEJDs3NGVi - здесь присутствуют участники всех выпусков
👀 Golang Digest: t.me/golang_digest - мои регулярные подборки интересных материалов по Go.
Тайминги:
00:00:00 Вступление
00:00:27 Начало
00:00:53 Представление участников
00:03:10 Что такое "Чистый Код"?
00:10:17 Вопрос от Данниила - какова причина появления "грязного кода"?
00:11:26 Можно ли сразу писать хороший код?
00:17:13 Отнимает ли чистый код больше времени?
00:20:45 Ответы на вопрос Даниила
00:21:51 Откуда всё же берётся грязный код?
00:22:09 Грязный код: Причина №1 - плохая задача
00:24:33 Грязный код: Причина №2 - микроархитектура
00:28:14 Умение сформулировать свои мысли и требования к коду
00:32:01 Обучаемость людей
00:33:27 Гипотетическая книга "Чистая Микроархитектура"
00:35:59 SOLID для Go
00:37:05 Дискуссии при написании гайдлайнов
00:42:12 Монорепозиторий - хорошо или плохо?
00:44:44 Почему чистый код пишется дольше?
00:49:00 Зависимость качества кода от постановки задачи
00:51:29 Роберт Мартин про скорость написания чистого кода
00:52:36 Соблюдает ли стандартная библиотека Go чистый код?
01:02:19 Можно ли использовать панику в коде?
01:06:17 Можно ли использовать данные, если ошибка не нулевая?
01:11:47 Нужно ли проверять на nil ссылочные типы?
01:17:40 Где добавлять контекст к ошибке - внутри функции или снаружи?
01:20:45 Передача логгера через контекст
01:31:44 Чем плохи глобальные переменные
01:38:24 Когда стоит использовать кастомные (пользовательские) типы?
01:41:58 Можно ли переборщить с кастомными типами?
01:43:11 Польза от Code Review, как способ научиться писать хорощий код
01:50:27 Важность правильного оформления Pull Request'ов
01:52:56 Заключение
#golang #gogetpodcast #ntuzov
Ребята, спасибо! В эти темные времена как пилюлька для мозга - так приятно послушать!
Очень приятные собеседники. Хочется слушать и слушать
В детстве, мама мне говорила: пиши сначала на черновик, потом я проверю и будешь писать на чистовик.
Нашел Ваши подкасты только сейчас, и для меня, как для только обучающегося, они - просто чудо. Очень жду подкаст про обработку ошибок
Отличная фоновая музыка. Пока слушал подкаст, медленно разделся, и слушал голым.
Ну наконец-то, хоть кто-то! В этом и была задумка ❤️
Супер! Спасибо за ваш труд!
❤ Если у вас есть желание поддержать развитие канала:
www.patreon.com/tuzov
boosty.to/nikolay.tuzov
👾 Мой канал в Telegram: t.me/ntuzov
🗣 Наш чат: t.me/+zsSZ63wEJDs3NGVi - здесь присутствуют участники всех выпусков
👀 Golang Digest: t.me/golang_digest - мои регулярные подборки интересных материалов по Go.
Ещё не смотрела данное видео, но смотрела другие. Хочу выразить вам огромную благодарность за ваш труд и креативный подход к обучению❤. У вас реальный талант учителя, всегда полезно и понятно, почти с первого раза! Наверное единственный канал с колокольчиком у меня 😂
Спасибо за ваш труд!
Спасибо! Внимательно слушаю все ваши подкасты! Очень интересно! Начинаю изучать golang и, с помощью вашего подкаста, расширяю кругозор.
Привет! Ты с нуля или уже имеется другой опыт разработки? Я вот начинаю с нуля, сейчас чтобы не распыляться на все - прохожу курс на степике и некоторые темы полтягиваю на Ютьюбе. Как у тебя проходит обучение?
насчет написания кода "для себя" - в какой-то момент смотришь и думаешь, я это не пропустил бы в прод и переписываешь нафиг )
Мне вот нравится этот дядька Глеб. Прям внушает доверие. Такого хочется слушать и прислушиваться.
100%
Спасибо за выпуск! 👍
Насчет скорости написания чистого и грязного кода - тут как-то ситуативно. Когда не сильно ограничен в сроках, стараешься писать чисто (я вот, например, придумал структурку, написал под нее тесты, реализовал, потом двигался дальше и из "сделай хорошо" задача потихоньку выстроилась во вполне себе структурированную) Это как наточить топор. Иногда лучше остановиться и обдумать, а не скакать опой по клавиатуре в погоне за результатом. И получилось быстрее, чем если б я сначала писал "чтобы работало", нафигачил кода, а потом ловил баги и кучу раз деплой перезапускал, у которого тоже свои особенности. Когда в сроках сильно ужат - делаешь "на коленке" с рассчетом, что "я потом это отрефакторю, честно-честно, но пока так" )
Вы лучшие, спасибо
Если нечто нельзя определить как константу, то вероятно правильнее сделать доступ к этому через функцию.
а можно от Глеба про профнепригодность в программировании, как это понять?
Вот это мы посмотрим на велике под пивко =)
Круто спасибо за труд
Мастодонты кода =)
Не в первый раз смотрю вас, ребята. Очень приятная атфосфера, компетентные люди. Но: почти два часа я ждал системные рекомендации по чистому коду в Go (переложение книги дяди Боба для гоферов) и так и не дождался, к сожалению. Какие-то фрагменты были, но тема не раскрыта, как мне кажется. Повторите, пожалуйста :)
Идеальная (или почти) "Локальность кода" бывает - это функциональное программирование. 😉
Метрики оценки "чистого" кода все же существуют и предоставлены дядей Бобом в книге "Чистая архитектура". Но там же он сам делает оговорку, что это не догма и существуют другие способы количественной оценки. В целом это про направление зависимостей.
Непонятна часть про плохой код из-за расплывчатой задачи. Делаете в команде стадию кларификации и проработки требований до уровня который можно дать миду. Это - типовая задача синьора, не говоря уже о лиде.
Проблема чистого кода - это всегда проблема двух недостатков, существенных для всех современных языков программирования кроме ассемблеров:
1) Язык, который позволяет один и тот же алгоритм реализовать многими различными способами.
2) Язык, в котором нет встроенного форматирования по единожды заданным нормам.
Все что выше этого, касается напрямую программиста, но эти проблемы гораздо проще выявить и решить:
1) Программист написал НЕ рабочий код или код, которые не реализует поставленную задачу корректно (ошибки на тех или иных данных, как пример).
2) Программист написал рабочий код, который не удовлетворяет требованиям производительности.
Всё...
Отсюда выводы:
Отсутствие чистого кода - это свидетельство несовершенства языков программирования.
Отсутствие корректного кода - это свидетельство несовершенства системы подбора, подготовки, экзаменации и квалифицирования программистов.
Отсутствие производительного кода - это свидетельство несовершенства системы отбора и внедрения в использование лучших алгоритмов.
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..
ставь лайк если потянулся за книгой чистый код на полке
Приветствую. Хороший код - оптимальный код (ничего лишнего). Но получение оптимального решения требует времени, а у нас бизнес, шпайш машт флоу. Вывод: причина грязного кода (без bidlo coder human factor) - отсутствие достаточного времени и/или отсутствие периодического рефакторинга, что опять же время.
класс
Понравился момент почему обход мапы рондомный , я не читал документацию но примерно знаю теорию по этой структуре , если я правильно понял , то он не рандомный, а зависящий от хеша ключа по которому строиться индекс бакета , то создаётся впечатление рандома , я прошел собес ?)
У меня на канале есть видос про Мапы в Го, там этот момент подробно объясняется
@@nikolay_tuzov я посмотрел ) честно говоря я так и не понял, зачем там генератор случайных чисел , ну в чем соль , неужели если обойти с чала будут проблемы ?)
@@alexalex-jj2sy потому что язык го проектировали не самые умные люди, если ты не менял мапу, то дважды пройти и получить один и тот же обход это логично и правильно
@@niklkelbon3662 Поинтересуйтесь на досуге чем известны авторы Го помимо самого языка прежде чем определять их в "не самые умные люди".
26:10 - всё, не выдержал!
там другой книжки не хватает.. третья должна быть "чистый прожект менеджер"
а ну и четвёртую можно - "чистый заказчик"!
конфликт интересов.. капиталистических на лицо!
если вам удаётся работать в условном БМВ у которого денег завались на нормальный инженеринг - это прекрасно. это замечательно..
вопрос неправильно стоит- не "почему" - а "ГДЕ" возникает плохой грязный код?
там где его берут, там где его покупают. там где ему "место".
посмотрев первую треть могу переформулировать вашу тему так - "пишите хороший код, даже если за это вам не платят."
как вам такой заголовочек?
вот попробуйте ответить теперь на вопрос - зачем комуто это делать. за плохой код - платит (расплачивается) заказчик.
да и за хороший - тоже заказчик!
заказчик ( госплан, рынок, капиталист, дядя вася ) - определяет, задаёт планку качества продукции. обладая идеей, целью, ресурсами для её реализации.
заказчик ставит цель
нанимает (или сам является) тех диром
тех дир - нанимает толковую команду, которой ставит толковые задачи, и строго с них спрашивает
и вуаля! у вас ест место где может появится хороший код
программисты тут как птицы. есть зерноядные, есть насекомо. вы обсуждаете как птицам сменить рацион. сделав волевое усилие.
чтобы походить на других. как воробьям ловить рыбу в море клювом.
а это вообще не тот процесс. вы сделайте нужный тип кормушки, в нужных условиях - а дальше черёд за появлением нужных Вам птиц.
Не хватает видео про обработку ошибок!
Посмотрел, и, немного запутался. Такое ощущение что участники говорят не о о конкретной известной абстракции чистого кода, а о каком-то хорошем или плохом коде, но не особо имеющего отношения к самой абстракции из книжки
Дяди после красивых слов про чистый код устроили срач на элементарном вопросе с логированием ;-))) В идеале при чистом коде бизнес-код не должен зависеть от инфраструктуры от слова совсем, в которой помимо логирования есть еще трассировка, метрики и тд.
Первые три минуты - прямо сильно хромающее начало беседы. Уже не первый раз. И я поясню, в чем проблема: Николай пытается играть по законам радио в игру ведущий-гости. Но в подкастах такого рода это не нужно - ты сам программист, тебе должно быть что сказать по теме. Поэтому берешь и начинаешь. Будь полноценным участником беседы(посмотри на подкаст "мы обречены", например) и не стесняйся говорить сам.
На радио то понятно почему так: потому что ведущий это журналист, а гость представляет собой экспертизу. И абсолютно логично, чтобы журналист, который ничего не понимает, говорил поменьше, а гость побольше. Но тут то это не нужно.
Спасибо за критику, подумаю над этим.
Я действтельно обычно говорю меньше по нескольким причинам:
1) мне нужно вести беседу, сохранять структуру, направлять в нужное русло и т.п. В первые разы это было довольно тяжело, и ментальных сил ещё и на полноценное участие не хватало. Но сейчас стало проще, т.к. начал привыкать.
2) у других участников как правило, намного более богатый опыт, чем у меня. Думаю, их интересней слушать
!IMHO!
Как-то слабоватый конец.
Контексты, логер, бизнес-логика... тут просто разделение ответственности, [S]OLID.
Логер в контексте - мне так не нравиться, ну вот как Даниил сказал "явное лучше НЕ явного". Контекс с логером - каждый раз извлекать из контекста или один раз задать и не париться (в хендлере, например).
короче они даже не знают, ЧТО такое чистый код
название - чистый бэйт
Почему байт? Если вы хотите простой и четкий ответ на довольно сложный ответ, т.е. "волшебнюю пилюлю", то вам к инфоцыганам. А мы просто обсудили эту тему, поделились своими мыслями и пониманием вопроса. А дальше уже каждый сам сделаем свои выводы.
@@nikolay_tuzov, воды вы налили на 2 часа
без яндексовского чуввка как-то скучно
Мысли правильные, но местами токсичные)