LINUX.ORG.RU

Нужны ваши мысли по code review

 ,


2

3

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

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

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

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

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

★★★
Ответ на: комментарий от alex0x08

Во-вторых оно порождает немеряное количество правок и diff получается чудовищных размеров.

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

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

Во-первых, это происходит нечасто

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

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

Допустим для ревью действительно можно такое пропустить, но в коммите же оно все равно будет. Вообщем идея не очень, есть риск что-то упустить.

Ах да, ты же в курсе существования такого замечательного языка как Python, где границы блока отмечаются количеством пробелов? Понимаешь чем может закончиться игнор «невидимых символов» в этом случае?

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

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

Никаких приветов если хуки настроены.

Вообщем идея не очень, есть риск что-то упустить.

Нету никакого, если голова у настройщиков CI не только чтобы есть.

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

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

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

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

Никаких прмветов если хуки настроены.

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

Нету никакого, если голова у настройщиков CI не только чтобы есть.

Причем тут CI? Хуки же на git-сервере настраиваются для запуска перед приемом коммита?

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

Хук это к сожалению просто скрипт, который может выполниться а может и нет. 

Паранойя щас лечится :) воспроизводимыми билдами например

Причем тут CI? Хуки же на git-сервере настраиваются для запуска перед приемом коммита?

Потому что git-сервер часть пайплайна и чтоб туда что-то попало, надо выполнить некоторые условия, а не форспушить в мастер всем подряд :)

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

Потому что git-сервер часть пайплайна и чтоб туда что-то попало, надо выполнить некоторые условия, а не форспушить в мастер всем подряд :)

Не очень понял о чем речь, можешь раскрыть тему?

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

Форспуш в мастер запрещен. Мастер, например, закрыт на мерж до ободрямса N доверенеными ревьюэрами и коде-овнером еще — либо туда мержит вообще только коде-овнер («схема с диктатором»). Фильтров такого плана плюс-минус достатрочно для исключения патчей от хаоситов. Детектирование ахинеи в пуллреквестах типа массовых замен тоже вполне поддается автоматизации, о чем кому надо приходят уведомления. Неодобренный пуллреквест вообще никуда не пойдет, не то что на сервер. А хуки всем придется у себя выполнять просто чтоб пуллреквест приняли на ревью ;) причем это все давно кэп.

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

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

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

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

а не замахнуться ли вам на вильЯма нашего шекспира понимаишь, и не копнуть ли в сторону нейросетей тут?

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

Откровенно говоря code review это не про критику как таковую а про соблюдение стандартов проекта и адекватность логики реализации.

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

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

а не замахнуться ли вам на вильЯма нашего шекспира понимаишь, и не копнуть ли в сторону нейросетей тут?

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

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

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

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

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

Syncro ★★★★★
()

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

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

Говорю же: времени и сил на такое просто нет.

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

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

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

если нет времени сделать нормально, то наверное не стоит браться выполнять эту задачу(ревью), иначе получается создание проблем вместо решения, замечания ревьюера у которого «нет времени» могут быть не понятны, не приемлемы, не уместны и т.д., вобщем, это опасная модель сильно напоминающая банальный job security паразитизм

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

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

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

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

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

Поэтому ситуация, когда со стороны ревьюера требуется «своя реализация» в коде мне кажется малореальной.

Написать что и где в коде не так это одно, выдать полностью свою реализацию - нет.

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

Чет я видимо слишком давно на свете живу чтобы верить вот в такое

Я дольше, и мир не перестаёт меня удивлять. Как и люди. :)

Есть какая-то практика использования?

А то!

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

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

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

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

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

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

Что тут сложного? Подготовить входные данные, то есть пометить их смыслом это долго, муторно и дорого, что малому предприятию не по плечу. Не стоит надувать щеки, рассуждая о какой-то там сложности нейросетей. Все просто, если численные методы учить в ВУЗе хотя бы на «удовлетворительно».

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

Все просто, если численные методы учить в ВУЗе хотя бы на «удовлетворительно».

Ну да, все научные работы и результаты «открыты». Теоретическая БАЗА есть. Даже патенты изучить можно.
Вот только повторить какое-то конкретное прикладное устройство/технологию задолбаешься.

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

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

Чтобы ответить на твой вопрос прямо - большинство Российских ВУЗов и лабораторий до начала санкций кормились на гранты, предоставляемые псевдонаучными зарубежными организациями, расчитанными на то, чтобы получить подготовленные данные по определённым областям (чем там занимался ВУЗ).

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

На самом деле он прав

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

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

Прекрасно, а где можно ознакомиться с вашими работами по нейросетям?

Я разве похож на «учёного» дурачка, выкладывающего свои изобретения на всеобщее обозрение ради общественного признания? Печатание в американских научных журналов ради какой-то там научной оценки работы сообществом это же всего лишь занавеска для того, чтобы американцам даром получать изобретения со всего мира. Сейчас, вроде бы, уже запретили печататься «учёным» из России, что является только благом для общества ибо признанный в США учёный рано или поздно уедет туда, где его оценили и признали. А родина потратила денежки на исследования этого «бегунка» и бесплатно раздала его труды. Папуасов так и нужно грабить, если ума нет.

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

Ну да, все научные работы и результаты «открыты». Теоретическая БАЗА есть. Даже патенты изучить можно. Вот только повторить какое-то конкретное прикладное устройство/технологию задолбаешься.

Качаешь «Матлаб» с торрентов. Устанавливаешь. Смотришь примеры по нейросетям. Генерируешь исходные тексты модели на Си. Вникаешь в исходный код. Тогда придёт понимание. Все эти Питоны с библиотеками - игрушка для бездельников из университетов. Настоящие технологии двигает американский ВПК, для которого «Матлаб» и создавался, чтобы моделировать и обсчитывать работу устройств повышенной надёжности.

На мой взгляд, отрабатывать работу нейросетей на видеокартах это тупик, потому что данные необходимо пробрасывать из сети/диска через оперативку и процессор в саму видеокарту, там считать и выдавать результат обратно в ОЗУ, диск/сеть. Гораздо эффективнее создать свою микросхему, которая будет содержать в себе сетевой приёмо-передатчик и множество умножителей со сложителями. Быстросчитаемо, надёжно и энергоэффективно.

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

А что насчет участия в открытых проектах или своих разработок? Или это слишком низко для такого гения?

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

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

Вообще смысл очень простой: получить практический опыт в обсуждаемой сфере и наконец перестать нести чушь.

Но не удивлен нет, теоретиком быть куда проще.

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