Comments 123
Старое, давным-давно безотказно работающее правило: Хочешь, чтобы что-то было сделано хорошо? Сделай это сам!.... И это касается не только программирования.
В поле каждый суслик агроном...
Если все делают хорошо(потому, как делают сами), откуда неэффективные и провальные решения?
Слишком высокие стали требования к решениям. И вот уже достаточно хорошие решения называются провальными.
В 95% случаев это не связано с уровнем программиста.
нереальный дедлайн, когда надо пушнуть в прод уже вчера
отсутствие внятной конечной цели, когда требования меняются буквально на противоположные чуть ли не еженедельно
внезапный взрывной рост, когда куча скриптов написанная во время корпоративного хакатона вдруг масшабируется в распределенную систему с миллионами транзакций
а теперь ещё и вайбкодинг, когда классы данных фильтруются с помощью регулярных выражений применённых к выхлопу "to string()"
Но приходилось видеть и горе от ума, например, когда в коде используется штук 5 state машин или куча функций вызывают друг друга и передаются в качестве аргументов. Расширять функционал таких творений особенно без документации и тестов то ещё удовольствие, сравнимое с реверс-инжинирингом китайских прошивок.
отсутствие внятной конечной цели, когда требования меняются буквально на противоположные чуть ли не еженедельно
@search: Программисты очень часто занимаются производством велосипедов, которые, возможно, полетят в космос, а, возможно, отправятся исследовать дно океана.
В 95% случаев это не связано с уровнем программиста.
То что человек берётся за работу, которую гарантировано не сможет сделать хорошо, это как раз вопрос его уровня.
То что человек берётся за работу, которую гарантировано не сможет сделать хорошо, это как раз вопрос его уровня.
То, что человека посадили на должность, с которой он гарантированно не может справиться — это как раз вопрос компетенции его руководителя. Впрочем, тогда выходит, что и к руководителю это тоже относится...
Каждый должен отвечать за себя.
Каждый должен отвечать за себя.
Да что ви такое говорите, господин директор!
Я по другую сторону прилавка.
Меня не устраивает ситуация, когда рукожопы делают своё рукожопство, а потом говорят "да, ваши данные/работы/время пошли по ... , но у меня было мало времени качественную".
Не можешь - не берись.
Тогда господин заказчик ставит подпись на документе с конкретным перечнем требований и метрик.
И если "хорошо" вдруг меняется с обработки тысячи транзакций в минуту при расходах на инфраструктуру в 100 баксов в месяц на миллион транзакций в секунду за те же $100 в месяц, то платите сколько попросим, а не по принципу "тут ничего не меняется, просто надо чуть-чуть скорость увеличить".
А теперь постройте аналогичные рассуждения о том, как продавщицы в продуктовых магазинах моют испортившуюся колбасу для последующей продажи, а мы, как покупатели, должны войти в их положение, потому что их начальство не оставило им выбора.
продавщицы в продуктовых магазинах моют испортившуюся колбасу для последующей продажи, а мы, как покупатели, должны войти в их положение, потому что их начальство не оставило им выбора.
«Их начальство не оставило им выбора» — продавщицы разве цепями к прилавку прикованы? У них есть как минимум есть выбор «продолжать так делать» иди «уволиться». Так что не надо делать фактически некорректные заявления — Вы программист или где?
«Их начальство не оставило им выбора» — продавщицы разве цепями к прилавку прикованы? У них есть как минимум есть выбор «продолжать так делать» иди «уволиться». Так что не надо делать фактически некорректные заявления
И чем это отличается от обсуждаемых программистов?
Их цепями приковали к клавиатуре?
У них нет выбора "уволиться"?
Так в чём же сравнение некорректное?
Сколько раз повторять: у меня замечания не ко всему диалогу со времён Царя Гороха, а к одной конкретной реплике, которую я потому и цитирую.
И в чём состоит задекларированная Вами некорректность это конкретной реплики?
«начальство продавцов не оставило им выбора».
Выбор есть всегда. Просто нередко это выбор между плохим и (не хорошим, но тоже на Х). И даже несмотря на это некоторые его вполне себе делают.
Вы же шутите, да?
Вы же не могли не заметить, что комментарий начинается с фразы "А теперь постройте аналогичные рассуждения о том, как".
Практика показывает, что Вы умеете читать, и способны понять, что "начальство продавцов не оставило им выбора" это не утверждение, которое я делаю.
Так зачем делать Вид, что Вы не поняли о чём речь?
У продавщиц в ТБ написано, что нельзя порченные продукты выставлять на прилавок и если нарушать правила, то служба защиты потребителей придет и даст звёзды всем, а не только начальству.ТБ существует годами и на адаптацию к любому изменению в нем тоже дают время.
Я тут читаю и не могу понять вы троллите или серьезно не понимаете, что мир не Понивиль где невозможно точно оценить и сделать все хорошо в первого раза? В нормальных процессах закладывается время как и на исправление ошибок, так и на уточнение/ правки клиента, из-за неполной информации которого чаще всего баги и происходят. Это нормальный процесс и задача профи это довести продукт до ума, а не без погрешности оценить время и стоимость разработки
Если Вы пролистаете наверх, то увидите, что обсуждается ситуация, когда программист понимает что делает хрень, но это оправдывается тем, что ему задание поздно выдали.
То есть, в момент начала работы, уже известно что будет хрень.
Это не "сложно сделать с первого раза", а "сразу понятно что будет хрень"
работу, которую гарантировано не сможет сделать хорошо
Невозможно сделать «хорошо», когда на это нет (или не хотят / не могут выделять) ни сроков, ни бюджета, а вместо долгосрочного планирования и технической документации быстрые пивоты и недопонимния «ой, оказывается нам надо вот это».
Невозможно?
Не берись!
Если ты бездомный - купи дом, если ударили - не ударяйся, если обидели - не обижайся.
Бездомный не может купить себе дом, а работник может уйти с работы, где его заставляют делать говно. Оставаться и вредить конечному потребителю, это его сознательный выбор для получения личной материальной выгоды.
Главная проблема, которую до сих пор не понимает айтишная и околоайтишная тусовка состоит в том, что больше нет деления на важный реальный мир и второстепенный виртуальный.
Сейчас мир в таком состоянии, что даже самый айтишный айтишник в абсолютном большинстве случаев находится в роли потребителя, явно или неявно.
Держаться за корпоративную солидарность и отмазывать рукожопов становится опасно - завтра в любого из нас может въехать самоуправляемый автомобиль, который запрограммировали рукожопы.
Любому из нас могут начать списывать деньги со счёта, потому что скобка не там закрыта.
В любой момент любой из нас может попасть под какую-нибудь автоматическую скоринговую систему, которая начнёт портить жизнь.
Если все делают хорошо, откуда неэффективные и провальные решения?
Вы пропускаете, первую часть фразы
Хочешь, чтобы что-то было сделано хорошо?
Так вот, большинству - пофиг, они не хотят хорошо. Даже если они "делают сами".
Старое, плохое решение, ведущее к тому, что один разработчик, часто даже не очень хороший, но зато с очень большим самомнением, гадит всей команде, молча делая «хорошо».
Интересная логика:
1й говорит: а может быть сделать по другому? Бах коммит
2й говорит: не а может быть было бы неплохо вот так? Бах коммит
3й: да ну ерунда вначале было лучше: Бах коммит
1й: и чем же оно лучше? давай так: Бах коммит
Складывается, что по ту сторону не опытный программер сидит, а какой то АИшка, которому как скажут, так и сделает.
Или я не догнал мысль статьи?
Мы ленивые. Если дойдёт до 4-х коммитов, значит проблема важная.
На практике будет:
1й говорит: а может быть сделать по другому? Бах коммит
2й говорит: вот тебе не пофиг, апрув.
Вот да.
Если бы в мой PR/MR вносили коммиты без объяснения, переписывая мой код, то я бы задумалась.
Как минимум, сама концепция PR подразумевает обсуждения конкретных решений и их правку, если это требует того. Максимум, что можно сделать, это в комментариях к коду привести кусок кода, как считает лучше переделать ревьювер.
Лезть молча коммитами в чужой запрос на изменение - это верх неуважения к коллеге.
Помимо этого, если кто-то закоммитит в мой запрос что-то, то я непременно полезу смотреть, а что же там поменяли и задамся вопросами "зачем? почему? для чего?". А это трата моего времени на чтение чужого кода в МОЕМ запросе.
Да и также ревьювер не всегда в контексте задачи и может натворить делов, переписывая рабочий код.
В общем, в такой команде я бы не задержалась. Я уважаю свой труд и труд своих коллег.
Как вариант - речь о программере-одиночке? Который настолько преисполнился, что в гробу видел спорить с кем то - просто берет и делает проект либо его кусок в соло.
Вообще не смотрю на стиль написания, у каждого свой стиль и вкус, я могу решить задачу за 5 строк кода, другой человек за 30 строк и это нормально, главное чтобы код достигал нужный результат, не было логических ошибок и код был покрыт тестами.
А как же производительность, читаемость кода, потребление памяти? Можно сильно по-разному писать, и вроде будет работать, но один вариант медленнее, другой потребляет больше памяти, третий плохо читаемый. Для разработки всë это важно, если нужен хороший продукт на выходе и возможность нормально поддерживать код дальше в будущем.
Да и пофиг, будем решать по мере поступления проблем. Тесты почти всегда все отлавливают. Нет времени этим заниматься, нужно пилить новые фичи иначе не выполним цель квартала и не получим бонусы.
возможность нормально поддерживать код дальше в будущем
тут всё просто - высокий ковердж в тестах. Тесты спасают от реграсса при рефакторинге 100% информация.
В среднем нагенерированные нейронкой тесты вообще не от чего не спасают. Зато при рефакторинге требуют переписывания ещё и тестов.
Ахаха, вам пишут что читать и поддерживать такой код такой - мучение, а вы говорите, каверадж тесты.
Этот условный 5 строчный понос растянутый на 30 строк я даже читать бы не стал. Не то чтоб его рефакторить или недайбох расширять. Ваще там у себя все принципы за three hundred bucks премии потеряли лол. А ещё нейронки зло при этом, я ору 😄 Вся ваша контора зло, которое обходить лучше по широкой дуге ))
Вообще не смотрю на стиль написания, у каждого свой стиль и вкус, я могу решить задачу за 5 строк кода, другой человек за 30 строк
Смотря что считать «стилем». Если пробелы vs табы и имена переменных через _ vs камельком, то лично я ничего против не имею (хотя знаю многих, кого это бесит). Да, в единообразии есть красота, зато в разнобое есть удобство. Я без всяких гитов и блеймов вижу, кто какую строчку писал, и кто всё испортил. По почерку. И хеш-подпись не нужна.
А вот если речь про записали сложное преобразование одним декларативным выражением vs написали 25 вложенных циклов, то извиниииите. Такую лягушку можете сахаром тестов хоть всю обсыпать, я не француз. Как это править потом? Что мне ваши тесты, разбираться в коде тесты не помогут.
P.S. Но если этот код сделать маленьким, изолированным и закреплённым строго за одним автором, моя терпимость резко возрастёт. Для этого, правда, нужен очень хороший архитектор, который нарежет проект на кусочки правильным способом.
Вообще не смотрю на стиль написания, у каждого свой стиль и вкус, я могу решить задачу за 5 строк кода, другой человек за 30 строк и это нормально
Я тоже раньше так думал, что нормально, но потом все же пришел к выводу, что они не имеют вкуса и не умеют мыслить. А замечать я это начал тогда, когда портянки с кодом на 30 строк вместо 5, стали поступать от одних и тех же людей, они в любом коде умудряются мыслить через зад и раздувать писанину.
И да и нет. С одной стороны, действительно глупо выполнять работу, предназначенную стайлчекинг-тулам и статическим анализаторам, будучи ревьюером, и душиться за каждый вшивый литерал в МРе. Но единый стиль и качество все же важны.
Я бы не стал участвовать в проекте, где каждый пишет как ему хочется.
... потому что может! А вода мокрая.
статья написана ai ?
Слушайте, вы если используете нейронки для текстов, так хоть пишите что-то интересное, зачем писать очередную статью про "А вот опытный программист сделал бы так". Ну потрудитесь хоть чуть-чуть, возьмите свои какие-то наблюдения, выводы, опыт, опишите их нейронке и скажите: "Вот из этого статью мне сбацай чтобы красиво было". А не очередное переливание из пустого в порожнее. Или делайте тогда уже видео с той дебильной нейро озвучкой если уж так хочется "творчества" и туда это пихайте.
Астрономы хабра объявляют неделю статей "Опытный программист это".
это значит что у вас очень плохая атмосфера в команде. И начнут друг друга код переписывать и переделывать на "читаемое и удобное" (не читаемое и не удобное)
Такое поведение "опытного" программиста - от усталости и нежелания делать хорошо и качественно. Чтобы понять, что такое хорошо и качественно в вашей команде - надо обсуждать это с коллегами.
Когда ты оставляешь 10 замечаний, например, по организации кода, а коллега их молча правит, то смысл ревью такого? Один потратил время на ревью и формулировку замечаний, а второй потратил время на то, что закрыть замечания первого.
К чему это приводит? К тому что ревью становится просто формальностью. Формальное ревью - деградация кодовой базы.
Вся эта молчаливая работа - это про бизнес, про рутинное решение задач, не обращая внимания, например, на техдолг, на обсуждение которого надо потратить время, в том числе и в рамках PR.
Если вы "легли" под бизнес, ради бога, но не утверждайте, что такая модель поведения профессиональнее. Это не так.
P.S. Автор предлагает вместо обсуждения самому делать правку в PR коллеги, чтобы не обсуждать? Забавно =)
Молча править - нормально, если замечания справедливые. Оставлены потенциальные ошибки, "у нас так не принято", кодстайл, что угодно "системное". Вкусовщину можно обсудить, но на то она и вкусовщина, что можно и не обсуждать.
Чтобы понять, что такое хорошо и качественно в вашей команде - надо обсуждать это с коллегами.
Скажу щас крамольную и токсичную вещь, но для себя я пришел к выводу что я в корне не согласен.
Хорошо и качественно == в соответствии требованиям и регламенту, которые предьявляет команде ее лид, ответственная за конечный результат должность. Обсуждать тот или иной вопрос с коллегами или принять решение самостоятельно - выбор лида, но слово лида должно быть окончательное и пресекающее любые возражения.
В противном случае, ревью-ремарки превращаются в нескончаемую тусовку демагогов.
"Удивительно, насколько "зрелая мудрость" напоминает простую усталость. " (с)Robert A.Heinlein
Python пример ужасен. Мне как не знакомому с синтаксисом Python, на много понятен первый вариант. Чем исправленный вариант лучше? Экономия на строках? Хотите, отсыплю лишних?
Касаемо примера Go. ErrPermissionDenied является типизированной ошибкой, судя по всему эта функция вызывается где-то в хэнделере. По правильному было бы сделать проверку типа на вызывающей стороне и обработка ошибки ErrPermissionDenied с возвратом 403 кода.
Это не питон. Это "ложно понятый питоновский стиль". Я бы за такое отрубал мизинец (за первый раз).
на самом деле list comprehension действительно в ряде случаев (и даже, пожалуй, часто) работает быстрее. Например .append() по разу в цикл ни разу для скорости не полезен. Другое дело что к самой статье это криво ложится, потому что по логике статьи, если бы какой поборник читабельости посоветовал наоборот развернуть это до красивой лесенки, персонаж должен был бы развернуть, ухудшив себе производительность, лишь бы разговоры не разговаривать.
Извините, среди множества бессмысленных ритуалов - код-ревью это один из самых идиотских и вредных.
Это как запирать конюшню после того как лошадей уже украли.
Нужен единый code style? Договоритесь всей командой, зафиксируйте style agreement, настройте линтер. Все! Никаких больше мелочных придирок к коду на ревью.
Нужно соблюдение архитектурного подхода? Разберите задачу заранее, обозначьте как именно она должна быть решена, зафиксируйте решение с разработчиком. Все, никаких больше "тут надо половину коммита переделать" на ревью.
Нужно учить джуна/миддла? Садись рядом с ним и помогай в процессе решения. Все, никаких больше лекций со ссылками на википедию в комментах к MR.
Все задачи, которые по мнению "эффективных менеджеров" должны решаться на ревью - внезапным образом эффективно решаются не на ревью, и при этом на ревью совсем не решаются, или, в лучшем случае, решаются плохо и с ненужными конфликтами.
А все потому, что обычно в рабочем процессе код-ревью - это слишком поздний этап работы над кодом.
Код-ревью задумано скорее для поиска ошибок по коду. Но вы же знаете айтишников, когда у них много гонора и свободного времени на работе, то начинают друг перед другом выделываться "а вот тут я бы написал не так". В каких-то компаниях это и вовсе чистая бюрократия, никто даже код не читает, так как просто смысла нет, когда ты знаешь по задаче меньше, чем тот человек, который с ней разбирался неделю.
Для поиска ошибок служит тестирование.
Код-ревью не предназначен для поиска именно ошибок.
Стив Макконел в книге совершенный код приводил такую статистику:
Software testing alone has limited effectiveness — the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent.
Одно лишь тестирование программного обеспечения имеет ограниченную эффективность: средний уровень обнаружения дефектов составляет всего 25% для модульного тестирования, 35% для функционального и 45% для интеграционного тестирования. В то же время, средняя эффективность проверок дизайна и кода составляет 55 и 60%.
По ощущению, бьётся с реальностью?
Непонятно откуда взята эта статистика.
Но дело даже не в этом. По статистике, некоторое количество водителей попадает пьяными в аварию. Означает ли это, что если ты не пьешь, то в аварию не попадешь?
Грубо говоря, если ты качественно делаешь те вещи, о которых я писал в изначальном посте - то есть, используешь тестирование для поиска ошибок (вместо поиска ошибок глазами на ревью, методом интерпретации кода в уме), и делаешь предварительную проработку задачи на постановке (вместо расшифровки постановкт по коду, опять-таки в уме) - то ревью только заберет у тебя время, и ничего не добавит к качеству решения.
Ну и, поскольку я именно так и делаю, то моя личная статистика не бьется с цифрами Стива. Но это, как я отметил выше, вообще ни о чем не говорит.
Бьётся)
код-ревью это один из самых
нужных и полезных инструментов.
Пусть у вас в команде все супер профи, все равно люди могут иногда ошибиться, иногда не так понять что написано в постановке, а то и вовсе сделать лучше чем было запланировано.
Код ревью выявляет всё это на ранних этапах. Плюс бонус — команда хотя бы поверхностно в курсе что где и как в проекте.
А кодстайл с ревью связан очень опосредованно, не на это нужно смотреть.
На каких ранних этапах? Код-ревью выполняется как правило уже на этапе MR. Это самый поздний, а не самый ранний этап работы с кодом.
Каким образом "команда в курсе что и как в проекте"? Простите, но в любом более-менее крупном проекте не то что ревьюеры - сами авторы кода через несколько месяцев не вспомнят что и где. Для понимания "что и где" - служит архитектура и документация, а не код-ревью.
Обсуждать постановку на код-ревью? Серьезно? Вместо того, чтобы разъяснить все вопросы еще до начала работы над кодом - мы будем ими заниматься на ревью?
Вот это именно то, о чем я говорю. Код-ревью многими воспринимается как некий волшебный способ решения ряда задач. А на самом деле - для каждой из этих задач код-ревью не является эффективным способом решения.
В целом, классический код-ревью (уже на MR) - это совершенно лишенный смысла ритуал, создающий ИЛЛЮЗИЮ контроля.
Я б сказал, тут причина с следствием перевернуты. Именно потому, что зачастую стайлинг и статический анализ не затянуты тулингом, а процессы дают волю двойным трактовкам, ревью и превращается в тот самый "идиотский" ритуал, вызывающий фрустрацию, где ревьюеры косплеят стайлчекеры и играют в пинг-понг ремарок с оригинатором.
Если процесс налажен, ревью становится просто последним барьером на пути в апстрим, где ревьюеру остается проверить лишь одну вещь. Вещь, которую пока что не покрывает тулинг - человеческий фактор. Адекватность RCA - если MR это багфикс. Понятность комментов к коду, качество абстракций, читаемость имен литералов. Как правило, такое ревью длится недолго, а ремарки если и есть, то по существу.
Проверить качество абстракций? Простите, но лично мне, чтобы оценить качество абстракций, нужно поднять постановку задачи, вчитаться, сформулировать свое решение, далее из кода восстановить решение коллеги, и сравнить эти два решения.
Это если говорить о действительно качественном анализе абстракций, а не о профанации. Как такое ревью может длиться недолго? Разве что задача была типовой и элементарной, но зачем для такой задачи вообще нужно ревью?
Если есть сомнения в качестве проектирования - абстракций, архитектуры, внутренних API, структуры БД, etc - нужно включаться в задачу на этапе обсуждения постановки, и там контролировать ход мысли коллег. Не тогда, когда архитектура спроектирована, API созданы, структура данных зафиксирована, написан код работающий во всем этим... Что, это действительно, по Вашему мнению, самый подходящий момент чтобы начинать дискуссию по этим вопросам?
Тут щас надо садиться, и долго дискутировать, холиварить и сопоставлять: что каждый из нас подразумевает под "проверкой качества абстракций". Скорее всего мы подразумеваем кардинально разное, так как я не согласен что такое ревью не может длиться недолго. Может, и длится, и не требует скрупулезного погружения со старта. Смотря как процесс поставлен.
Оставим за скобкой "качество абстракций" - это несущественные детали. Основное что я хотел донести: ревью это просто еще одна ступенька в quality pipelinе. И фрустрирует эта ступенька, обычно, тогда, когда она в этом pipelinе - единственная. Когда нет ни тестов, ни линтеров, ни статических анализаторов, которые "краснили" и блочили бы мерж МРа в случае нарушений. Доверия такое решение, разумеется, не вызывает, и вот тогда - по совести - начинается история с "длительным скрупулезным погружением". И разумеется, такое ревью стопорит разработку на корню лавиной всякой херни и демагогии в комментах, зачастую со срачами и холиварами. По совести - не получается, из-за чего под давлением сроков и "эффективных манагеров" ревью вырождается в эрзац, ревью ради галочки. Вот и все.
Когда ревью проходит через настроенный тулинг, ревьюверу больше нет нужды тратить время на проверку как минмум стайлинга и следования проектным гайдлайнам. Время на ревью тратится меньше, ремарок по МРу муссирует меньше, раундов ревью до аппрува - меньше.
И не то чтобы для меня свет клином на ревью сошелся. Идея полного отказа от код ревью - вообще не нова. Есть extreme-подходы к разработке, типа trunk based девелопмента. Ревью в таких методологиях обычно со старта просто замещается парной разработкой - как вы выше и описываете: "Садись рядом с коллегой и помогай в процессе решения". Но это другая история.
Я, кстати, обожаю парную разработку. Но в реальности практически все мои коллеги от этой практики не были в восторге. Будучи руководителем, я мог бы и заставить. Но, конечно, не стал этого делать, а вместо этого годами занимался пропагандой. Без особых успехов :)
А удаленка похоронила это дело окончательно.
В целом, я думаю, что мы друг друга уже немного лучше поняли. Ревью часто рассматривается как универсальное решение для задач, которые на самом деле намного эффективнее решаются другими методами. Если эти методы задействованы - ревью избыточно. Если не задействованы - то ревью либо становится дорогим и тяжелым процессом (если делать его добросовестно), либо вырождается в лучшем случае в профанацию, в худшем - в арену состязания амбиций.
И вот кто-то в ревью спорит: «А может быть, стоит вернуть HTTP ошибку 403 вместо ErrPermissionDenied?»
опытный просто перепишет так
iferr := authorize(r.User, "execute"); err != nil {returnnil, NewHTTPError(403, "forbidden") }
А потом второй опытный перепишет
if err := authorize(r.User, "execute"); err != nil {
return nil, ErrPermissionDenied
}
И что дальше?
Такое поведение банально вредно и в нормальных коллективах запрещено.
Можешь предложить конкретный код? Ок, приводи его в комментариях или создавай PR, заодно и продемонстрируешь, что тесты проходят.
Но push без одобрения ревьюверов недопустим по ряду причин, от банального неуважения к мнению коллег ("мне пофиг что ты там выскажешь, я уже запушил") до снижения качества кода где точкой отказа становится 1 человек.
Да, в редких случаях код не требует согласования, но тогда и код-ревью не производится.
Самые бессмысленные коменты в ревью - это "а я написал бы так: ..." - и дальше следует переписываение 4 строчек в 3 или вынесение 5 строчек ва отдельную функцию или еще какая-то мелочь, которая не меняет ни логику работы ни производительность кода. С таким человеком надо серьезно поговорить и при отсутствии результата наложить административные санкции на его ревью.
Пример в статье с отправкой 403 ошибки немного странный, потому что надо было изначально на берегу договориться про обработку ошибок, используются HTTP коды или нет, будете вы выдавать напрямую ошибки с HTTP кодами либо же будете выдавать доменные ошибки, которые будут мапиться в HTTPшные где-то в общем месте.
На мой взгляд ревью невероятно дорого, оно настолько дорогое, что даже мало кто себе представляет реальную его цену. И вот почему:
Само по себе время на просмотр и изучение кода ревьюверами
Затраты на переделку коммита автором МРа - нужно переключиться в тот бранч, переделать код, прогнать тесты локально, при этом часто приходится заново перепроверять и отлаживать всё, так как просят поменять основную часть. Затем всё запушить, дождаться прохождения пайплайна, ответить комментаторам.
Затраты времени на синхронизацию: от момента отправки ревью (когда в целом код был протестирован автором, отлажен и в целом готов к тестированию) это +1 день на ревью + 1 день на исправление + 1 день на повторное ревью. Итого любая задача делается минимум за три дня.
Совершенно недооцененные затраты на прерывание "состояния потока" у автора кода. Все мы помним, как легко и быстро пишется код в пет-проектах, как интересно ими заниматься и как много можно сделать за 2 часа после работы и за 8 часов в выходные. Только почему-то за 40 часов рабочей недели получается сделать в разы меньше.
Конечно ревью приносит пользу, находят серьезные недостатки в коде, баги, которые могли бы попасть на прод. Но кроме пользы оно также приносит невероятный вред в виде несделанной работы из-за колоссальных затрат времени.
приносит невероятный вред в виде несделанной работы из-за колоссальных затрат времени.
У меня на прошлой работе отдельные персонажи постоянно издевались на ревью над новенькими работниками, что нужно поле в БД назвать не масло_масляное, а масляное_масло. Представляете, сколько нужно откатить на dev-БД, если там уже все сделано и целая пачка скриптов залита в репозиторий, где данные, таблицы, процедуры, там на полдня работы может случиться. Айтишники теми еще гандонами бывают.
Естественно, что когда ты уже не новенький, то просто им фак показываешь и идешь жаловаться тимлиду.
У меня на прошлой работе отдельные персонажи постоянно издевались на ревью над новенькими работниками, что нужно поле в БД назвать не масло_масляное, а масляное_масло. Представляете, сколько нужно откатить на dev-БД, если там уже все сделано
Ну, если все остальные колонки называются водяная_вода, хлебный_хлеб и тп, то он ССЗБ
Там тысячи таких колонок и подобное не описано регламентом наименований. Это просто унизительная процедура и ничего более.
Если тысячи колонок называются в стиле водяная_вода, какой еще регламент нужен?
Вы из этих самых, кто на ревью лучше всех знает, как правильно называть поля?
А вы из тех кто называет все поля field_1, field_2 и "все ж работает, что вы издеваетесь?"?
Ну, камон, отсутствие спеки по неймингу - это плохо, но мы используем дорогое ревью именно для того, чтобы потом не тратить дни на попытки разобраться, какое из полей wet_water или water_wetting использовать, и почему первое булево, а во втором число.
Есть две самые сложные вещи в программировании: инвалидация кэша, отладка и именование переменных
2 и 4 пункты несколько преувеличины.
Вас никто не выдергивает из потока и не просит бежать роняя кал править замечания. Когда удобно, тогда заходите и смотрите замечания (в разумных пределах конечно). И тут мы переходим к п2 — править код придется только если замечания по существу и обоснованы. Если кто-то зашел просто поглумиться, можно послать его нах.
Про второй пункт - не важно, в какое время я это буду делать это всё равно займет много времени. Нужно еще раз вернуться к этому коду, что-то дописать, отладить, протестировать и.т.д. Если это нужно чтобы исправить какую-то реальную проблему - то ОК, но в половине случаем просто просят сделать чуть лучше, но в реальности это ни на что в итоге не влияет. При этом в проекте всегда есть гораздо более важные задачи и проблемы, мы этими улучшениями и полировками до блеска отнимаем время от решения реальных проблем.
Про четвертый пункт - люди есть разные. Кому-то без разницы в каком порядке есть первое, второе салат и пить компот, но мне лично очень тяжело переключаться.
Ну и вот этот выбор - замечание по существу или не по существу - это же не выбор между черным и белым. Обычно всё-таки что-то среднее и стоит ли оно того, чтобы потратить на это 2-3 часа рабочего времени - большой вопрос.
Можно добавить, что ревью очень дорогое не только для автора кода, но и для ревьюера. Если, конечно, делать полноценный аудит, а не бегло пробежаться по комментариям и названиям переменных.
Одно дело, когда коммитится багфикс в две строчки (отдельный вопрос зачем там ревью).
Но, например, один из моих недавних MR состоял из десятка новых таблиц в БД и набора новых классов логики. Реализация принципиально новой подсистемы в составе крупного продукта.
Быстренько провести ревью на MR? Удачи.
Одно дело, когда коммитится багфикс в две строчки (отдельный вопрос зачем там ревью).
Обычно после таких багфиксов прод и ложится :)
состоял из десятка новых таблиц в БД и набора новых классов логики
Тут, действительно, понадобится выделить отдельное время. Стараюсь до такого не доводить. Если задачи большая, то создают ветку в которую через ревью мержу этапы работы.
Для рецензента этот процесс вообще крайне невыгоден: вы выбиваетесь из потока, читать код сложнее, чем писать, потом никто ваши труды по рецензированию не вспомнит.
Одно дело, когда коммитится багфикс в две строчки (отдельный вопрос зачем там ревью).
Чтобы в горячке не внести ещё один. Такое бывает неоднократно.
Старая поговорка: там, где два senior разработчика, там три мнения.
Кто ревьювит матерого опытного разработчика? Еще более матерый и опытный? Мне одному кажется, что описанная в статье проблема (которую, как подозревают, писал АИ), собственно, вскрывает порочность и бессмысленность системы ревью?
там где пришлось работать у кода всегда был хозяин - project leader, check in только с его согласия, обычно после ревью, без разницы опытный программист или нет, second opinion всегда полезно, тех кто считает написанный код личной собственностью лучше сразу на выход, типа это не профессионально, как и любое неоправданное усложнение кода
Обсуждение это способ взглянуть под разными углами. Если комментирующий дело говорит, то чего спорить? Исправили модель, посмотрели поведение, пошли дальше.
По моему, это зависит от типа мышления: системное, которое строит модели и смотрит их поведение и прикладное, которое реагирует на раздражитель.
Вместо коммита можно внести suggestion - точно знаю, что в GitLab и GitHub есть такая опция при ревью. Это когда вы сразу предлагаете способ переписать, но еще не коммитите в ветку, и автор MR/PR может его апрувнуть - и применить как полноценный коммит. Отличная штука, и можно также к своему suggestion добавить пояснения, если они еще требуются, или продолжить дискуссию.
Обсуждение имеет смысл, когда у тебя есть вопросы. Если вопросов нет – просто делаешь, как надо.
А если опытному программисту ревьюер в окно прыгнуть скажет, то он тоже прыгнет без лишних споров? Ревьюер тоже человек, и может ошибаться.
Да. Если заказчик хочет какой-то бред, и этот бред ничего принципиально не портит, тогда быстрее сделать, чем вступать в споры
Я вот из тех кто особо не спорит, ну если только дичь не предлагают.
Ибо считаю что нет абсолюта а среди сеньоров есть вкусовщина. Вот примеры за последний год (python)
1) на одном проекте тимлид требовал везде одинарные кавычки. Пришел на другой проект, после пары замечаний от нового тимлида, что нужно ставить везде двойные кавычки. Спросил почему? Тот ответил - одинарные кавычки устарели вместе с питоном2, и с тех пор все пишут на двойных.
Стоит ли мне спорить с такими тимлидами? При этом в пеп говорится о том что можно и те и те как принимают в команде. В обоих командах не было стайлгайда.
2) еще на одном проекте тим лид из соседней команды когда наш был в отпуске и замешал его начал всем в комментах писать заменять в типизации Dict на dict (тогда как раз вышл новый пидантик). И причем о важности этого спорил на каждом митапе. Стайлгайда тоже не было.
Стоит ли тратить на него время? Или проще поменять.
3) по молодости пришёл на один проект и там был styleguide. В нем было написано что на проекте мы используем pytest. Выполнил первое тз, написал тесты. Прилетает жёсткий ревью от тимлида - "зачем pytest? Используй всегда unittest"
... Могу до бесконечности вспоминать, проще молча поменять.
Я не знаю, как в питоне, а в Ruby текст в одинарных кавычках не может содержать внутри интерполяцию, и поэтому если в закавыченном тексте интерполяции нет, то нет и смысла пихать его в другой обработчик, если тот гарантированно не сработает.
В любом случае - это прекрасный повод завести код стайл :) Прийти и задушнить всех.
А потом стать тимлидом и выдвигать свои требования.
мы внедрили правило: ревью должно завершаться
Неплохое правило!
Это правило применимо во всех сферах. Твоё дело писать код. Ты должен его писать, когда стоит такая задача. Даже если тебе кажется, что можно его не писать, ты должен просто взять и написать. А оспаривать должен тот, кто потом несёт ответственность за новое решение.
Если твоя работа - рыть землю, то ты не должен думать о том, где лучше рыть, и где лучше не рыть. Просто моча рой землю. Это твоя работа, на которую ты нанят.
Если твоя работа - рыть землю, то ты не должен думать о том, где лучше рыть, и где лучше не рыть. Просто моча рой землю. Это твоя работа, на которую ты нанят.
Если твоя работа — строить мосты, то ты не должен думать о том, где лучше строить, и где лучше не строить. Просто молча строй мост. Это твоя работа, на которую ты нанят. Построишь — вместе поржём.
Можно то...
Надо так..
А вот если ...
И в ответ короткое НЕТ. И все, и тишина, ни споров ни обсуждений ....
После первого абзаца текста сразу 2 вопроса. К автору и модерации - Серьезно? Публиковать на хабре нефильтрованное нейрохрючево вот так в наглую?
Второй вопрос комментаторам, которые неиронично отвечают на пост. Вы правда не замечаете чем вас кормят или вам с этим ок?
Из одного предложения раздули статью. За что плюсы?
«моё решение лучше»
Для кого лучше?
Все эти правила нужны чтобы совместить работу нескольких программистов, чтобы код мог развиваться и сопровождаться, чтобы код был читаем и на ревью можно было ошибки найти.
И внутри репозитория появляется sendHTTPError, и все автоматом подстраиваются. Конец дискуссии
Ага, классно. То есть зависимость протекала уже не через один слой, а через два. Такое гниение кодовой базы быстро распространяется. Команда копирует паттерн, HTTP логика везде.
Цепная реакция:
Handler - Repository - Database layer
HTTP коды просачиваются через все слои
Всё связано с транспортным протоколом
Второй вариант
Оставить возврат 403, текст
Но текст должен быть доменный
Не
err.Error() = "Forbidden" // это HTTP-термин
err.Error() = "Bad Request" // это протоколА
ErrInsufficientFunds // "недостаточно средств на счете"
ErrOrderExpired // "заказ истек 3 дня назад"
Я пишу сейчас код с помощью ии в основном. И заметил, что ии ведет себя порой точно также. Кидаешь ему очередной промт и он без лишних вопросов сразу вылает три варианта кода, указывая, какой на его взгляд лучше. Короче, не спорит, а просто генерит код. Иногда бесстолково, но в любом случае, это подспорье хорошее, я сам рпзберусь что мне лучше выбрать. Написание кода с ии ускорилось в разы.
Помню ожесточенный спор с коллегой, когда его изначальное решение мне не нравилось, т.к. функция могла молча оставить объект в невалидном состоянии. Мое предложенное решение не понравилось ему, т.к. я создавал guard объект, бросающий исключение из деструктора. В конце концов мы смогли найти вариант, устраивающий нас обоих. И вот я готов мержить изменения, но... обнаруживается конфликт. Оказывается, во время нашего спора наш общий менеджер (даже выше, менеджер менеджера) создал свой PR и, никого из нас не добавив в ревьюеры, молча слил на мастер то самое говнище, которое не устраивало нас обоих. Это при том, что никакого цейтнота не было.
Этот же менеджер всячески игнорирует любые попытки создать хоть какое-то владение кодом: в идеале коллективное, но вначале индивидуальное. В итоге код напоминает общественный писсуар. Эта рыба давно прогнила с головы. А споры в ревью -- это необходимость. И они же порождают владение кодом.
У нас правило такое: у того, кто поломал, есть два варианта на выбор: либо починить самому, либо дать починить кому-то ещё, но тогда без выйоживаний выслушивать от него всё, что тот имеет, глядь, сказать.
я создавал guard объект, бросающий исключение из деструктора
Речь о коде на каком языке программирования?
«То, что вообще может быть сказано, должно быть сказано ясно».
«О том, что сказать невозможно, следует молчать».
Людвиг Витгенштейн
"Лингвистический поворот" случился не на пустом месте.
Эта статья — безусловный победитель в номинации "Холиварная статья на Хабре 2025 года". Уровень субъективности, выданной за универсальную "зрелость" и "рациональность", просто пробил потолок. И да, автор прав: с такими, как он, спорить действительно бесполезно. Надо просто выполнить "commit, push" и протереть пыль с резюме, потому что работать в такой команде - сомнительное удовольствие. Поэтому я обращаюсь не к автору, это очевидно бесполезно, а к тем, кто прочитает его "философию тишины". Философия автора не имеет ничего общего со зрелостью. Это скорее набор правил для токсичной, авторитарной среды, где статус важнее идеи. Прощай, Менторство. Он фактически заявляет: "Если новичок что-то сделал не так, я исправлю это молча. Пусть сам догадывается, почему моё решение лучше, мне лень объяснять". Он максимально эффективно устранили обучение и рост в своей команде. Настоящая зрелость - это способность быстро и уважительно объяснить причину изменения, а не просто демонстрировать "превосходство" через коммит.
Автор поставил под сомнение парное программирование, архитектурное мышление. Он превращает разработчика в писаря, а не автора.
Путь к архитектурному мышлению лежит через дискуссии, через защиту своих решений и критику чужих. Модель автора низводит разработчика до "болтика", которому запрещено думать о контексте и предлагать альтернативы. Если он никогда не "спорит" о границах и шаблонах, он никогда не станет архитектором. А тут как в армии плох тот солдат, который не мечтает стать генералом. Так же и тут плох тот разработчик кто не мечтает стать архитекторам. Это пожалуй самая важная вещь в программировании. Каждый программист архитектор в контексте своего решения, будь это метод, или класс, или пакет. Если разработчик не спорит, а просто делает как надо он не программист, он писарь. Как птица-секретарь. Иерархия, а не Коллаборация. Автор гордится тем, что "старшие правят, младшие спрашивают". Это чистый взгляд сверху вниз. А что, если Junior нашел более эффективное решение или ошибку в "идеальном" коде старшего? Его "рациональность" предписывает ему молчать и принять решение стершего, основанное на статусе, а не на лучшем аргументе. И главное в программировании старший или senior - это весьма относительное понятие. Старший где? В этой команде? В этом, конкретно, приложении? В мире? Старший по выслуге лет? Или старший потому что его код повысил прибыль проекта в N - раз? Что вообще следует понимать под словом "старший"?
Подводя итог: Если единственная эффективная коммуникация в команде автора это молчаливое принятие чужих коммитов, то это не "зрелость". Это сигнал о том, что коллектив работает на выгорание, где "спор" заменен страхом и авторитаризмом. Продолжай кодить, а не спорить.
Вообще у меня сложилось ощущение, что автор работает не среди плохих или сильных разработчиков. Он работает в плохо выстроенной команде. И вопросы тут не в том кто такие программисты, а кто там в менеджерах.
И вот о статусе, кстати. Опять живой пример. Прямо сейчас я проходил процессинг по найму в одну команду. Первый день, что-то напутали, я вышел в одного числа, а вроде как команда ожидала другое число. Да, такое бывает. В итоге мне не дали доступы. Сказали отправляться домой и ждать. Я поехал, но предварительно уточнил на счет задачи которая у меня будет на испытательном сроке (они практикуют на испытательном сроке давать реальную бизнес-задачу и по итогам её выполнения оценивать твой скил). Я мог не уточнять о задаче, мне никто не предложил её обсудить. Но я сам проявил инициативу и уточнил. Более того, оценив задачу, я понял что большую её часть можно сделать вообще в отрыве от их инфраструктуры. Сделать её в своем контексте. DDD на практике, так сказать. Итог: конец первого рабочего дня, у меня уже полностью готова бэкнд часть задачи изолировано. Получив доступы я реализовал пару описательных классов-адаптеров и интегрировал бесшовно в их приложение свое решение за час. А доступы я ждал почти 3 дня. То есть по сути я могу тупо ждать 3 дня. Но я пошел иным путем. И конечно, разработчиков моё решение ввело в ступор. Даже опытных, которые там более 6 лет работают. Но обсуждая решение, я аргументировал это тем, что цель состояла не в демонстрации того как я могу "красиво" написать независимый код. Это решение было продиктовано условиями в которых я оказался. Я сэкономил бизнесу деньги и время, вопреки их бюрократическим провалам. Junior на моем месте скорее всего бы тупо ждал, Meaddle вероятно ознакомившись с задачей, а Senior написал решение как сделал я. Но вопрос даже не в подходе к реализации. А в том: а каждый бы Senior проявил инициативу и спросил о деталях задачи в первой рабочий день, несмотря на то, что привычный flow процесса онбординга нарушен? Думаю что нет. А это и есть настоящая зрелость разработчика. А не "режим тишины" и молчаливые "комиты". Зрелость - это не выбор между разговором и действием, это синтез их обоих. Зрелый разработчик не является пассивным участником плохого процесса, а активно его исправляет/обходит во благо бизнеса. Я с автором согласен в одном. Спорить в комментариях - бесполезно. И в этом он прав, просто говорит об этом как то странно. Если ты молча написал код, сделал коммит, тебя начинают критиковать в комментариях - я бы тоже не спорил, а переписал. Но не потому, что я опытный и зрелый разработчик. Я бы не такое заключение сделал. Я бы сделал заключение, что я тупой. Потому что зрелый и опытный, сперва предлагает, спорит, обсуждает, рождает истину, а уже потом появляется коммт с готовым решением.
Был у нас один разработчик, который просто говорил, что не будет это делать, потому что это фигня
«А если подумать, то и пчОлы тоже фигня...» ©
Почему опытные программисты всё чаще молча переписывают, чем спорят в комментариях