КОД КАК У СЕНЬОРА. РЕФАКТОРИНГ

[@CoRecYT]

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

[@binzaricatalin6542]

А можно фото с видео? С котом Томом)

[@ITentikaOnline]

@@binzaricatalin6542 а вот и кот! itentika.ru/wp-content/uploads/2022/10/cat_refactoring.jpg

[@binzaricatalin6542]

@@ITentikaOnline спасибо ✋

[@vector7932]

Я

[@ulcuber]

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

[@beispiel]

Очень приятная манера повествования и дикция, уши в восторге

[@bog_d]

Знаю родителей автора видео, классные мужики!

[@urbanfreestylerone]

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

[@Paradise_Box]

Теперь я понял к чему приводит рефакторинг! К увольнению! :)

[@arakovskiy]

😆

[@ДмитрийЛегостаев-р9ш]

Спасибо, теперь появилось хоть и смутное, но понимание того, что же такое рефакторинг

[@TurboKot1k]

слова настоящего синьора, мое почтение! единственное есть пару спорных моментов, многие это подметили, а в остальном балдеж)

[@Valentin_I]

Круто! Вместо 1 свитча с 64 кейсами - 64 новых класса

[@maxgrachev1]

Увидел 4 класса вместо 4 свитч кейсов. И это действительно удобнее, имхо. А в чем проблема с новыми классами? Если их выходит слишком много, то можно группировать по неймспейсам и/или подклассам. Или рефакторить дальше.

[@Valentin_I]

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

[@ДаниилЧернышев-л5й]

@@Valentin_I Если растет количество категорий, можно воспользоваться паттерном Builder или Composite - сделать класс категории, который можно собирать из нескольких более простых. В схему со switch такое вообще не представляю как уложить.

[@Valentin_I]

@@ДаниилЧернышев-л5й вот с этим согласен

[@maximlyakhov967]

видео топ, но семантика имени класса ChildrensPrice заставляет задуматься о контексте))

[@BodnarSergey]

Отличный видос!

[@sliceem88]

Блин категорически крутой контент! Как раз в процессе.

[@youtubeyh]

Только за озвучку уже 2 лайка заслуживает!

[@РоманРоман-н4н]

Топ, однозначно. И техническая сторона, и философская, и взаимоотношения.

[@nomugop8017]

Сильно брат! Надеюсь однажды достигну твоего уровня код рефакторинга ;), а лучше сразу буду писать как надо.

[@ok-tz3vw]

Видос - супер! Кратко, понятно и доступно! Можно показать как разрабам, так и менеджменту.

[@spamcolector]

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

[@Unknow2N]

да и говорит по ходу дела довольно энергично) Если в теме 0, то тяжело воспринимать. Я начал сыпаться с switch-case. Надо будет пересматривать, как предыдущая информация будет переработана

[@Nisitka]

Спасибо за видео! Все понятно и доступно

[@Лучшеникакогознаниячемникакое]

Не ну это за гранью конечно. Методы по 3-4 строки - еще ладно, на любителя, может кому-то и правда удобнее иметь 1000 методов вместо 20. Лично меня учили, что метод должен быть глубоким, то есть делать какое-то значимое и понятное изменение, решать какую-то структурную часть задачи. А не просто быть потому что нам код слишком длинным показался. Но вызов одного и того же метода несколько раз, просто чтобы не создавать переменную - это край уже. А если метод изменится и станет жрать больше ресурсов, тогда что? Будете все его вызовы искать? А когда у вас такие методы вообще везде и имя им легион - так что конкретно одного тормозящего нет, а все коматозят приложение примерно поровну - тогда что? Опять полный рефакторинг? Нельзя так откровенно забивать на оптимизацию. Преувеличивать её роль конечно тоже не стоит, но тут прямо полное пренебрежение же. Что вообще значит "только когда она (оптимизация) требуется"? Кому требуется? Типа пока заказчик претензии не выставит, то и оптимизировать не будем что ли?

[@alexgorodecky1661]

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

[@gset1000]

все это конечно интересно... Но я не понял фичу со switch. Отрефактарил код и в итоге, по сути к нему же и вернулся, заменив его на if(ы). Почему не создать словарь, где будут храниться все классы -наследники и ключ по priceCode?

[@ТиминАлексей-с2т]

катастрофически одобряю контент полезный

[@antonchekulaev]

Братан, хорош, давай, давай, вперёд. Контент в кайф, можно еще? Вообще красавчик! Можно вот этого почаще?

[@___avka___924]

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

[@andd3dfx]

Благодарю, неплохое видео

[@warpArtifact]

А если я пришёл на проект и там классы по 20к строк, нету тестов, и есть такой IService который реализует более 200 интерфейсов ?

[@VladykaVladykov]

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

[@Nixguy]

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

[@Zanozus]

А еще из-за этого строка кода становится заметно длиннее и автоматическая проверка стиля будет разбивать ее на несколько строк.

[@nerewan]

плюс, запрашиваемые данные могли измениться за время между вызовами (зависит от контекста, конечно же)

[@alexgorodecky1661]

А ещё это банальное дублирование логики

[@mir8876]

Давай больше таких видосов

[@VaeV1ct1s]

Отличная идея писать тесты на код, который нужно рефакторить. Рефакторим же мы его не потому что он не тестируемый, верно?

[@foooxich8828]

Прекрасное видео, спасибо большое автору

[@grizimin]

А что делать если методов настолько много, что не хватает фантазии придумывать названия для них?

[@romanbush5164]

Нахриначил магических цифр найс, сними видос по правильным тестам

[@cognosce6193]

Можно добавлять в описание ссылку на репозиторий исходников? спасибо

[@АлексейВарнавский-щ8д]

Спасибо, классное видео!!

[@eduardboiko7219]

Отлично

[@enter_IT]

Классная подача материала в видео :)

[@zvuk3316]

Классный видос, спасибо! Вот только про unit тесты не понял всё таки. Я столкнулся с проблемой, что когда рефакторишь код, то постоянно нужно и рефакторить тесты(

[@suifutors]

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

[@PaulSith]

Написание под продукт сложнее блокнота грамотных автотестов ... требует команду такую ж как на основной продукт , а то и в несколько раз большую Те тесты которые присутствуют во многих "крупных" продуктах ... в целом ... "Чтобы были" ... и не более

[@bubblesort6368]

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

[@octaviarius]

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

[@MrShnaiderTV]

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

[@gibbdev]

Хорошее видео :D После того как понимаешь как рефакторить почти все oop языки становятся гораздо менее страшными и очень понятными. Только вот может в случае джавы стоило вместо классов для новых типов фильмов завести enum?

[@muggzzzzz]

Взяли джуном на 20-летнее легаси. В программе около 450 классов, самый маленький строк в 5-10, самый большой в овер6000. Жуткие макароны. Рефакторить такое практически невозможно, как и добавить новый функционал.

[@kolyuchkin]

Автору спасибо за видео. "Структурный поиск/замена" в IntelliJ Idea тоже является мощным средством рефакторинга и автоматизации сопутствующих рутинных операций. Не могли бы Вы также, как и в этом ролике, более подробно познакомить нас с этим инструментом?

[@justborney]

Автор, у тебя не было статьи на хабре?

[@Eltar007]

Интересно... Но как же асилить весь ролик-то? ))) Надо будет посмотреть с утра, пожалуй ))

[@bossmusa9075]

от души

[@АзизбекНурматов-э1в]

3-4 строки на метод, я представляю сколько теперь будет методов в моих проектах)...

[@Лучшеникакогознаниячемникакое]

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

[@АзизбекНурматов-э1в]

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

[@Лучшеникакогознаниячемникакое]

@@АзизбекНурматов-э1в Так в методе и не должно быть много чего. В нем должно быть решение одного аспекта задачи. Только одного. Но по возможности полностью - чтобы прочитав код этого метода, ты понял, как именно этот аспект решается. Без беготни по стеку вызовов.

[@АзизбекНурматов-э1в]

@@Лучшеникакогознаниячемникакое Да так и есть

[@eternal_wanderer_ru]

Уж лучше один метод на 50 строк который делает что-то конкретное, чем 17 функций по 2-3 строки

[@_LEXX_]

Концовка намекает что удача вам пригодится )))

[@ltukutfl]

Красивый шрифт у IDEA

[@eternal_wanderer_ru]

Jetbrains Mono. Можно юзать хоть где

[@VitaliyNET]

Video Test ✅ 1 of 1

[@MrNikitaftw]

Работаю джуном в проекте с легаси кодом, имеем классы размером 11 тысяч строк)

[@ivanmatew568]

Отличное видео. Подписка. 1. Я сам пока не могу себя заставить не кешировать в переменную результат функции, но борюсь с этим. 2. Говорят, что Кент Бек уже отрицает полезность TDD. Я не проверял, но мысль любопытная.

[@arakovskiy]

Последнее, что я встречал - это как тдд защищает :) kzbin.info/www/bejne/sGrUpquQqLGWnNE

[@ne4to777]

а надо кэшировать. Я хз, от куда эта идея экономить на спичках.

[@ivanmatew568]

@@arakovskiy , ролику 8 лет же.

[@Igor-wh3cp]

Хорошее видео. Автору спасибо! Где можно посмотреть исходный код и репозиторий с коммитами?

[@Igor-wh3cp]

@@arakovskiy Спасибо за оперативный ответ!

[@FL4M3M4K3R]

хорошее видео спасибо

[@РоманОболонский-ц8н]

эх, всегда бы было все так просто

[@georgepro8481]

Я в репе увидел ещё попытку подрефакторить через ООП. Я думаю. что лучше через функциональные интерфейсы, типа private static Map map = new HashMap(); static { map.put(REGULAR, a -> (a (a (a

[@VinodKumar-mz3fs]

Could you please provide sub titles in English for non Russian audience

[@TheDavBag]

а нельзя просто обойтись интерфейсом для получения цены? наследование - грязная завязка, которую потом не отрефачишь

[@spirridd]

Одна вещь осталась неясной - зачем нужно слово get при именовании методов?

[@arakovskiy]

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

[@magdel1940]

Так называют методы которые возвращают значения полей как есть. Без get называют методы которые что-то делают и возвращают.

[@Wansery]

1:14 мне интересно, а что они такое писали, что у них ушло так много строк кода? Я блин аналог тележки уложил в 5к строк, это с учётом визуала javaFx, который занял минимум 30% строк. А тут что...

[@bog_d]

МОЯ ЖИЗНЬ РАЗДЕЛИЛАСЬ НА ДО И ПОСЛЕ ПОЧЕМУ Я НЕ ДЕЛАЛ ЭТОГО РАНЬШЕ ЧТОБЫ ПОЗНАТЬ РЕФАКТОРИНГ ПОЛНОСТЬЮ, НУЖНО ВСЕГО РАЗ В ДЕНЬ... Читать дальше

[@Lucio11a]

"Метод, который содержит 10 и более строк - явно перегружен!" Вспомнил ща методы свои, в которых я, иногда, использую switch, т.к. он бывает удобнее и нагляднее, и так получается явно больше 10 строк :D

[@АккаунтВременный-ш2ы]

Если у тебя вменяемое и точно фиксированное количество case'ов, и в одном месте, то можно и switch.

[@arakovskiy]

@@АккаунтВременный-ш2ы +

[@vlera4198]

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

[@olegbogomolov3227]

Огромное спасибо! Отличная подача и наглядные примеры!

[@hpw-dev]

пофиксите название, замените на КОД КАК У СЕНЬОРА. РЕФАКТОРИНГ КОДА НА JAVA

[@stepan-klyukin]

3:13 это реальнй проект?

[@ИИванов-ь6с]

Еще раз гляну когда протрезвекю

[@ИльяПетров-р3о]

А почему у великих программистов считается, что работать с тысячей мелких классов на 2-3 строчки проще, чем с одним большим? Превратил простую и понятную программку на 10 строк в дремучие дебри, в которых сам через неделю ничего не поймёшь )))

[@SkyAntins]

Потому что Роберт Мартин так сказал, это самое главное для них. А то, что работать с этим неудобно - это уже мелочи и издержки

[@WSSAWER]

Это лажа. Такое говорилось про методы, а не классы. И это верно в том смысле, что лучше методы на 2-3 строчки, чем метод на 100. А классы и методы просто должны быть сообразны названию/применению с минимизацией роли. Тогда мы получаем метод с минимальным количеством строк без ухудшения понимаемости. Для перегонки джейсонов это почти всегда несколько строк. А вот для математических вычислений и алгоритмов это около 10-30 строк, в зависимости от сложности алгоритма и подготовки данных может быть и больше сотни строк. А классы на 1000+ строк, 100+ методов получаются вообще во многих либах, просто из-за высокой степени унификации. Но логическая сложность у них низкая, можно сказать на порядок ниже(т.е. воспринимаются как класс с десятком методов)

[@krauter_roman]

ыы, а такое бывает?)

[@WSSAWER]

Это никак не сеньорский уровень, а максимум мидла. Если бы не момент. Тут опять есть Золотая пуля - убрать локальные переменные. И что в итоге? Метод читается лучше, а класс то хуже. Я бы за такое своих разрабов точно ругал. У нас задача уменьшить логическую сложность большого проекта. Мы в первую очередь работаем с его структурой - нам важна читаемость на верхнем уровне. Среди сотен классов и десятков тысяч методов нужно разобраться. А тут ещё и задачу усложняют! То, что внутри метода чуть правая часть будет длинной - вообще не читаем, если не нужно узнавать откуда эта переменная данные берёт. Ладно бы ещё методы в методах были(локальные методы) - вот тут я бы понял. Мелочи, типа переноса метода по зависимостям как в видео делать можно в любой момент. Но вот если зависимости из нескольких мест идут, то так уже нельзя. Сначала нужно заняться дизайном текущего кода. Потом уже из этого дизайна исходить. Про дизайн о при рефакторинге тут нет. А это основа, по которой мы должны код менять. И не всегда это простой рефакторинг, иногда это ещё и сокрытые баги, которые в силу случайности не видны, но появятся при изменении кода в каком-то вообще другом месте. Чтобы показать что там и как на сеньорском уровне, нужно не такие "детские" исправления, а например, перенос метода из одного интерфейса с 10 классами в другой интерфейс с 5 классами показать. Да как это всё версионировать и проверить. Ну или хотя бы решение какой-то проблемы с рефакторингом через дизайн. Про тесты интересно... И интересно как написать тест, если заглушек нет, а программа работает через загрузку данных в, скажем, 100 разнотипных объектов. Т.е. либо грузи всё, либо работать не будет. Отдельных самостоятельных объектов нет. Причём, на микро это всё не делится. Можно только %10 выписать в отдельные сервисы разного размера, но неделимое ядро для загрузки будет требовать именно столько. Вот на этот вопрос я пока не нашёл Хорошего ответа.

[@pavel2392]

Что за ОС стоит?

[@arakovskiy]

убунта)

[@AlexGreenoff]

Видео скорее вредное, чем полезное. Автор определяет методы подлежащие укорачиванию по их длине, что в корне неверно. Укорачивать метод или нет, нужно решать по его логической структуре. В идеале метод должен делать что-то одно и если это не так, то только тогда разносить логику на несколько методов. Насмотревшись таких роликов джуны и некоторые миддлы будут плодить код, состоящий из сотен коротких методов и функций, порождая лишние сущности и по сути нарушая принцип KISS. А уж момент со встраиванием переменной и вовсе заставил меня выключить видео. Чтобы сэкономить 1 строку кода (кому вообще это мешает????), автор видео потенциально увеличил потребление ресурсов. Неопытные разработчики, опять же, увидев такое и приняв на вооружение начнут подобное клепать во всех проектах к месту и не к месту. А ведь за этим методом, который мы встраиваем, может скрываться потенциально какой-нибудь тяжелый кусок кода, который проводит сложные вычисления, лезет в БД, лезет в сторонние API. Поэтому попытка хорошая, но видео скорее вредное, чем полезное. И уровень рефакторинга, на мой взгляд, не соответствует названию. Дальше не смотрел, тк стало просто жалко времени.

[@AlexGreenoff]

@@kanequbolt10 Почему один раз, если два? Даже сам автор видео на этом делает акцент. Посмотрите сами на 6:53

[@georgepro8481]

Пулемётная скорость. Я лично не успеваю осмыслить. Пришлось смотреть не сколько раз. А так-то в общем неплохо.

[@GoosesGoose]

видел разок .c файл на 88к строк кода :)

[@articice7342]

5 за подачу материала. 1 за отсутствие видео где объясняется когда и почему вышеописанные правила не надо использовать.

[@alexgorodecky1661]

Никогда эти правила не нужно использовать 😂

[@СырнаНе-Бака]

1:00 Тот, кто это говорил - тот не видел код ЯндереДева в Яндере симуляторе.

[@СергейК-б6н]

Я канеш не шарю в джавах но видос крутой

[@GrafMKristo]

Слова проглатываешь. Не торопись.

[@leader_antagonist]

Копия статей хабра?

[@SunakSunak-b9t]

Надо было на 1С писать!

[@igorgromyko8975]

хммм набор мыслей джуна не понимающего чего делает

[@ivanmatew568]

Обоснование есть?

[@bubblesort6368]

@@ivanmatew568 ну во первых даже первоначальный код был весьма сносным. А во вторых 4 строчки может быть пипец как мало для метода) даже 12 очень немного. В реальных проектах у вас может быть сущность с 50 полями по домену. И как ее инициализацию уместить в 4 строки?) Можете сказать, что сущность нужно разбить на несколько классов, так она она тогда может потерять инварианты...

[@Wansery]

4:10 сомнительное утверждение... Очень сомнительное

[@ІванМостовий-у1в]

лайк + підписка + комент

[@ТимурСафаров-в1ч]

Всё можешь идти книгу писать

[@step6753]

Мои методы на 150 строк: а, да?

[@darkjune0122]

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

[@tony8366]

Спасибо за видео Вообще рекомендуется ещё не использовать приватные методы в классе

[@ИльдарБулатов-т4х]

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

[@danielshabarov5661]

22:22

[@Kadabra1981]

Автор просто клал на производительность от слова совсем - дублирует циклы, увеличивает количество вызовов, меняет циклы на стримы. Накладные расходы на всю эту "красоту" автора не волнуют. "Замеры не производились" - ультимативный аргумент. Вот после таких сеньоров люди потом недоумевает почему Ворд на i7 работает как на pentium3.

[@evgeniichuprov]

Хорошо иметь встроенный профайлер в голове, да?

[@Kadabra1981]

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

[@evgeniichuprov]

@@Kadabra1981 не эксперт по jvm, но доводилось оптимизировать код на С++ для embedded system. Я тоже не сторонник разбивать циклы в общем случае, но видел на что иногда способны компиляторы с точки зрения оптимизации, поэтому каждый случай может быть индивидуален. И что точно меня коробит, так это предварительная оптимизация (хз как правильно перевести premature optimization). Тут разница может быть незаметные доли секунды, тогда как рядом есть неоптимальный запрос к базе данных или к файловой системе, которые будут нивелировать всю выгоду от такого объединённого цикла. В общем, я к тому, что контекст важен.

[@ИванНикитин-ч7б]

Рабочий процесс гуру (Кента Бека): 1. Напиши рабочее говно; 2. Сделай из говна конфетку (отрефакторь); 3. Оптимизируй, только если очень очень надо. Если ты видишь неоптимизированные куски кода, то либо автору так не критично, либо он ещё не дошёл до стадии 3. Другой известный всем ненубам гуру (Дональд Кнут) говорит: преждевременная оптимизация - корень всех зол.

[@ProGuitarUA]

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

[@TinTaBraSS777]

ты не синьер помидор ты синьер мухомор )

[@XpIOHdeJIb3000]

сначала глобальные переменные быдлокодом назвали, теперь до локальных добрались.

[@heheheyhey5234]

Глупость. Если в сложной бизнес логике сокращать длину кода до 5 строк, в итоге это будет ПРОСТО НЕВОЗМОЖНО поддерживать и читать следующим людям. Если писать большие программы в стиле "Cean Code" вы получите еле работающее чудовище.

[@ИльяПетров-р3о]

Молодец какой. Сам придумал учебный говнокод, сам переписал )))

[@Anton-kh9bj]

Хочешь просрать время - напиши тесты к коду

[@onetwothree123-]

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

[@user-mc8tn9qn3d]

2022год в джаве до сих пор клоунские геттеры и сеттеры

[@Tezla0]

А какие надо?

[@alexgorodecky1661]

Жиза

[@george-harder]

kzbin.info/www/bejne/m5u7qYquqZirhc0 Главное, не дорефакториться до примерно такого: result += first.getSomething(second.GetAnother() * third.GetWhatever(42)) / (100 + vat.GetVat(false)) * vat.GetVat(true); Ненуачо. Сколько локальных переменных сэкономили! Во всём нужна мера. И это чувство меры воспитывается (не у всех, правда) десятками лет впахивания в разработке.