LINUX.ORG.RU

Ревью кода или психология мидла

 ,


3

8

Всем привет!

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

И любит он делать херовый код (плохой нейминг, непонятные и ненужные абстракции, каша в логике). Если пнуть, то обычно исправляет. Но я уже заманался его пинать, одни и те же ошибки в каждом МР. Уволить?! Как говорит начальство — не можем, бюджет не позволяет платить больше кому-то, а найти нового человека сейчас очень сложно.

Стараюсь дать ему возможность подумать и самому сделать так, чтобы было красиво, но получается все равно какая-то каша которую по 3-4 часа ревьювишь и пишешь куски кода для того чтобы он порефакторил правильно.

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

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

★★★★

Последнее исправление: maxcom (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

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

AKonia ★★
()
Ответ на: комментарий от Mobutu_Sese_Seko

мааасковские пааанты

Понты обычно у всяких понаехавших «принцесс» которые вышли замуж за прописку и которые боятся сесть в самолёт потому что губы лопнуть могут

upcFrost ★★★★★
()
Ответ на: комментарий от anonymous

Ну если не пользоваться системами управления исходным кодом, историей с метаданными и blame в них

Ваша капля оказалась последней в чаше. Вчера наваял на CREATE EVENT TRIGGER ON ddl_command_end перехват изменений в процедурах ПГ и отправку их в git.

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

Toxo2 ★★★★
()

Код пишется один раз. Читается множество. Поэтому любые усилия направленные на улучшение его читаемости – действие в верном направлении.

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

Составьте свод правил, как уже советовали, и просто отсылайте к нему. Дополняйте его. Да и всё. Меньше действий себе, больше оппоненту.

И не надо пытаться искать проблему в себе или в оппоненте – это путь к поражению. Личное в таких вопросах вообще должно отсутствовать. Потому что это не вопрос индивидуумов и личностей, а вопрос технологии. Типа, как правильно печь блины.

thegoldone ★★
()
Ответ на: комментарий от snizovtsev

Поэтому такая ситуация встречается повсеместно и плодится в IT как грибы после дождя.

Так может стоит менять систему, если система поощряет создание говна?

pihter ★★★★★
()
Ответ на: комментарий от thegoldone

Составьте свод правил, как уже советовали, и просто отсылайте к нему

Автор пишет на Rust систему Нипель с DDD и всеми паттернами из говенных книжек Мартина (для Java). Почему его оппонент не прав? Если в вопрос в читаемости, то с его дрисней другие погроммисты в последующем разбираться не станут, а просто все перепишут на другом языке (той же Java)

rtxtxtrx ★★
()
Ответ на: комментарий от rtxtxtrx

Ну так DDD самое то. DDD и CLEAN. Проблема работы с ними нулевая, если использовать архитектурное проектирование (в принципе, но желательно до начала работы), и соответствующие инструменты.

А подход, когда программист сам и архитектор – это как нанять себе строителей из Средней Азии для строительства собственного дома. Такие подходы годятся очень мало где. Но точно не в серьёзных проектах. Их желательно искоренять. Если конечно там этот оппонент за небольшую зарплату шабашит, чтобы работодатель сэкономил, что вряд ли, то можно его не сильно презирать за самодеятельность.

thegoldone ★★
()
Ответ на: комментарий от thegoldone

Ну так DDD самое то. DDD и CLEAN.

Rust - это язык без наследования, полноценного ООП и тп. Он примитивный как C - почти ASSembler. Я много дерьма видел типа ООП на Баше… и все это примерно из той же оперы. Я бы заставил ОПа написать по собственному, пусть валит на 4 стороны. В любом языке есть свой стиль, которому ты начинаешь подражать после изучения тонн исходников, где подсматриваешь какие-то лучшие решения, и тут появляется юное дарование с клин кодом, которое учит батьку трахаться… Есть DRY и KISS. Это главные принципы. Распухание кода из-за ООП ради ООП - это намного большая проблема чем его уродство, так как чем меньше кода, тем меньше вероятность совершить ошибку. Если нравится Мартин, т̶о̶ ̶н̶а̶ ̶н̶е̶м̶ ̶н̶а̶д̶о̶ ̶ж̶е̶н̶и̶т̶ь̶с̶я̶ просто писать на Java

rtxtxtrx ★★
()
Ответ на: комментарий от thegoldone

А подход, когда программист сам и архитектор – это как нанять себе строителей из Средней Азии для строительства собственного дома. Такие подходы годятся очень мало где. Но точно не в серьёзных проектах. Их желательно искоренять.

Опа. Проснулся великий Мамкин какир с сурьёзными проектами. Давай определение сурьёзности.

anonymous
()
Ответ на: комментарий от rtxtxtrx

Такое ощущение, что на какой-то свой внутренний диалог Вы ответили мне.

Я всё же уточню, что ООП никакого отношения не имеет к DDD и CLEAN. Более того к языку программирования последние вообще не имеют отношения.

А DRY бывает вреден, например, когда сушка приводит к связыванию несвязанных частей.

Про KISS. Одно дело делать проще для себя, и другое делать проще для всех работников проекта на предполагаемый срок его жизни.

Если провести аналогию с египетскими пирамидами, то разработчик – это обычный раб. И свои высокие мысли он может оставить с собой. Учёный грек – это техлид. Который возвращает код на доработку. Нач. отдела выступает в роли надсмотрщика с плёткой. Если раб делает что-то не то, то его наказывают. Всем этим подходам уже более 5 тысяч лет.

thegoldone ★★
()
Последнее исправление: thegoldone (всего исправлений: 2)
Ответ на: комментарий от thegoldone

У меня проект на поддержке, в котором я руководил раньше, в нем никто кроме меня больше полугода не работал и было больше десятка разных разрабов, а у тебя влажные фантазии мол хорошо для меня. Меня ли? Любой новый разраб с полпинка должен понимать, что как работает, а не разбираться в писание очередного непризнанного гения с раздутым до неба ЧСВ. Я рассуждаю как человек, который понимает реалии рыночка, которому плевать на всю эту рахитектуру. И в больших конторах везде тяп-ляп и в продакшн. DRY (повторяющийся код выносим в отдельные функции, классы, модули) и KISS (код должен быть понятен джуну)

rtxtxtrx ★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 2)

Я так понимаю автор темы до сих пор стесняется показать проблемный с его точки зрения пример кода со своими исправлениями? А чего так? 5 страниц обсуждений ни о чем. Вы либо код покажите либо трусы наденьте.

Obezyan
()
Ответ на: комментарий от rtxtxtrx

Почему

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

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

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

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

olelookoe ★★★
()
Ответ на: комментарий от rtxtxtrx

Рынок тут вообще не при чём. Речь не про него. У Вас опять разговор со своим внутренним оппонентом вырывается наружу. Мне он не интересен.

Любой новый разраб с полпинка должен понимать, что как работает

Только при чём тут код. Если описание работы приложения – это про документацию. Документировать прямо в коде можно только очень небольшие проекты без сложной внутренней логики.

Странная ситуация, для строительства дома нужен какой-никакой проект. А для ПО за бо́льшую цену просто нанять рабов, согнать в кучу и бросать в них задания, это Ваш гениальный подход? Если так, что со сложными проектами Вы никогда не работали. Либо выезжали только за счёт сильных разработчиков.

thegoldone ★★
()
Ответ на: комментарий от thegoldone

Вы никогда не работали. Либо выезжали только за счёт сильных разработчиков

Это ты скорее всего кода не писал прочитал мартына и пересказываешь. В жизни все не так. Ага, забудьте чему вас учили

rtxtxtrx ★★
()
Ответ на: комментарий от Nervous

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

rtxtxtrx ★★
()
Ответ на: комментарий от rtxtxtrx

Rust - это язык без наследования, полноценного ООП и тп.

Ты не прав, потому что DDD и CleanCode завязаны на наследование и ООП чуть менее чем ни как, все остальные выводы так же мимо.

AntonyRF ★★★★
() автор топика

ВНИМАНИЕ

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

Многие вопросы задаются неоднократно разными людьми и советы так же повторяются многими людьми. Так же я понимаю, что нужны примеры кода и больше обьяснение чтобы заинтересованные товарищи могли глубже проанализировать кому ставить клоунский emoji.

Но я катастрофически не успеваю поучаствовать в беседе и плюс у меня корпоратив, семья, жизнь вне ЛОРа. Обещаю воскресить эту тему с кучей примеров и деталей, но пока вынужден исчезнуть. Всем спасибо!

AntonyRF ★★★★
() автор топика
Ответ на: комментарий от AntonyRF

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

whereisthelinus
()
Ответ на: комментарий от whereisthelinus

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

AntonyRF ★★★★
() автор топика

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

anonymous
()
Ответ на: комментарий от anonymous

Да в рот я бомбил того оленя. Есть техлид и он решает, что правильно, а что нет. А «клёвые» разработчики появляются и исчезают. Точно также накосячил и всё испортив в говно. Со своими, как им кажется, офигительными идеями.

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

А если доверия нет, пресловутое – «я знаю как правильно» – дома со своей пассией обсудишь. А здесь не ты это решаешь и всё.

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

Обычное дело в ИТ. Оленёнок прокачал свои навыки программиста, а остальные так и остались на нуле. И обычный конфликт, который решается простым – «завались» – раздувается в драму на форуме.

anonymous
()
22 февраля 2024 г.
Ответ на: комментарий от Nervous

конечно.

пишишь файл

запускаешь файл

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

в яме тьюринга есть всё

особенно всё есть при игнорировании издержек

qulinxao3 ★☆
()
Ответ на: комментарий от tr0_

вполне годные в

The Elements of Programming Style, 2nd Edition

а уж в

Лисков, Б.; Гатэг, Дж. Использование абстракций и спецификаций при разработке программ Издательство: М.: Мир Переплет: твердый; 424 страниц; 1989 г. ISBN: 5-03-000489-0

ваще пол жабы

qulinxao3 ★☆
()