Ревью кода

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

энтузиасты занимаются review кода

Ну, они ж это добровольно делают. И как мне кажется, только для важных проектов. Будет ли интересен твой yet-another-плеер для ревью?

Будет ли интересен твой yet-another-плеер для ревью?

Боюсь что нет :(

можешь просто слать PR на гитхаб там почти всегда в более менее крупных проектах будет ревью изменений

Боюсь что уйдёт слишком много времени чтобы влиться в open-source проект.

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

В общем не уверен на сколько в рамках open-source удастся пописать совсем «базовые» штуки, т.к. они уже давно написаны.

https://codereview.stackexchange.com/

https://codereview.stackexchange.com/

Натыкался, но что-то не заметил чтобы там постили ссылки на github, но можно и там попробовать.

Спасибо в любом случае

http://www.govnokod.ru/

Если код небольшими порциями подавать, то можно здесь попробовать)

Стоит ли связываться подобными штуками?

Ну, попробуй.

Какие подводные камни?

Тебя смешают с говном, как вариант.

Если код небольшими порциями подавать, то можно здесь попробовать)

Может быть идея и неплохая, но боюсь что меня смоет волной говна :)

Никак не могу привыкнуть к формату общения на ЛОР'е

Тебя смешают с говном, как вариант.

Опередил :)

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

Наверное так и сделаю, всем спасибо за ответы!

Да никому ты не нужен. Таких как ты десятки тысяч по всему миру. Код надо писать, чтобы он работал, а не чтобы был красивым. И вообще, совет тебе, как начинающему:

избегай работы в команде программистов где ты не главный!

Поможет в жизни.

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

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

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

А за совет спасибо, но боюсь пока что рано становиться «главным»

ошибки проектирования/дизайна/интерфейса

Этому учат в ВУЗах. Там для такого специальные люди есть. Одни сначала рассказывают как делать, другие потом по шапке бьют, если ты даун.

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

Этому учат в ВУЗах.

ВУЗ закончил, но вы видимо давно не заглядывали в них, большая часть материала «универского» была освоенна самостоятельно, иначе писал бы я на lazarus'e сейчас.

Мне нравится как мне поставили диагноз что я «неуч» не видя даже 1 строчки кода.

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

закончил ВУЗ

самостоятельно освоил весь материал

все еще джун, неспособный в самостоятельный кодинг

\o/

щас бы доебаться до кого-нибудь

У него типа травма.

У него типа травма.

Тогда батхерд/агро мод отчасти понятен

Троллей бояться - в интернет не ходить. Посылай их быстро нахрен, никто не заставляет уделять им внимание.

Короче, на ЛОР-е есть волшебная кнопка «игнор». Видишь экземпляр - сразу, вместо «ответить на это сообщение» идешь на ник, и там «игнорировать». Обновляешь страницу, profit.

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

Короче, завози код, смотреть будем. Используй paste.org.ru (вручную выбери подсветку C++) и ссылку сюда. Ну или ссылку на гитхаб.

Короче, завози код, смотреть будем. Используй paste.org.ru (вручную выбери подсветку C++) и ссылку сюда. Ну или ссылку на гитхаб.

Окей, спасибо большое! Как что-то появится обязательно дам знать (думаю что в течении недели)

Отпишусь тогда видимо в этой теме, чтобы не создавать новую

Ишь чего захотел. Никто не будет тратить время ревьюить твой код ради того чтобы ревьюить твой код.

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

Иди работать и пусть тебя ревьюят коллеги

Уже работаю, но review не взлетает особо

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

Хорошая мысль, осталось только его придумать

Начни контрибутить в свободные проекты

Тоже неплохая мысль, но

Боюсь что уйдёт слишком много времени чтобы влиться в open-source проект.

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

Если в сетевом программировании разбираешься - поправь udpreplay (оно правда на C) так что бы оно в петлю научилось вещать. У меня есть наколенный патч, а оформить его что бы оно прошло то самое ревью мне влом пока что.

Уже работаю, но review не взлетает особо

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

Тоже неплохая мысль, но

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

Так внедряй, ревьюй других

Ага, и в итоге(если внедрить сможет, а для этого надо таки убедить начальство) будет что-то такое:

ТС -> reviewer: ну что, смотрел патч?(в патче UB на каждые 30 строк)
reviewer -> ТС: да, всё нормально(в мыслях: да иди ты уже н%х)

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

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

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

Есть много неплохих статей о том как внедряют стайл гайд, ревью, тесты, ci и всё такое прочее - ищите и читайте

Я согласен насчёт того, что всё это вещи нужные. Речь немного о другом: сомневаюсь, что подобное можно протолкнуть будучи рядовым программистом(да ещё и джуном). Есть шанс на что-то такое натолкнуться:

тесты писать не нужно поскольку это трата времени разработчика не на разработку продукта

или «ну давай, делай, потом раскажешь, чем всё закончилось», причём речь нифига не о прототипе)

Я согласен насчёт того, что всё это вещи нужные. Речь немного о другом: сомневаюсь, что подобное можно протолкнуть будучи рядовым программистом (да ещё и джуном).

Можно. Хотя я бы конечно близко не подошёл к шарашке в которой джуну приходится внедрять тесты и ревью, но если бы вдруг, и при этом это встретило бы сопротивление, то почему бы не покрыть тестами втихаря какую-нибудь часто меняемую функциональность и не ревьюить втихаря чужие коммиты. А через месяцок бухнуть пару сотен багов в трекер с пометками «сломано тем-то в таком-то коммите, поймано тестами/замечено в ревью и могло бы не попасть в прод если бы эти процессы были нормально внедрены» + отчётик начальству.

тесты писать не нужно поскольку это трата времени разработчика не на разработку продукта

говно-продукта, поправил (сам тестировщик/верификатор)

кстати, тесты не разработчик пишет, но для начала - требования (requirements)

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

те кто выпускает продукцию без тестирования - биомусор для биореактора

Ну хз тогда. Но первой в голову приходит вариант сменить место работы, требующий меньше усилий

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

Это ровно обратное определение исходного кода.

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

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

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