Ну и куда же без этого анекдота: Как реагируют разные разработчики на фразу "Твой код говно". Junior: - "А-а-а-а меня уволят и я умру!" Middle: - "Что я могу сделать чтобы мой код стал лучше?" Senior: - "Я знаю!" Архитектор: - "А нахрена ты туда полез?!"
Есть офигенный нюанс, про который никто не говорит. Никто не сидит и не читает код как книгу просто потому, что интересно. С большой вероятностью тебе дали баг, что что-то не работает, и когда ты будешь через step in проходить все функции в поисках того, что ж там пошло не так, то мелкие однострочные функции будут офигенно бесить. Всё постоянно прыгает фиг знает куда, посмотреть на пару строк выше не вариант из-за того, что ты вообще в другом файле, надо постоянно тыкать мышкой коллстек туда-сюда и получается полная жесть. И никакие красивые имена не спасут. А вот если есть большой метод, в котором всё последовательно написано и работает, то дебажится шикарно. Ограничение по размеру и уровням вложенности это самое надуманное ограничение, которое на самом деле пытается заменить собой принцип DRY - а надо просто придерживаться DRY, а нарезку на методы где попало не пихать.
Работаю в ИТ инженерии больше 10 лет. Вырос сильно по карьерной лестнице до сениора и дальше в управлении. Могу решать самые тяжелые задачи. До сих пор пишу говнокод. Легче отдать мидлам на рефакторинг 😆
Формат топ, ви молодець, дивлюсь ваші відео ще з моменту початку навчання програмуванню, зараз вже працюю, але ваші відео допомагають навчатися і далі, тож дякую!
"Чистый код" обычно хвалят те кто прочитал только начало :) В последнее время слышу много критики этой книги от тех людей которые прочитали её полностью. Судя по отзывам, в начале в книге есть достаточно логичные и полезные мысли, а во второй половине происходит возведение этих практик в абсолют
6:50 - На самом деле, IoT в частности и немаленькая часть embedded в общем, уже давно ушли в сторону красивого кода, вместо оптимального. Если посмотреть на то, как написаны HAL для современных микрух, то там от оптимальности не то что бы много чего осталось :) Многие даже забивают на DMA и интеррапты, а просто возлагают эти все задачи на RTOS. В итоге, часто вижу проекты, где для задач чуть сложнее чем помигать светодиодом, используют довольно мощные микроконтроллеры с большим объемом памяти, чисто что бы все те абстракции туда потом влезли :)
Общее правило звучит так: код нужно писать "хороший". Разумеется, выбирая алгоритмы с правильной асимптотикой. И только потом, если будет тормозить и профайлер покажет в каком месте, тогда можно начать оптимизацию (раскручивать циклы, делать все функции инлайн, писать вставки на ассемблере и так далее). В любом случае, будет всегда в запасе "референсный" код, который работает _правильно_. Потому, что оптимизированный код очень трудно развивать и всегда важен пусть медленно, но работающий код. Скажем, удобно написать всяческие тесты на рандомных входных данных и сравнивать результат работы "референсного"/"хорошего" и "оптимизированного" когда. Чтобы по ходу оптимизации не сломать что-нибудь.
Две главных боли, которые испытываю при раскурке чужого кода - однобуквенные или сокращённые переменные (привет go) и охулиард слоёв абстракций, вызывающих переполнение мозга (привет жабе).
Добавьте сюда микросервисную архитектуру, где что бы понять, что там в итоге возвращается - нужно ещё выкачать проект (на возможно другом языке и технологиях), и залезть ещё и туда :)
@@feddos4227с микросервисами получилось так-же, как с идеей дробить функции, когда отдельные индивидуумы начали делать кашу из однострочных функций. вот вроде бы здравая идея - а давайте распилим монолит на несколько сервисов, чтоб за каждый отвечала одна команда. а дошли до того, что микросервис на каждый чих, и вместо десяти человек на сервис - десять сервисов на человека. и еще сотня неприкаянных при общем количестве в тыщу. и вот уже со всех митапов и конференций понеслось - "а ведь монолит то не так и плохо было, если он не слишком большой"
Фаулер Роберт - Чистого кода чистый код .... (голосом боярского: Уу уу ... Уу уу... Чистого кода чистый код... Уу уу... А тут матюк и слово рот.... Уу уу...)
На тему безопасности ренейминга: это может быть проблемой, если Вы используете (или вынуждены использовать, ибо до Вас так заведено) автомаппинг. В таком случае желательно сделать (если ещё нет) и прогнать тесты маппинга.
НУЖНО ВИДЕО ПРО DRY В НеООП Мало материалов про клинкод для неООП-фреймворков и языков, а это значительная часть фронтэнда. Например, мне приходится писать много на Vue, куча похожих компонентов, но не совсем ясно, как избежать дублирования кода. Если бы было наследование, я бы им пользовался, но там нет наследования
DRY - это тоже троллинг и запросто спотыкается о реальность, либо порождает архитектурное безумие, так как вы будете вынуждены связывать совершенно несвязанные друг с другом сущности. Допустим у вас в проекте есть классы: "утка", "корабль", "самолёт" и человек". Корабль и утка плавают и в коде их "плавания" может быть немало общего, далее самолёт и утка летают, также утка умеет ходить на двух ногах как и человек. Удачи вам здесь с DRY в проектировании методов. Либо связывайте классы между собой и тогда утка - у нас сверх существо, которое умеет всё! Clean Code сцуко!
Питання. Наприклад пишемо бухгалтерську задачу для місцевого споживача. Оборотно-сальдова відомість на мові замовника просто "оборотка". Як бути з кодом? Писати транслітом "Oborotka", чи англійською "BalanceSheet"?
Оптимизированый код, это код для которого выполнена оптимизация по конкретным критериям, и они могут быть разными. По простоте или по структуре (это тоже оптимизация). По памяти. По скорости. По размеру самого кода. По комбинации критериев. Автоформатирование это зашкварно. Конечно должны быть рекомендуемые правила форматирования, но это в первую очередь рекомендация. Хотя джависты со своими скобками, наверное, достали всех, и автоформат это единственный выход.
Давно пора из идеи и тому подобных вытащить форматеры кода в мавен плагин или в другие сборщики и форматировать в автоматическом режиме при пушах в git.
Автоформатирование - это гадость, от которой надо избавляться. А программистов, неспособных отформатировать нормально, надо просто гнать подальше - никогда такие хороший код не напишут. И никаких конфликтов при мёрдже не будет, если не форматировать код, который ты не менял (в том числе, сюрприз, не применять автоформатирование ко всему файлу).
тот день копгда я понял что ненавижу всей душой как пользователь и программист с 20+(комерчиский ессно) стажем "хороший" код. больше я ненавижу развечтрои зеленых и вокнутых.
Ребят, хорош заниматься всяким кодо-фетишем. Код, который работает и делает то, что надо - хороший, а тот, который не делает - плохой. И нет тут идеала. Практически всегда тот, кто пишет и тот, кто читает, имеют разные модели мышления. И как бы не полировался код, он всегда будет непонятен с разбегу другому программисту. Поэтому, решайте проблемы бизнеса, помогайте зарабатывать ему деньги. Это главное, а не сам код - он вторичен.
Стив Макконелл - база, Боб Мартин - кринж. Серьёзно, clean code от дяди Боба - это тормозной архитектурный ад, который при всё нисколько не помогает писать код быстрее и понятнее. При этом Стив помимо своего ИМХО изучил какие-то исследования, искренне пытаясь вывести наилучшие практики, Боб: "Миш мне пох*й, я так чувствую!" (с).
Ох и противоречивая тема. С одной стороны, вроде удобно отлавливать баги, когда много кода в одном файле, а не скачет всё по 100 файлам, но с другой это порой выглядит как такая чушь. У меня вот была ситуация, когда код дублировался и создавал баг из-за того, что я на класс навешал функционал, не свойственный ему по названию. И при вызове класса производилось некое действие и после него оно также производилось. Нет в общем волшебной пилюли (или silver bullet по заморски).
💪Новый поток advanced тренинга Enterprise patterns стартует 2.12 - go.foxminded.ua/48xDdTi
Ну и куда же без этого анекдота:
Как реагируют разные разработчики на фразу "Твой код говно".
Junior: - "А-а-а-а меня уволят и я умру!"
Middle: - "Что я могу сделать чтобы мой код стал лучше?"
Senior: - "Я знаю!"
Архитектор: - "А нахрена ты туда полез?!"
Я у таких випадках кажу: "Я ще не рефакторив!"
Это драфтовый коммит)
@@БорисКрасных-ц8н Тогда PR должен быть соответствующий 😁
@@woodzimierz9621 а зачем тогда PR делаешь? 😁
Вы недопоняли, просто кто первый написал корявый код, позаботился о коллегах и их хорошей зп и востребованности😂
Видео о запахах кода (code smells) для меня будет очень даже интересным 🙂
Интересно было бы посмотреть видео с разбором кода (как плохого, так и хорошего).
Есть офигенный нюанс, про который никто не говорит. Никто не сидит и не читает код как книгу просто потому, что интересно. С большой вероятностью тебе дали баг, что что-то не работает, и когда ты будешь через step in проходить все функции в поисках того, что ж там пошло не так, то мелкие однострочные функции будут офигенно бесить. Всё постоянно прыгает фиг знает куда, посмотреть на пару строк выше не вариант из-за того, что ты вообще в другом файле, надо постоянно тыкать мышкой коллстек туда-сюда и получается полная жесть. И никакие красивые имена не спасут. А вот если есть большой метод, в котором всё последовательно написано и работает, то дебажится шикарно. Ограничение по размеру и уровням вложенности это самое надуманное ограничение, которое на самом деле пытается заменить собой принцип DRY - а надо просто придерживаться DRY, а нарезку на методы где попало не пихать.
Работаю в ИТ инженерии больше 10 лет. Вырос сильно по карьерной лестнице до сениора и дальше в управлении. Могу решать самые тяжелые задачи. До сих пор пишу говнокод. Легче отдать мидлам на рефакторинг 😆
пора над тщеславием поработать
Формат топ, ви молодець, дивлюсь ваші відео ще з моменту початку навчання програмуванню, зараз вже працюю, але ваші відео допомагають навчатися і далі, тож дякую!
Дякуємо! Який напрямок обрали? Вчились самостійно чи на курсах?
"Чистый код" обычно хвалят те кто прочитал только начало :) В последнее время слышу много критики этой книги от тех людей которые прочитали её полностью. Судя по отзывам, в начале в книге есть достаточно логичные и полезные мысли, а во второй половине происходит возведение этих практик в абсолют
Говоря что SOLID нарушает половину того что написано в чистом коде 😮 это правда?
@@Sky_Lib не могу подтвердить или опровергнуть
@@AntonArhipov без адвоката? )
6:50 - На самом деле, IoT в частности и немаленькая часть embedded в общем, уже давно ушли в сторону красивого кода, вместо оптимального. Если посмотреть на то, как написаны HAL для современных микрух, то там от оптимальности не то что бы много чего осталось :) Многие даже забивают на DMA и интеррапты, а просто возлагают эти все задачи на RTOS. В итоге, часто вижу проекты, где для задач чуть сложнее чем помигать светодиодом, используют довольно мощные микроконтроллеры с большим объемом памяти, чисто что бы все те абстракции туда потом влезли :)
Как всегда точно, кратко, информативно и с юмором 💪
8:00 - Как тебе спится, Джон-Серийный программист?
Формат хороший)
Спасибо, Сергей+!
Интересно, как и всегда) про code smells видео конечно нужно и разбор с примерами тоже было бы здорово
Ваш ответ записан, спасибо)
Ещё таких видео! Очень интересно смотреть.
Общее правило звучит так: код нужно писать "хороший". Разумеется, выбирая алгоритмы с правильной асимптотикой. И только потом, если будет тормозить и профайлер покажет в каком месте, тогда можно начать оптимизацию (раскручивать циклы, делать все функции инлайн, писать вставки на ассемблере и так далее). В любом случае, будет всегда в запасе "референсный" код, который работает _правильно_. Потому, что оптимизированный код очень трудно развивать и всегда важен пусть медленно, но работающий код. Скажем, удобно написать всяческие тесты на рандомных входных данных и сравнивать результат работы "референсного"/"хорошего" и "оптимизированного" когда. Чтобы по ходу оптимизации не сломать что-нибудь.
Круто! Будет интересно посмотреть тоже самое на примерах)
Прекрасное видео! Спасибо Сергей! Жаль, что не сопровождаете кодом, как Tim Corey например, но и на том, что есть спасибо большое!
интересно было бы послушать про code smells!!
Две главных боли, которые испытываю при раскурке чужого кода - однобуквенные или сокращённые переменные (привет go) и охулиард слоёв абстракций, вызывающих переполнение мозга (привет жабе).
Добавьте сюда микросервисную архитектуру, где что бы понять, что там в итоге возвращается - нужно ещё выкачать проект (на возможно другом языке и технологиях), и залезть ещё и туда :)
@@feddos4227с микросервисами получилось так-же, как с идеей дробить функции, когда отдельные индивидуумы начали делать кашу из однострочных функций.
вот вроде бы здравая идея - а давайте распилим монолит на несколько сервисов, чтоб за каждый отвечала одна команда.
а дошли до того, что микросервис на каждый чих, и вместо десяти человек на сервис - десять сервисов на человека. и еще сотня неприкаянных при общем количестве в тыщу.
и вот уже со всех митапов и конференций понеслось - "а ведь монолит то не так и плохо было, если он не слишком большой"
иногда в погоне за уменьшением связности кода мы делаем его бессвязным (
Встречается однажды программист с хорошим кодом и пользователь с fps ниже пульса в два раза...
Наверное в Cities Skyline 2 очень хорошие программисты, и написали очень хороший код )))
Хороший кот это тот, который мурчит и не ссыт в тапки. Всё остальное это плохой кот. Вот
А теперь представим себе кота, который мурчит и срёт.
Мурчит?
Да.
Ссыт?
Нет.
Значит хороший
:D
Роберт Мартин - Чистый код
+
Мартин Фаулер - Рефакторинг
=
Роберт Фаулер - Рефакторинг чистого кода
🙃
Чистый рефакторинг 🙃
Мартин Мартин - Чистый код: Рефакторинг
Чисто рефакторинг!
Фаулер Роберт - Чистого кода чистый код .... (голосом боярского: Уу уу ... Уу уу... Чистого кода чистый код... Уу уу... А тут матюк и слово рот.... Уу уу...)
жду видео про code smells!
Сделаем
У меня есть книга чистый код. Красивая, жёлтая. Всё что я о ней знаю.
аналогично )
Хочете мені подарувати?😊 Бо напевно монітор який стоїть на ній занадто високо 😂
Если ваш код с запашком 💩 то зажмите нос и работайте дальше 😊
Мартин и Фаулер это два разных человека, а Чистый Код вообще не человек (с) анекдот
Відео сподобалось. Тема актуальна. Давай ще.
На тему безопасности ренейминга: это может быть проблемой, если Вы используете (или вынуждены использовать, ибо до Вас так заведено) автомаппинг.
В таком случае желательно сделать (если ещё нет) и прогнать тесты маппинга.
Сейчас очень велика вероятность получить оффер на вакансию пушечного мяса
Да блин это грустно пипец, и конца не видно
???
Обучить чатгпт тому как пишут код у вас в конторе, а потом прогонять свой код, через эту модель)))
Видео про code smells!!!!!
Code Smells +++
Интересно!
С перламутр...пуговицами это классика😅
На хаскеле тоже отступы важны, правда только в части синтаксических конструкций
Сподобалося!
НУЖНО ВИДЕО ПРО DRY В НеООП
Мало материалов про клинкод для неООП-фреймворков и языков, а это значительная часть фронтэнда. Например, мне приходится писать много на Vue, куча похожих компонентов, но не совсем ясно, как избежать дублирования кода. Если бы было наследование, я бы им пользовался, но там нет наследования
DRY - это тоже троллинг и запросто спотыкается о реальность, либо порождает архитектурное безумие, так как вы будете вынуждены связывать совершенно несвязанные друг с другом сущности.
Допустим у вас в проекте есть классы: "утка", "корабль", "самолёт" и человек". Корабль и утка плавают и в коде их "плавания" может быть немало общего, далее самолёт и утка летают, также утка умеет ходить на двух ногах как и человек. Удачи вам здесь с DRY в проектировании методов. Либо связывайте классы между собой и тогда утка - у нас сверх существо, которое умеет всё! Clean Code сцуко!
Питання. Наприклад пишемо бухгалтерську задачу для місцевого споживача. Оборотно-сальдова відомість на мові замовника просто "оборотка". Як бути з кодом? Писати транслітом "Oborotka", чи англійською "BalanceSheet"?
В rust проблему форматирования решили на уровне языка. Команда "cargo fmt" форматирует код в проекте по стандарту разработчиков языка
dont care
Хороший код - за которий платят деньги. То есть, как минимум, он неплох :)
Да конечно видеоролик классный
Оптимизированый код, это код для которого выполнена оптимизация по конкретным критериям, и они могут быть разными.
По простоте или по структуре (это тоже оптимизация).
По памяти. По скорости. По размеру самого кода.
По комбинации критериев.
Автоформатирование это зашкварно.
Конечно должны быть рекомендуемые правила форматирования, но это в первую очередь рекомендация.
Хотя джависты со своими скобками, наверное, достали всех, и автоформат это единственный выход.
Давно пора из идеи и тому подобных вытащить форматеры кода в мавен плагин или в другие сборщики и форматировать в автоматическом режиме при пушах в git.
В смысле 500 не показывать 🌚не по-христиански это 😂
Автоформатирование - это гадость, от которой надо избавляться. А программистов, неспособных отформатировать нормально, надо просто гнать подальше - никогда такие хороший код не напишут. И никаких конфликтов при мёрдже не будет, если не форматировать код, который ты не менял (в том числе, сюрприз, не применять автоформатирование ко всему файлу).
тот день копгда я понял что ненавижу всей душой как пользователь и программист с 20+(комерчиский ессно) стажем "хороший" код. больше я ненавижу развечтрои зеленых и вокнутых.
Ребят, хорош заниматься всяким кодо-фетишем. Код, который работает и делает то, что надо - хороший, а тот, который не делает - плохой. И нет тут идеала. Практически всегда тот, кто пишет и тот, кто читает, имеют разные модели мышления. И как бы не полировался код, он всегда будет непонятен с разбегу другому программисту. Поэтому, решайте проблемы бизнеса, помогайте зарабатывать ему деньги. Это главное, а не сам код - он вторичен.
Reformat только для ИЗМЕНЕННОГО кода, никогда для ВСЕГО файла!
Вот тогда не будет ни лишних изменений кода, ни, тем более, конфликтов.
недооцененный коммент
Шукаю хорошого джава стриптизера для допомоги або чуть гіршого для спільного проекту)
Що за проект? І на чому бек пишите?
@@Klerfe нема і нікого і нічого ще
Стив Макконелл - база, Боб Мартин - кринж. Серьёзно, clean code от дяди Боба - это тормозной архитектурный ад, который при всё нисколько не помогает писать код быстрее и понятнее. При этом Стив помимо своего ИМХО изучил какие-то исследования, искренне пытаясь вывести наилучшие практики, Боб: "Миш мне пох*й, я так чувствую!" (с).
17:53
Скромно предположу
-
Учиться
Всем Адекватности мира и добра
Ха. Книга уже есть. Так что без меня.
Это все? Как то мало, слишком очевидные вещи
+
Чистые кода не существует что значит чистые значит не чего
Первый.
Чистый?
Поздравления
Ох и противоречивая тема. С одной стороны, вроде удобно отлавливать баги, когда много кода в одном файле, а не скачет всё по 100 файлам, но с другой это порой выглядит как такая чушь. У меня вот была ситуация, когда код дублировался и создавал баг из-за того, что я на класс навешал функционал, не свойственный ему по названию. И при вызове класса производилось некое действие и после него оно также производилось. Нет в общем волшебной пилюли (или silver bullet по заморски).