LINUX.ORG.RU

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

 ,


3

8

Всем привет!

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

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

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

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

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

★★★★

Последнее исправление: maxcom (всего исправлений: 1)

в помощь моему проекту

строго говоря и проект не твой :)

Что обычно делают в таких ситуациях?

ставят бывалого сейнера с полномочиями коде-pwnerа в репозитории и правом решающего слова по спорным мерж-реквестам, чтоб осадить ретивого мидла ТСа, разводящего на проекте банальную дедовщину на основе каких-то неформальных критериев :)

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

э, залагынса!

P.S.: в любом из случаев бизнес только выиграет, если научится/решится/станет замечать проблемы внутри себя.

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

P.S.: в любом из случаев бизнес только выиграет, если научится/решится/станет замечать проблемы внутри себя.

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

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

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

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

aol ★★★★★
()

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

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

Что обычно делают в таких ситуациях?

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

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

В роли редактора тоже ловил клин и начинал чуть ли не полностью переписывать за другими. В паре случаев это действительно было оправдано, т.к. люди откровенно не тянули. Но в большинстве случаев это я сам ловил тупак в стиле «они пишут не так как я -> они пишут неправильно». Потом я расслабился и понял, что такой авторитаризм ни к чему.

В общем, что я хочу сказать: тебе нужно тщательно обдумать, насколько твоя строгость объективна. И попробуй поставить себя на место этого коллеги. Если он реально чего-то не понимает или не может осилить - попробуй раскрыть эти темы для него как-нибудь «на пальцах», только без давления и токсичности.

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

Потом я расслабился и понял, что такой авторитаризм ни к чему.

Потому что у тебя задача не «сделать идеально для меня», а «сделать продукт, удовлетворяющий таким-то критериям».

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

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

Я к тому, что работодатель либо не заинтересован решать этот вопрос либо хочет решить его за счёт ТС. В первом варианте деятельность ТС - донкихотство, во втором варианте, имхо, вообще не очень этим заниматься.

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

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

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

В любом из случаев это твой манямирок и вишфул мышление, т.к.

но по моим наблюдениям, бизнес это делать не любит

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

anonymous
()

Мидл выражает недовольство мидлом:

[code] Мартышка, в Зеркале увидя образ свой. ‎Тихохонько Медведя толк ногой: ‎«Смотри-ка», говорит: «кум милый мой! ‎Что́ это там за рожа? Какие у нее ужимки и прыжки! ‎Я удавилась бы с тоски, Когда бы на нее хоть чуть была похожа. ‎А, ведь, признайся, есть Из кумушек моих таких кривляк пять-шесть: 10Я даже их могу по пальцам перечесть».— ‎«Чем кумушек считать трудиться, Не лучше ль на себя, кума, оборотиться?» ‎Ей Мишка отвечал. Но Мишенькин совет лишь попусту пропал. [/code]

anonymous
()

в котором стандартные компоненты типа - use-case’ы, доменные сервисы, entities, aggregates, repositorie

плохой нейминг, непонятные и ненужные абстракции, каша в логике

но получается все равно какая-то каша которую по 3-4 часа ревьювишь

ТС, улавливаешь?

anonymous
()

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

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

Не каждый будет делать код, как ты хочешь.

А вот этого вообще никогда не происходит.

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

У всего есть своя обратная сторона.

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

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

У меня для тебя плохие новости. Сейчас такое бывает даже у военных (когда майоров и подполковников дохрена и формально их ранжировать сложновато). А уж в гражданских организациях и подавно, причём даже с формой собственности предприятия это коррелирует довольно слабо.

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

Сейчас такое бывает даже у военных

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

Но мне это не сильно жало, ЧСВ только если, а оно за общей задолбанностью как-то замолкло. По ЗП там разница в пару тыщ была всего между инженегром и начальником инженегров.

Но это да, хреновая бюрократия и контора в целом, тут я согласен с оратором выше.

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

Правда, самые покладистые в этом плане программисты — это люди с психологией вечного джуна.

Да ну почему? Если ты хороший специалист, это не значит, что надо положить болт на принятые стандарты и писать отсебятину. Это скорее пахнет дедами в НИИ, которые будут до усрачки доказывать, что они так 40 лет делали и будут делать дальше, а все эти ваши кодстайлы или требования им по болту.

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

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

Тоже так думаю.

Если ТС официально рулит и, главное, отвечает за результат — он вполне имеет право на то, что пытается делать. Если нет, и они по сути равны, то непонятно, зачем ему это.

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

Если ты хороший специалист, это не значит, что надо положить болт на принятые стандарты и писать отсебятину

А я и не утверждал, что «надо». И я даже не про «плохой-хороший», а скорее, про тип мышления. Творческое начало и исполнительская дисциплина в одном человеке сочетаются редко.

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

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

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

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

идти к краху, за который ты не в ответе

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

Но это не про код. Это про крах и ответственность за него.

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

У нас с ним даже отступы разные. У него пробелы, у меня табы. Так даже удобнее получается - открываешь хранимку и сразу видишь кто из нас писал и какие изменения вносил - можно поинтересоваться «с фига ли именно так», при большом желании.

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

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

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

Ой, всё сильно правильно у вас.

Мне тоже хотелось правильно, но ни на одном проекте совершенства не удалось добиться. И базарно сделанные проекты оказывались успешнее соборных.

Точно не перегибаете?

blex ★★
()

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

Тут либо расставаться, либо поговорить по душам и потом все равно расстаться. Потому что ну вот так.

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

Так жалко ж контору

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

alex1101
()

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

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

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

Были у нас как-то два программиста. Один писал прямо, в лобовую. Вижу байт, пишу байт. Другой обожал накуролесить — шаблон на шаблоне и структурой погоняет. И еще какие-нибудь лямбды приплетет, которые потом старыми компиляторами не собираются.

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

Ну не сходятся они, такое бывает.

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

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

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

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

Ага. Сказка ложь, да в ней намёк…

Иногда за борьбой за красоту кода легко потерять полкоманды. Как тут многие предлагают ТС уволиться или заставить уволиться непокорного.

monk ★★★★★
()

Во первых покажи, пример его кода и того, как ты хочешь это исправить.

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

Далее, сколько он работает на проекте и сколько ты?

Его устроили по знакомству?

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

раз я по факту работаю за другого человека

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

rumgot ★★★★★
()