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

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

Рет қаралды 13,743

Күн бұрын

Обсуждаем вопросы, связанные с написанием хорошего кода в 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

Пікірлер: 50

@artemsukharenko4877 Жыл бұрын

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

@SergeyPryada Жыл бұрын

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

@nikolay_tuzov Жыл бұрын

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

@worldfree1190 Жыл бұрын

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

@Moonsheen Жыл бұрын

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

@user-vn3ou5pn1t 10 күн бұрын

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

@user-ic1hl5zj4f Жыл бұрын

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

@togzhanserikbayeva8146 Жыл бұрын

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

@nikolay_tuzov Жыл бұрын

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

@eleimt Жыл бұрын

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

@alex4everyours Жыл бұрын

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

@artemchistyakov9705 Жыл бұрын

насчет написания кода "для себя" - в какой-то момент смотришь и думаешь, я это не пропустил бы в прод и переписываешь нафиг )

@MajotradeNet Жыл бұрын

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

@user-tu7mo7sf2v Жыл бұрын

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

@takagiro-space Жыл бұрын

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

@paul.inglsmit 8 ай бұрын

100%

@artemchistyakov9705 Жыл бұрын

Насчет скорости написания чистого и грязного кода - тут как-то ситуативно. Когда не сильно ограничен в сроках, стараешься писать чисто (я вот, например, придумал структурку, написал под нее тесты, реализовал, потом двигался дальше и из "сделай хорошо" задача потихоньку выстроилась во вполне себе структурированную) Это как наточить топор. Иногда лучше остановиться и обдумать, а не скакать опой по клавиатуре в погоне за результатом. И получилось быстрее, чем если б я сначала писал "чтобы работало", нафигачил кода, а потом ловил баги и кучу раз деплой перезапускал, у которого тоже свои особенности. Когда в сроках сильно ужат - делаешь "на коленке" с рассчетом, что "я потом это отрефакторю, честно-честно, но пока так" )

@javascuft 9 ай бұрын

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

@zenderfufikoff Жыл бұрын

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

@TheDavBag Жыл бұрын

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

@VakaramGolang 8 ай бұрын

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

@itemun Жыл бұрын

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

@eligolin9947 Жыл бұрын

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

@user-ui9eb8dn5p Жыл бұрын

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

@AlexeyPetushkov 4 ай бұрын

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

@flamehowk Жыл бұрын

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

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

@GeatMaximus Жыл бұрын

класс

@trueskvoz 8 ай бұрын

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

@viktoralferov2874 Жыл бұрын

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

@alexalex-jj2sy Жыл бұрын

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

@nikolay_tuzov Жыл бұрын

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

@alexalex-jj2sy Жыл бұрын

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

@niklkelbon3662 2 ай бұрын

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

@zakharka3938 19 күн бұрын

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

@petery6775 Жыл бұрын

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

@TheDarkprof 5 ай бұрын

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

@inv2004 7 ай бұрын

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

@user-nu2wg3rx6n Жыл бұрын

Дяди после красивых слов про чистый код устроили срач на элементарном вопросе с логированием ;-))) В идеале при чистом коде бизнес-код не должен зависеть от инфраструктуры от слова совсем, в которой помимо логирования есть еще трассировка, метрики и тд.

@onkelen5677 Жыл бұрын

Первые три минуты - прямо сильно хромающее начало беседы. Уже не первый раз. И я поясню, в чем проблема: Николай пытается играть по законам радио в игру ведущий-гости. Но в подкастах такого рода это не нужно - ты сам программист, тебе должно быть что сказать по теме. Поэтому берешь и начинаешь. Будь полноценным участником беседы(посмотри на подкаст "мы обречены", например) и не стесняйся говорить сам.

@onkelen5677 Жыл бұрын

На радио то понятно почему так: потому что ведущий это журналист, а гость представляет собой экспертизу. И абсолютно логично, чтобы журналист, который ничего не понимает, говорил поменьше, а гость побольше. Но тут то это не нужно.

@nikolay_tuzov Жыл бұрын

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

@courtneywilson3652 Жыл бұрын

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

@gooseman5578 6 ай бұрын

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

@nikolay_tuzov 6 ай бұрын

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

@gooseman5578 6 ай бұрын

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