Программирование[11]

Index написал 3 часа назад:

а тимлид ругается что МРики не минимальные.

скажи ему чтобы отвалил, что ты художник и так видишь

аухеть, чел сам рефачит чтобы был норм код, а ему за это по рукам дают

Index написал 3 часа назад:

Ну и чет с одной стороны требование типо пиши говнокод абы быстре, а с другой стороны по часу обсуждать как домен "ХУЙ" обозвать чтобы не матерно было

а что за компания, напомни

Just.Doit написал 13 часов назад:

аухеть, чел сам рефачит чтобы был норм код, а ему за это по рукам дают

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

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

Index написал 16 часов назад:

а ещё ощущение что ты в бигтехе мелкий хуй на которого всем похуй (кроме твоего тимлида который от тебя закрытые тасочки требует)

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

ещё более неприятный нюанс - что то что ты ебашер/ультрасотрдуник/дохуя крут/дохуя сделал и дохуя ценный - в общем-то знает тимлид этого наноподразделения. тимлиды меняются и знания теряются. наверно только гитхаб компании может что-то объективное сказать, что чел Х закоммитил уже 1001й коммит в репу Y и делает это годами. в остальном, 1-2 уровня выше и кто ты такой никому неизвестно и неинтересно. это хуёво и с точки зрения роста, так и с той точки зрения, что в случае проблем можно легко кик получить. т.е. ситуации разные, когда ты ценный и это знают и если что жопу прикроют, и когда ты тоже самое, но тимлид другой и ты просто юнит в пачке, будет всё сложнее.

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

Делать рефакторинги в критичном коде без тестов - такая себе идея. Если уж собрался рефакторить - обложи тестами с начала. Или действуй по принципу "работает - не трогай".

Index написал 16 часов назад:

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

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

Рефакторинг предпочительно должен быть отдельным МР.

Когда ты пишешь код, конечно хочется просто переписать и сделать как лучше. Да и ты в контексте, потому "чо тут ревьювить то апрувь, и спасибо скажи".

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

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

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

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

Olololnet написал 1 час назад:

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

соглы, но контекст индекса кажется сильно другой. 

Olololnet написал 1 час назад:

рефакторинг вносит риск нестабильности/проблем

ммм, любые изменения его вносят

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

индекс, у вас так?

GoldRobot написал 29 минут назад:

потому что сложность МР растет экспонециально с каждым изменением.

не соглы что всегда так. 

часто бывает что рефакторинг упрощает код и становится гораздо проще его понимать

у меня был кейс там было 2-3 логики (условно функции) которые делают почти одно и тоже но написаны были с нуля 2 раза и местами были не консистентны.

грубо говоря сложная валидация узлов дерева. сначала на этапе перед запуском дерева (AOT), а потом уже в рантайме.

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

Это похоже на валидацию на фронте и на беке - валидация должна быть идентичная, но часто это не так тк код де факто разный.

ну вот я переписал чтобы использовался ровно 1 код для этих валидаций и оно гарантировало что проверки будут идентичные. это щас легко сказать. но тогда я дня 3 думал и рефакторил тк исходные инпуты этих проверок сильно разные в АОТ и рантайме. и даже со всей мощью и гибкости скалы было тяжело это обобщить корректно.

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

еще были кейсы что в коде половина инвариантов уже не существует и никто не занимался их расчисткой, в итоге у тебя вариантов объектов и их обработок по коду 10, а по факту 3-5. вычищая их и предоставляя статически типы только про них, ты видишь что здесь вот только 3 варианта возможны на уровне типов и тебе меньше в голове прокручивтаь приходится, тк уже ограничено все до минимума

GoldRobot написал 29 минут назад:

Index написал 17 часов назад:

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

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

Рефакторинг предпочительно должен быть отдельным МР.

 

 

Когда ты пишешь код, конечно хочется просто переписать и сделать как лучше. Да и ты в контексте, потому "чо тут ревьювить то апрувь, и спасибо скажи".

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

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

 

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

 

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

  да я полностью согласен

но мой поинт что тимлид не бухтеть и бить по рукам должен, а направить эту энергию чела в нужное русло и обхяснить что вот надо делать за 3 МРа и тд и тп

Just.Doit написал 21 минуту назад:

но мой поинт что тимлид не бухтеть и бить по рукам должен, а направить эту энергию чела в нужное русло и обхяснить что вот надо делать за 3 МРа и тд и тп

Согласен с такой постановкой полностью.

СЛАВА КПСС - ВЛАДИМИР ПУТИН

СЛАВА КПСС

484 тыс. подписчиков

Подписаться

6,7 млн просмотров 6 лет назад

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

Just.Doit написал 7 часов назад:

ммм, любые изменения его вносят

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

индекс, у вас так?

Да мы MVP делаем 

Тоесть, пару дней назад кто-то закомитил функционал. Челики его заревьювили, "все супер, мерджим".

И тут ты воврвался "я тут ваше говно переписал"?

GoldRobot написал 1 час назад:

Тоесть, пару дней назад кто-то закомитил функционал. Челики его заревьювили, "все супер, мерджим".

И тут ты воврвался "я тут ваше говно переписал"?

тож не совсем понял че там рефакторить в мвп

блять я подумал тут мм топик, сори

Не сильно отличается, пиши

Just.Doit написал 22 часа назад:

ммм, любые изменения его вносят

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

индекс, у вас так?

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

Olololnet написал 1 час назад:

Just.Doit написал 23 часа назад:

ммм, любые изменения его вносят

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

индекс, у вас так?

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

не понял мысль(

Arzanis написал 23 часа назад:

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

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

Just.Doit написал 13 минут назад:

Olololnet написал 1 час назад:

Just.Doit написал 19.05.2024 в 14:08:

ммм, любые изменения его вносят

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

индекс, у вас так?

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

не понял мысль(

иначе говоря, чем важнее код, тем меньше вероятность и адекватность попытки рефакторинга

Читаю новости про всякие нейросети,ИИ, чаты и просто охуеваю. Такое ощущение, вопрос времени, когда какие- нибудь  "Тапочники" прикрутят ИИ к каким- нибудь беспилотникам, а там скайнет прЫйде.

Жухлый Жмых написал 16 минут назад:

Читаю новости про всякие нейросети,ИИ, чаты и просто охуеваю. Такое ощущение, вопрос времени, когда какие- нибудь  "Тапочники" прикрутят ИИ к каким- нибудь беспилотникам, а там скайнет прЫйде.

Пока что очень далеко от этого. Так как никакого ИИ еще нет.

Кроме того для серьезных вещей требуются большие мощности.

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