Пересказ книги Чистый Код за 20 мин — Transcript

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

поддержку, потому что данного рода ролики - это что-то новое для канала. А, попробуем это развивать в целом. Как-то так. Также подпишись ещё на Telegram-канал, потому что там как раз-таки есть анонсы, продвинутый материал, помощь, консультации. Так ты мне сильно поможешь. Лайки, комментарии,

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

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

коде. Если мы чистая архитектура охватывала всю систему целиком, здесь мы говорим структуру о дизайне системы. То есть, ну, тот, кто читал чистую архитектуру, поймёт, о чём сейчас речь.

Дизайн - это конкретная, грубо говоря, а конкретная реализация. То есть тот же самый код. Здесь, как и в прошлых роликах, есть проходные главы, вода ничего нечего особо подчеркнуть. Средний не особо прямо важно. Начнём с того, что вообще такое чистый код и какая главная

идея книги. Чистй код. Главная идея. Книга начинается с вопроса, что такое чистый код. Универсальное определение, нет, но опытные разработчики сходятся в одном. Чистый код легко читать, понимать, изменять и сопровождать. У Роберта Мартина есть одна основная вещь.

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

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

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

обратно же это в книге написано, но местами легче продублировать код, нежели, грубо говоря, там писать какую-то интересную логику. То есть важно понять, что есть определённые вещи, которые не стоит делать очень часто. Дублировать не стоит. Огромные функции, огромные функции могут

присутствовать, но и это не должен быть весь проект. Чаще всего это маленькие функции fit function, ну, то есть максимально такая узенький участок кода, который могут там функции, функции и так далее. Э и непонятные имена обязательно нужно именовать и функции, и переменные,

и так далее. Ээ смешивание ответственностей, а, это очень плохая история, когда у нас в одной функции очень много разных сайд-эффектов и так далее, то есть лучше всё-таки разграничивать логику. А что у нас по признакам чистого кода? Код читается как

текст. Это, кстати, очень хорошим примером является. То есть, если вы код можете просто прочитать как эссэ, это было бы хорошо. И для того, чтобы, ну, код легко воспринимается. Можете его в будущем поддерживать. Каждая сущность отвечает за одну задачу. Это очень

важная история. Минимум неожиданностей, то есть минимум сайд-эффекта, минимум того, что может в будущем привести к каким-то непонятным вещам. А чистый код ээ нужен не компьютеру. Компьютеру всё равно. Чистый код нужен людям, которые будут поддерживать систему после вас.

О'кей? А содержательные имена. Здесь у нас идёт про то, как мы именуем переменные, функции и так далее. Главная идея имена - это самая важная часть читаемости кода, потому что по переменной можно понять, что она делает.

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

Имя должно отвечать на вопрос, что это плохая переменная, consрошая, created, плохо, geta, хорошо, get user, плохо, userlist хорошо, generation time step, плохо, gen dbms, хорошо, user order payments.

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

это слишком абстрактно. Хорошо будет вот так. А плохо у нас тоже видим, что не совсем понятно, что такое.

Хорошо будет sendil. То есть мы говорим, наша функция, наша переменна должна говорить, зачем она и что хочу передавать тебе перейти в мой Telegram-канал в описании, потому что именно там выходит самая первая, самая новая информация. консультации, ты можешь получить собеседование, ты можешь

получить променты материалы, шпаргалки, поучаствовать в конкурсе, приходе в описании. Первошая ссылка будет, зачем она и что она делает. О'кей. Функции. А главная идея: функции должны быть маленькими, понятными, выполнять одну задачу. Плохая функция, 200 строк кода много. Обратно же всё зависит от

контекста. Местами 200 строк кода- это это ещё мало. Поэтому всё зависит от контекста. Если у нас есть возможность её уменьшить, это было бы хорошо. Просто обратно же. Можно функцию вообще сделать маленькой, но это будет функция функций, функции, функции, функции, функции. То

есть это будут разные вложности, это будет куча вложности, это будет просто нагромождение файлов ненужных. Это будет бред. Местами лучше может даже дополнительную строчку добавить. Хорошо.

Видим, как хорошо. Одна функция, одна ответственность. Плохо видим, как у нас это выглядит. Лучше видим, как это у нас выглядит. А здесь у нас отличие по названиям, если кто не понял.

Минимизируйте аргументы. Важно лучший вариант. Это вообще без аргументов допустимо. Хуже, когда мы передаём таким образом, это очень плохо. Лучше всего передавать в объекте, в объекте, где у нас first time власны сити и так далее.

Главная мысль главы, а, а, вот, кстати, избегайте флагов, потому что true fse лучше не отправлять. А и по названию наших э функций тоже мы должны понимать, как их правильно реализовывать. Главая главная мысль главы. Функции должны иметь возможность понять практически

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

Поэтому надо разделить либо переименовать комментарии. Главная идея комментарии. Большинство разработчиков считают, что большин большие комментарии, чем больше комментарией, тем лучше. Мартер утверждает обратно. На самом деле комментарии - это, ну, это не то, что где вы можете там разгуляться.

Комментарии - это просто где-то что-то описать. Чаще всего это какая-то доконформация, какая-то лицензия, а, и так далее. То есть просто глав главном файле док информации. Чаще всего комментарии местами даже очень плохо.

Лучше комментарий тот, который не нужен. Фактически, если ваш код понятен без комментариев, это хорошо. Не надо писать для сме отправка имейла комментарий, потому что это и так понятно. Но если у вас функция D какая-нибудь и вы реализуете стороннюю библиотеку, просто

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

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

закомментированное, просто убираем. О'кей. Форматирование. Форматирование - это не просто красота. Ну, притеры, понятно, а как это работает? Это вопрос читаемости. Код читается гораздо чаще, чем пишется, поэтому его внешний вид влияет на скорость понимания системы.

Вертикальное форматирование. Файл должен читаться сверху вниз. Как раз сначала высокоуровневая логика, потом детали. Видим, как это выглядит. А, тоже видим, как это выглядит. Большие файлы трудно понимать. Если файл содержит 2005 2.000 строк кода 5.000, значит, скорее всего, в нём слишком много ответственности. А

предварите предпочтительно 100-500 строчек кода для большинства классов и модулей. А горизонтальное же форматирование - это когда у нас слишком длинная функция, и нам надо её, грубо говоря, а, упростить, сделать таким образом. Чаще всего у нас есть линтеры и

притеры, которые обязательно для подключения. Кстати, здесь об этом и говорится. Самое важное правило главы в проекте должны быть единый стиль, еслин, притерitр, конфликт, который настроен там вс-коде где угодно, где вы, какой идеей вы пользуете. А далее, объекты и

структуры данных. Главная идея. Мартин показывает фундаментальную разницу между объектом и структуром нами данных. Многие разработчики смешивают эти понятия. Что такое объект? Объект скрывает данные и представляет поведение. Видим, что у нас есть, а, bн аккаунт и у нас есть депозит и вывод.

Что такое структура данных? Структура данных представляет данные напрямую. Например, банк аккаунт, просто баланс тысячи. Мы просто получаем здесь у нас объект фактически, который даёт нам возможность что-то саккумулировать внутри и делать изменения этого с помощью методов. Объект не должен знать

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

Общение между слоями, между функциями, между какими-то участками кода происходит с помощью DTO, контрактной истории Data Transfer Object, простой контейнер данных. Например, у нас есть user DTO, в котором хранится ID, name, email. DTO не должно содержать бизнес-логики, и его задача - перенос

данных между слоями. Объекты скрывают данные, представляют поведения. Структуры данных представляют данные и почти не содержат поведения. Смешивание этих подходов часто приводит к запутанному коду. О'кей. Обработка ошибок. Код обработки ошибок не должен смешиваться с основной логикой приложения. Чаще всего это какой-то

внешний или надстройкамевара, которая перехватывает исключения. Эти исключения каким-то образом форматируют и выводим в понятном виде. Проблема кодов ошибок.

Используйте исключение. И видим, что в данном случае у нас плохо что-то result error, какая-то непонятная история. Что мы сделаем лучше в случае в случае какой-то ошибки мы отхватываем подхватываем эту ошибку и выводим её лоиром. Не создавайте информативные исключения, не возвращайте нал в

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

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

системе, где у нас на стыке встречаются разные источники данных либо вообще разные проекты. А когда мы используем стороннюю библиотеку, мы начинаем зависеть от её апи. В чём здесь в чём плохо? В плохом случае у нас есть как как раз библиотека, с которой мы

работаем. Get, post, delete. Меняется библиотека, меняется интерфейс взаимодействия. Что нам делать? Хорошо, когда у нас есть какой-то внешний, ну, внешний источник, там какая-то библиотека и в наш внутренний класс, который это реализует, в случае чего мы можем просто прийти и изменить там getт,

пост, контракт взаимодействую, что угодно. В данном случае нам надо будет изменять везде. Вот если мы будем работать с HTP Client, у нас есть единая точка входа, где в случае каких-то изменений мы и заменим. Данный подход является адаптером. Ещё один способ

работы с границами, например, Application, Payment Strpe. То есть у нас есть адаптер, который даёт нам возможность в данном случае просто адаптировать код библиотеки под наших.

Сторонний код нельзя контролировать, поэтому нельзя позволять ему распространяться по всему проекту, как в этом случае. Любая внешняя зависимость должна быть изолирована через собственные интерфейсы, адаптеры, обёртки. Модульные тесты. Тесты - это такой же код, как и основной код приложения, как мы и смотрели в чистой

архитектуре. Советую этот ролик очень сильно. Поэтому тесты должны быть чистыми, читаемыми и поддерживаемыми. Три закона TDD, а Test Driving Development. Мартин напоминает основные правила разработки через тестирование.

Первый закон не писать рабочий код, пока не падающего теста. Обратно же всё это практика. На самом деле в реальных работающих проектах местами тестирования забивается полностью. ЕстьDD, есть BDD, когда мы сначала тесты пишем, когда мы тесты поверх пишем, кто как пишет. Здесь

как это только теория. Здесь вот вот это вот прямо я даже зелёным, наверное, отмечу, это прямо не супер что-то важное. А первый закон, не писать рабочий код, пока нет отпадающего теста.

Это обратно же. Всё зависит от проекта, всё зависит от того, как вы пишете код.

Если вам TDD подходит, о'кей, местами BDD, местами без тестов, местамин-тесты, всё от проекта зависит, всё максимально не тривиально и нету такого вот нет серебряной пули. Второй закон, не писать большие тесты, чем нужно для падения. А третий закон не писать больше кода, чем

нужно для прохождения теста. Принцип first для тестирования. Хороший тест обладает пятью свойствами. Fast - быстрый тест, independent - независимый тест, repeatable повторяемый, self validate самопроверяемый и таймле своевремен. А, о'кей. Дальше у нас глава 10. Классы. Главная идея. Если функция

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

add item, remove item calculator. Это в плохом примере у нас calculate total, send email, upload file, то есть что-то вообще непонятное у нас. Оordдер к этому фактически не относится. А изоляция изменений. Изменения одной части системы не должны приводить к изменениям

десятков классов. Для этого используются интерфейсы абстракции, внедрения зависимостей. И здесь как раз два примера с нашего Solid. В Solid можно глянуть в JavaScript на канале. У меня был отдельный ролик по СolлиID. Плюс ко всему в чистой архитектуре мы также про

Solid говорили. А в что здесь? Принцип единовестности кланс должен и иметь только одну причину для изменения.

Видим, что у нас usеer, save, validate, generate pdf, которая здесь вообще никак не сходится и сميل. В лучшем случае надо usеer. User validate отдельный класс, userпоository и email сервис, который будет этим всеми заниматься. Размер класса, как и функции класса, должны

быть небольшими. Большой класс обычно содержит 1.000 строк кода. Это нарушает наш SRP принцип. CP класс должен расширяться без изменений существующего кода в плохом случае, когда мы добавляем какой-то, я не знаю, провайдер. В лучшем случае у нас есть какой-то Payment

Gitway, который реализует определённые наши сервисы: оплаты пайпалом, оплата криптой, чем угодно. То есть фактически у нас всё должно быть гибко и удобно.

Далее. Системы. Вопрос главы: как организовать всю систему? Разделение и создание, использования очень распространённые ошибки. Класс сам создаёт свои зависимости и получает сильную связанность. userвиice в конструкторе создаёт наш userрепоositoryй. В чём проблема?

Userрепозиторий меняется, нам надо заходить в наш класс, что-то изменять. Такого не должно быть. В лучшем случае у нас есть usерсервис, который получает репозиторий снаружи. Очень похоже, кстати, на Dependy Injection. И здесь как раз идёт речь про Deppendc e

injection. Один из основных инструментов - это как раз-таки внедрение зависимости. Внедрение зависимости, сервис, локаторы и так далее. Об этом всё в Telegram-канале. Не забудь подпишись, пожалуйста. Отделяйте бизнес от инфраструктуры. В плохом сценарии у нас есть user сервис Safe User с

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

отражать бизнес. В плохом случае у нас есть контроллеры, сервисы, репозитории. В хорошем Orders payment user. Понимаем, как это работает. Далее.

формирование архитектуры. На самом деле, касаемо архитектуры, у нас уже была, а, был у нас уже ролик, чисто архитектура, но мы ещё здесь, грубо говоря, обойдём.

Архитектура должна поддерживать изменения. Главная задача архитектуры снижать стоимость изменения. Об этом говорилось в чистой архитектуре.

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

Обратно же смотрим. Чи Чистая архитектура, ролик на канале. А используйте абстракции. userвиice, постгрес, репозиторий. Не конкретно в юзерсервисе мы работаем с нашим постгресом, у нас есть определённый репозиторий для работы с базой. Не привязывайтесь к технологиям.

Архитектура должна пережить замену базы данных, фреймворка, очередь сообщений, внешнего. Роберт Marinн говорит: "Всё, вообще всё у нас - это детали. Детали должны изменяться. Всё основное - это бизнес-правила. Бизнес-правила всегда.

Это конечно, это точка, с которой начинается проект. Лучше usеerсервис и user repository. У нас есть прослойка в виде user repository, которая принимает себя пост user repository и user repository принимает, вернее, usеer общается с user repository. Что такое хорошая архитектура? С точки зрения

Роберта Мартина хорошая архитектура позволяет легко тестировать систему, легко изменять систему, понимать систему, заменять детали реализации. А здесь же у нас такая оглавление. Связь дальнейших книг фактически является мостом между чистым между двумя частями книги. Первая часть объясняет как чистый

код. Следующая часть будет объяснять, как из чистого кода строится архитектура в виде чистой а архитектуры. А многопоточность. Главная идея.

Многопоточность нужна для ре задач. Повышенной повышение отказо устойчивости системы, более эффективное исполнение ресурсов. Но многопоточно делать код значительно сложнее. А что у нас здесь?

Принцип разделения ответственности. Многопоточно должен быть изолированным от бизнес-логики. Видим, как это выглядит. Здесь у нас есть плохой пример Create order, где у нас синхрона, всё синхронизировано. Лучше, чтобы у нас это всё было в отдельном виде. У нас есть

орсервис и какой-то, э, тред-менеджер, который будет именно заниматься потоками. Всё, что касаемо сервиса - это в сервисе. Всё, что потоков - это к потокам. Ограничивайте область синхронизации. Обратно же у нас есть ээ большой синхронизатор, условно, который синхронизирует потоки. И лучше это

сделать в фитформате. Избегайте совместного состояния. Обратно же. Рейс-кондишены, самая тяжёлая история, которая вообще может быть. У нас есть единый источник данных. И если мы попадаем в race condition, мы себе просто стреляем в ногу. В плохом виде у нас есть usерш. Кэш, к которому

обращается 220 потоков. Лучше каждый поток работает со своими данными. Лучше всё-таки это разделять. Используйте готовые инструменты. Не нужно самостоятельно писать очереди, блокировки, пулыпотоков. У нас есть определённые модули и в Питоне, и в нормально это используется. Используется стандартной библиотеки. Executor service

concurrent hashmap blocking you. Это в контексте. Так многопоточность последовательное очищение. Главная идея. Большинство проектов невозможно написать идеально с первой попытки. Хороший код появляется через последовательный рефакторинг. Что такое последовательное ощущение? Поход подход состоит из двух этапов. Первый этап - заставить код работать. Второй

этап - постепенно улучшать структуру. Как обычно работает любые проекты, они все написаны на коленке. И главное решить задачу. Как только проект выстреливает, начинается рефакторинг.

изменения хорошая архитектура и так далее. Маленькие изменения лучше больших. Что у нас в плохом варианте?

Полностью переписать модуль за один комит. Это очень плохое. А лучше у нас 50 маленьких изменений, чем одно большое, потому что между маленькими изменениями есть комиты, есть фиксации.

Мы можем как-то откатить, посмотреть, то есть лучше итеративно всё-таки делать маленькими частями. А каждый рефактор должен сохранить работоспособность системы. Как раз-таки это основная суть, потому что без работоспособности системы вот эти маленькие комиты не имеют никакого а значения. Здесь видим, что

тест у нас все о'кей. И тогдареact тоже о'кей. Так, здесь у нас глава, где мы рассматриваем внутреннее строение Gunit.

Это как раз-таки Java история. Это нам не надо, это можем пропустить. Здесь то же самое с сериал Data. И так, а запахи евристического правила. Главная идея - это не новая тема книги, это итоговый чек-лист, который помогает находить проблемы в коде. Мартин собирает в одном

месте признаки, запахи, которые часто говорят о плохом дизайне или нарушении принципов чистого кода. Комментарий как запах. Часто комментарии говорят о том, что код написан плохо. Дублирование кода - один из самых серьёзных запахов.

Длинные функции, слишком много параметров. Магические числа. Плохо, когда у нас здесь статус сем. Мы не знаем, что это за статов. Нарушение инкапсуляции. Свич и большие цепочки if.

Мёртвый код, который не поддерживается. Код работает, но размер функции намекает на большие нарушения. Видим, что здесь как у нас что такое запах. Запах не означает с ошибку. Это сигнал, который может быть проблема. Здесь вот как видим, как запах выглядит. О'кей.

Приложение А. многопоточность. Здесь как раз-таки идёт речь о том, что у нас есть потоки, у нас есть дедлоки, у нас есть локеры. В чём суть? Когда мы работаем с потоками, нам надо как-то синхронизировать наши изменения. Для этого у нас есть различного рода

примочки. Это локеры. Это, ну, вот мы можем говорить локи, семафоры, мьютексы, очереди, пайпы и так далее. То есть то, как мы это всё синхронизируем. А многопоточности трудно воспроизвести, отладить, протестировать. То есть это на самом деле такая история, которую не

прямо легко решить. То есть а есть места, где многопоточность о'кей, но чаще всего всё-таки работают с concurrenty, потому что это более отслеживаемая история. А потому что мы можем здесь попасть в состояние гонки, где у нас для один источник данных и

есть проблемы, надо локами заниматься, взаимной блокировкой, когда у нас один поток блокирует другой поток, и мы просто сидим, ждём. И главная идея, вот здесь как раз-таки озвучена главная идея идея приложения. Многопоточность нужно рассматривать как отдельную проблему проектирования. Она требует собственных

правил и дисциплин. Здесь у нас приложение Как работает приложение serial data. А не особо важно.

Перекрёстные ссылки. Большинство принципов чистого кода взаимосвязаны. Проблемы замечены в одном месте. Обычно связаны с проблемами нескольких правил.

И эпилог. Финальный вывод всей книги. Чистый код - это не набор правил или не набор паттернов. Это постоянное стремление писать код, который легко читать, тестировать, изменять и сопровождать. Если после вашего хода другой разработчик сможет быстро понять систему безопасно внести изменения,

значит цель книги достигнут. Всё, что говорит Роберт Мартин - это только то, что мы тот код, который пишем, должны легко поддерживать. В целом, как-то так.

Мы рассмотрели книгу Чистый код. Это является, грубо говоря, началом для чистой архитектуры. Кто как хочет, может смотреть. Скорее всего, чистая архитектура выйдет раньше. и она уже вышла на канале, можно будет посмотреть.

Поэтому как-то так. Для меня ваша поддержка будет колоссальна. Просто очень надо просмотры, подписки, лайки.

Просто поставить лайк, просто поставить комментарий, это ничего не не значит для нас и но очень для вас, но очень значит для меня. Поэтому подпишись, поставь лайк, переходи в Telegram-канал в описании тоже туда подпишись. Огоньки очень нужны для продвижения, потому что,

э, чтобы всё, грубо говоря, было о'кей, чтобы канал развивался хоть как-то, хоть как-то даже на текущий момент. Поэтому подпишись, поставь лайк.