С одной стороны может показаться, что автор говорит очевидное, но чем больше вы слышите одно и то же, тем больше шансов, что вы начнёте делать правильно
В последнем примере, где вы стали заранее готовить результаты всех сравнений, ваша оптимизация просто опасна. А вдруг, например, свойство user.IsLocked вычисляется относительно долго? До оптимизации оно вычислялось последним, после кучи других проверок, и не каждый раз. Вы "отрефакторили" код так, что теперь все значения для условия вычисляются обязательно и всегда, в том числе и наше потенциально тяжёлое свойство.
На счет первого, как по мне, это вопрос спорный (где-то схватился за сердечко дядюшка Боб). Над ним я постоянно размышляю. И прихожу к выводу, что порой проще читать код в потоке, нежели заниматься извлечением метода ради самого извлечения метода. Не спорю, извлекать методы нужно и важно, когда это действительно улучшает чистоту, но иногда прям фанатичное извлечение превращается в какое-то горожение огорода. Тут все-таки нужно чувство баланса.
Полностью согласен с тобой. Тут речь безусловно о больших логических кусках, конечно выносить в метод 1-2 строчки не всегда хорошая идея, но бывают и исключения. Например, если у нас длинное и сложное условие, которое по бизнесу часто меняется, то его я бы выносил в метод, чтобы проще было изменять его в случае чего (мое субъективное мнение). А так конечно же все рефакторингы это отчасти и вкусовщина. Писать нужно так, как удобно тебе и членам твоей команды, но и стараться следовать + - общепринятым стандартам, чтобы если вы ушли, то другие разрабы могли это быстро подхватить.
Последний пример я бы написал немного по другому. Каждый if вынес бы отдельно с прерывание дальнейшего выполнения. Зачем нам дальше выполнять код, если нет оредера или юзера? if (order == null || user == null) return false; И так далее, код будет так же читаем и без вложеностей.
Да, можно и так. Но визуально будет иначе. В твоем случае вложенность визуально сохранится, но будет всегда 1 уровень вложенности. Я показал прием, как вообще избавиться от условных конструкций. Чаще на практике я как раз делаю так, как ты предлагаешь. Т.е всегда проверяем плохие случаи и делаем прерывания.
Спасибо, хоть и являюсь новичком, но понял все, о чем вы говорили в данном видеоролике. Но почему не использовать partial в 3 рефакторинге, можно же создать 2 одинаковых метода с разными аргументами, раз у нас номер карты и email, то можно uint cardNumber сделать и аналогично с e-mail, но уже в string? Я немного слабоват еще в таком
Если делать частичными классами, то придется названия методов каждый раз разные делать. Тогда не будет плюсов полиморфизма. По сути это не будет отличаться от первоначального примера, когда все в одном классе. Ты просто раскидаешь кусочки по разным файлам. Чтобы более точно понять, тут тебе нужно почитать про плюсы использования абстракций и слабой связанности за счет нее.
Многим впадлу читать эти книги (особенно джунам). Т.к зачастую первое впечатление, что it материал подается довольно душно. Такие видео и созданы для тех, кто не особо читает книги.
Я бы по другому сделал мне не нравится код рефакторинга в начале мы 3 раза извлекаем продукт хотя можно это сделать 1 раз и передавать уже продукт аргументом в методы а не ID продукта. С интерфейсами вообще все просто можно сказать что интерфейсы обеспечивают стандартизацию, позволяя классам имплементировать общие методы и свойства. Это средство унификации, обеспечивая согласованный способ взаимодействия различных классов. Из этого следует вопрос а зачем нам все это надо на что можно просто ответить что это нужно для упрощения добавления новых функциональностей, обеспечивая единообразный способ взаимодействия между классами и улучшая читаемость и понимание кода. То определение что интерфейс служит контрактом бла бла бла мне в корне не нравится…
4й - не надо так плз, имхо более правильный рефакторинг в данном случае это инвертирование условия: т.е. вместо if (a) { if (b) { if (c) ...логика... }}} else { return false; } лучше if (!a) { return false; } if (!b) { return false; } if (!c) { return false; } ...логика... это легче читать чем вложенные в тернарники тернарники и полотно && || условий
автору самому бЫ подучиться перед тем, как учить других. В четвертом примере название метода CanProcessOrder неудачно, поскольку описЫвает невнятное состояние вместо действия. Лучше бЫло бЫ назвать CheckOrderProcessAbility или CheckOrderProcess. Так же в коде есть антипаттерн magic numbers - єто 0 и 10. Их нужно вЫнести в константЫ.
В каждом из примеров рефакторился не весь код, а конкретные примеры. В четвертом примере специально не менялось название метода (осталось исходным), ибо об этом речь шла во втором примере. Также и в случае с константами. Если рефакторить все подряд, тогда не наглядно будут видны изменения в коде на конкретном примере рефакторинга. Также стоит отметить, что это не мой код. Я лишь взял данный код для наглядности конкретных приемов рефакторинга, которые я произвел над ним. Но тут не было речи о полном рефакторинге кода каждого из примеров. Но все равно спасибо за замечания
Ничо не понял. Приведённые примеры - это не рефакторинг, это исправление изначально кривущей архитектуры приложения и незнания элементарных вещей про клинкод. Нут не рефачить надо, а гнать взашей таких тупых скиллбокскодеров.
Чат подсказал тоже неплохое сокращение кода, хотя хз, норм это или нет ) public class OrderProcessor { public bool CanProcessOrder(Order order, int stockCount, User user, bool isExpressShipping) { return order != null && user != null & order.Status == OrderStatus.Pending && stockCount > 0 && user.IsActive && !user.IsLocked && (!isExpressShipping || stockCount >= 10); } }
Не всегда нужно делать сокращение ради сокращения) Читаемость также должна оставаться высокой. Сейчас нужно прям вчитываться в каждый фрагмент условия, поэтому лично я бы так не писал)
📢 ССЫЛКА НА TELEGRAM канал: t.me/lightcode_group
⚡ ПОДДЕРЖКА канала на boosty: boosty.to/lightcode
С одной стороны может показаться, что автор говорит очевидное, но чем больше вы слышите одно и то же, тем больше шансов, что вы начнёте делать правильно
Тебе нужно делать цикл видео программирование на мемах !!!)!)!))!))!)🤧
Спасибо за видео!
Советы и правда хороши, причём нередко они необходимы и для программистов со стажем, которые были в прошлом самоучками.
Согласен, ибо опыт работы не гарантирует наличие пробелов в знаниях)
Категорически крутой контент! Все понятно и доступно 🔥
В последнем примере, где вы стали заранее готовить результаты всех сравнений, ваша оптимизация просто опасна. А вдруг, например, свойство user.IsLocked вычисляется относительно долго? До оптимизации оно вычислялось последним, после кучи других проверок, и не каждый раз. Вы "отрефакторили" код так, что теперь все значения для условия вычисляются обязательно и всегда, в том числе и наше потенциально тяжёлое свойство.
На счет первого, как по мне, это вопрос спорный (где-то схватился за сердечко дядюшка Боб). Над ним я постоянно размышляю. И прихожу к выводу, что порой проще читать код в потоке, нежели заниматься извлечением метода ради самого извлечения метода. Не спорю, извлекать методы нужно и важно, когда это действительно улучшает чистоту, но иногда прям фанатичное извлечение превращается в какое-то горожение огорода. Тут все-таки нужно чувство баланса.
Полностью согласен с тобой. Тут речь безусловно о больших логических кусках, конечно выносить в метод 1-2 строчки не всегда хорошая идея, но бывают и исключения. Например, если у нас длинное и сложное условие, которое по бизнесу часто меняется, то его я бы выносил в метод, чтобы проще было изменять его в случае чего (мое субъективное мнение). А так конечно же все рефакторингы это отчасти и вкусовщина. Писать нужно так, как удобно тебе и членам твоей команды, но и стараться следовать + - общепринятым стандартам, чтобы если вы ушли, то другие разрабы могли это быстро подхватить.
Классно, давай еще) Как вариант слева можно оставлять как было, а справа как стало.
Учту в следующих подобных видео
Отличный видос, спасибо
Пример с интерфейсами тот еще мусор. Автор просто взял весь сценарий с нейронки и записал ролик. Браво
Спасибо
Последний пример я бы написал немного по другому. Каждый if вынес бы отдельно с прерывание дальнейшего выполнения. Зачем нам дальше выполнять код, если нет оредера или юзера? if (order == null || user == null) return false; И так далее, код будет так же читаем и без вложеностей.
Да, можно и так. Но визуально будет иначе. В твоем случае вложенность визуально сохранится, но будет всегда 1 уровень вложенности. Я показал прием, как вообще избавиться от условных конструкций. Чаще на практике я как раз делаю так, как ты предлагаешь. Т.е всегда проверяем плохие случаи и делаем прерывания.
Крутой продакшн. Респект!
Бро, скинь ссылку пожалуйста на годный курс на программирование , что бы вот сесть и вместе с курсом чт то делать а не просто слушать .
Даже я все поняла 😁👍🏻
Спасибо, хоть и являюсь новичком, но понял все, о чем вы говорили в данном видеоролике. Но почему не использовать partial в 3 рефакторинге, можно же создать 2 одинаковых метода с разными аргументами, раз у нас номер карты и email, то можно uint cardNumber сделать и аналогично с e-mail, но уже в string? Я немного слабоват еще в таком
Если делать частичными классами, то придется названия методов каждый раз разные делать. Тогда не будет плюсов полиморфизма. По сути это не будет отличаться от первоначального примера, когда все в одном классе. Ты просто раскидаешь кусочки по разным файлам. Чтобы более точно понять, тут тебе нужно почитать про плюсы использования абстракций и слабой связанности за счет нее.
Спасибо за ответ, сейчас прочитаю как раз
какой симпатяжка🥹🥹🥹🥹😘🥹🥹
тут возникает дилема скорости и удобства
Жизненно 1:15
Если интересно, можно почитать книгу, Чистый код Роберта Мартина
Многим впадлу читать эти книги (особенно джунам). Т.к зачастую первое впечатление, что it материал подается довольно душно. Такие видео и созданы для тех, кто не особо читает книги.
насколько на технике эпл удобно кодить на Си шарпе?
Я бы по другому сделал мне не нравится код рефакторинга в начале мы 3 раза извлекаем продукт хотя можно это сделать 1 раз и передавать уже продукт аргументом в методы а не ID продукта. С интерфейсами вообще все просто можно сказать что интерфейсы обеспечивают стандартизацию, позволяя классам имплементировать общие методы и свойства. Это средство унификации, обеспечивая согласованный способ взаимодействия различных классов. Из этого следует вопрос а зачем нам все это надо на что можно просто ответить что это нужно для упрощения добавления новых функциональностей, обеспечивая единообразный способ взаимодействия между классами и улучшая читаемость и понимание кода. То определение что интерфейс служит контрактом бла бла бла мне в корне не нравится…
4й - не надо так плз, имхо более правильный рефакторинг в данном случае это инвертирование условия:
т.е. вместо
if (a) { if (b) { if (c) ...логика... }}} else { return false; }
лучше
if (!a) { return false; } if (!b) { return false; } if (!c) { return false; } ...логика...
это легче читать чем вложенные в тернарники тернарники и полотно && || условий
Согласен по поводу инвертирований, сам так постоянно пишу, думаю стоило упомянуть в видео
автору самому бЫ подучиться перед тем, как учить других. В четвертом примере название метода CanProcessOrder неудачно, поскольку описЫвает невнятное состояние вместо действия. Лучше бЫло бЫ назвать CheckOrderProcessAbility или CheckOrderProcess. Так же в коде есть антипаттерн magic numbers - єто 0 и 10. Их нужно вЫнести в константЫ.
В каждом из примеров рефакторился не весь код, а конкретные примеры. В четвертом примере специально не менялось название метода (осталось исходным), ибо об этом речь шла во втором примере. Также и в случае с константами. Если рефакторить все подряд, тогда не наглядно будут видны изменения в коде на конкретном примере рефакторинга. Также стоит отметить, что это не мой код. Я лишь взял данный код для наглядности конкретных приемов рефакторинга, которые я произвел над ним. Но тут не было речи о полном рефакторинге кода каждого из примеров. Но все равно спасибо за замечания
Душнила😊
Ничо не понял. Приведённые примеры - это не рефакторинг, это исправление изначально кривущей архитектуры приложения и незнания элементарных вещей про клинкод. Нут не рефачить надо, а гнать взашей таких тупых скиллбокскодеров.
Чат подсказал тоже неплохое сокращение кода, хотя хз, норм это или нет )
public class OrderProcessor
{
public bool CanProcessOrder(Order order, int stockCount, User user, bool isExpressShipping)
{
return order != null && user != null & order.Status == OrderStatus.Pending && stockCount > 0 && user.IsActive && !user.IsLocked && (!isExpressShipping || stockCount >= 10);
}
}
Не всегда нужно делать сокращение ради сокращения) Читаемость также должна оставаться высокой. Сейчас нужно прям вчитываться в каждый фрагмент условия, поэтому лично я бы так не писал)