Ну, хоть примерно. Любых. Сколько лично у вас получается каких-нибудь?
---
Конкретно сейчас переписываю T-SQL на PL/pgSQL. Хоть убейся больше 2000 в день не получается. Это около половины процедуры в день. Начальство нервничает, мол очень медленно.
За non-functional / cosmetic changes в приличных заведениях больно бьют по рукам канделябром.
Сколько в день строк может быть отработано?
Да разные патчи бывают - и крошечные one-liners, и «монстры» в несколько тысяч строк. На большой патч трогающий критичные куски кода и день запросто убить можно. Не числом строк как таковым всё меряется, а сложностью. Вопрос то в чём?
2к строк в день - это вообще-то охренеть как много. Если начальство нервничает и просит больше, то да, отказывайся от этой работы, и пусть оно само ей занимается.
Да нет конечно - это довольно большое изменение, особенно если это что-то spaghetti-style.
Может отказаться от этой работы, не справляюсь действительно?
Мне кажется - вопрос ставится неправильно: если напрягает то наверное имеет смысл «посмотреть по сторонам», но как совсем можно самоустаниться от review - мне не очень понятно. Главное выдержать разумный баланс и не превращать каждый день в «каторгу» - так долго не протянуть.
У нас code review не предполагает внесение изменений ревьювером - только замечания. В зависимости от сложности проекта и 100 строчек может быть очень долгим для ревью.
когда надо быстро, это значит, что ты должен наделать ошибок и потом быть виноватым, платить и каяться и т.п. Впрочем, кажется так не бывает чтобы не надо было быстро.
Если с правкой, форматированием, переписыванием отдельных кусков…
Ты видать рефакторинг с кодревью путаешь. И да. Обычно кодревью – это на какой-то пул/мерж-реквест делается. Т.е. что там целый день читать ХЗ. Разве что процесс криво поставлен и кто-то делает огромные пул-реквесты.
За non-functional / cosmetic changes в приличных заведениях больно бьют по рукам канделябром
За cosmetic да, ибо есть стайлгайд, а за non-functional нет, ибо бывают места что всех бесят, но никто не хочет например менять захардкоженные значения в декларативный массив. А потом находится герой, что мимо проходил
Ревью кода - дело понятное, благое и к применению обязательное. А что такое «вычитка кода»? А при чем тут правки и форматирование? Вы серьёзно, лезете с правками в чужие пулл-реквесты? Вас за это надо палкой бить по пяткам. Если это требование к вашей позиции со стороны работодателя, бегите от этих идиотов. Если вы сами это придумали, вы плохо придумали, код-ревью не так работает.
У меня сложилось впечатление, что ТС путает code-review и рефакторинг. А по описанию, так и не рефакторинг даже, а rewriting с одного языка(БД) на другой.
Ничего не знаю про переписывание sql. У нас длительность ревью обычно зависит от сложности, а не количества строк. Частенько бывают большие коммиты, но с однотипным или простым для понимания с одного взгляда содержанием, там особо не глядя можно аппрув ставить.
Никогда не занимался код ревью целый рабочий день, потому хз. На ревью большого мр в районе 1000 строк изменений уходит час где-то. Хотя могут быть исключения, когда почти весь мр это автогенеренные файлы DTOшек. А может быть эти 1000 строк это всё логика. Оговорюсь что код-ревью не замена всяким анализаторам кода и тестированию
с правкой, форматированием, переписыванием отдельных кусков…
Это что за ревью такое? На ревью ты просто пишешь замечания и отдаёшь обратно доделывать.
Форматирование вообще должно автоматически ревьюиться и исправляться.
Ну бывают, конечно, какие-то мелочи, которые можно сразу по-месту исправить самому. Но это когда исправить быстрее и проще, чем написать комментарий.
Сколько в день строк может быть отработано?
Как ты это делаешь, фактически выполняя работу за автора патча, можно и 300 строк в день едва осилить.
А так вообще, если проверять по формальным требованиям, и что автор не удаляет гланды через жопу, то можно и 10к в день сделать легко.
Просто для приблизительного понимания местной публикой.
Вы добились ровно противоположного - вас никто не понял. Да и как вас понять, если вы взяли всем хорошо знакомый термин и применили его к совсем другой штуке. Вам бы поработать пару годков в большой софтверной компании, ну чтобы в пободные ситуации не попадать.
ТС не то чтобы путает. ТС думал, что «code-review» больше похоже на то, чем занимаюсь сейчас.
«code-review» это когда вам джун(не обязательно) присылает код, а вы смотрите и говорите где в коде говно и отправляете его переделывать. А у тебя портирование кода на другой язык, хоть и похожий.
Да, виноват, я понял что неудачную аналогию пытался привести. Пардон. FishHook
Но тем не менее - вот «джун(не обязательно) присылает код, а вы смотрите и говорите» - 2000 строк просмотреть, осмыслить, что-то поправить - это действительно мало?
А есть возможность сравнить твою производительность с производительностью коллег? Т.е. берём какой-то набор метрик, например, количество строк кода в день усреднённые по неделе, количество регрессий выявленных в тестировании, количество времени потребовавшегося на устранение регрессий и сравниваем
Обычно всё же на ревью отдается тому кто в этом модуле что-то понимает. А проскроллить 2000 строк +- знакомого кода, это не так и долго. Ответственный за код всё же автор, ревьюер только как незамыленный второй взгляд(и возможно более опытный коллега).
что-то поправить
Этого делать не стоит, плохой тон, если что-то не так, сказать автору и пусть исправляет(или убедит, что его решение лучше).
The effectiveness of code review was found to depend on the review speed. Code review rates should be between 200 and 400 lines of code per hour.[19][20][21][22] Inspecting and reviewing more than a few hundred lines of code per hour for critical software (such as safety critical embedded software) may be too fast to find errors.[19][23]
Если еще и
с правкой, форматированием, переписыванием отдельных кусков…
Смотрел роботов. Те, кого видел - ошибаются, например, в переводе DATEDIFF на ПГ. И, естественно, не могут сделать правильное RETURNS TABLE(). И с хинтами по индексам затык. И т.д., и т.п.
А вручную, по буквам - что-то у нас с начальством совсем разные представления о сроках.
Да, виноват, я понял что неудачную аналогию пытался привести. Пардон. FishHook
Но тем не менее - вот «джун(не обязательно) присылает код, а вы смотрите и говорите» - 2000 строк просмотреть, осмыслить, что-то поправить - это действительно мало?
Давайте по пунктам:
Через ревью должен проходить весь(!!) код, не важно, кто его написал - джун или господь бог.
Ревью делается до(!!) мерджа бранчи, а не после
В ревью обычно участвует вся команда разработки включая джунов и практикантов, а не один какой-то дядя считающий себя суперумным
Ревью не ставит задачи отловить все баги и косяки. Для этого существует всеразличное тестирование. Ревью это просто свежий взгляд на ваш код со стороны ибо никто не безупречен. Одной из побочных, но важных задач ревью является ознакомление команды с тем, что вы собираетесь замерджить. Допустим, Вася запилил функцию А, которая будет полезна Пете в его модуле, Петя должен как-то об этом узнать. Или наоборот, Вася костылит функцию А, которую Петя в своей бранче сделал лучше и эффективнее, но этот код еще не в мастере. Петя с Васей должны обменяться кодом, чтобы не плодить сущности.
В ревью бывают разные уровни - блокирующие замечания и неблокирующие. Тот чей код ревьюируют сам решает, что делать с неблокирующими, может игнорировать или создать жиру для дальнейшего фикса.
Ревью делается на базе той или иной системы контроля версий. Ревьюится именно версия подлежащая вливанию в основную ветку кода.
От пяти до хрен знает сколько.
Очень сильно разнится, в зависимости от содержания. Оформление кода - это семечки. Гораздо больше времени занимает, если просто реализация не нравится, и всё надо по мнению ревьюера переписать. Или ищутся уязвимости или что-то типа аудита.
У меня похожая ситуация была на моей самой первой работе. Шарашка была небольшая: пару студентов/вчерашних студентов и начальство. Так начальство постоянно на мозги капало: все вы хорошо делаете, всем я доволен, но вот медленно. Деньги тоже жал, пор предлогом, что медленно. В силу отсутствия опыта, нам было не понятно, и вправду мы медленно гребем или он просто давит этим. Главное в этой истории то, что поработав, потом, уже на многих конторах я понял, что ни разу мы там медленно не работали. Достаточно хороший темп был. Как для юных специалистов, разумеется.
Эм, а какой идиот вам задает ревью кода НА СКОРОСТЬ? На вопрос «а почему так медленно?» отвечайте «а почему вы считаете что это медленно? Вы сам делали ревью? Использовали какие-то метрики? Вы специалист? Нет? А я консультировался с коллегами-специалистами, в том числе с системным архитектором и он сказал что без потери качества ревью в среднем ДО 1К строк в лучшем случае.». Начнет вертеть жопкой приглашайте его сюда, мы быстро рога обламаем.
Поддержу, 2000 для SQL это много. Если без изменений логики работы, а именно ревью портирования, я бы ориентировался на 500 строк в день (но сильно зависит от кода). Ну и, понятное дело, запуски помогут отловить блох, которых не заметил глаз.
Обычно продуктивность (читателя кода) составляет примерно 1000 строк в день.
это какие-то простыни с инициализацией массива на 5 страниц?
Нереально в день осмысленно прочитать 1000 строк кода, только если на позиции «ревьюер кода», но таких не бывает.
Такие разговоры надо начинать с того, что всю литературу по поводу норм в разработке ПО лучше игнорить из-за нерепрезентативности выборки, и имеет смысл только сравнивать конкретных разрабов.
Нереально в день осмысленно прочитать 1000 строк кода
как можно понять из разрозненных и слабо связанных друг с другом сообщений автора, там еще интереснее. Значит у них есть какой-то джуниор, который производит ежедневно 2000 строк скульных скриптов, а ТС их в режиме реального времени как бы ревьюит и тут же фиксит. И как-то так получается, что джун успевает наговнокодить 2к строк, а ТС (который очевидно не джун), не успевает это прочитать. И никто из участников процесса не видит тут каких-то противоречий.
Есть продукт на T-SQL, который разрабатывался примерно 30 лет. С десятками тысяч процедур, на тысячи строк каждая.
Начальство удивительным образом считает, что это всё можно переписать на ПГ за два месяца. И очень удивляется, что у меня выходит в лучшем случае одна процедура за два дня.