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