Во-первых, мне тяжело что-либо ревьюить код, если я не вник в суть задачи. Я при ревью спотыкаюсь об вопросы типа, решает ли код подставленную задачу и решает ли он её полностью. Т.е. мне прежде чем ревьюить нужно сначала прочитать задачу, её предысторию (связанные обсуждения) и только потом я могу приступать к коду. Для меня это настоящая работа.
Во-вторых, я спотыкаюсь о то, что я раньше аппрувил задачи с косяками. Такой опыт заставляет немного нервничать, когда курсор зависает над кнопкой Approve.
Как у вас с этим дело обстоит?
Всё сказанное выше — личное мнение, если не указано обратное.
Ф>Во-вторых, я спотыкаюсь о то, что я раньше аппрувил задачи с косяками. Такой опыт заставляет немного нервничать, когда курсор зависает над кнопкой Approve. Ф>Как у вас с этим дело обстоит?
Ревьюайеризм не предполагает ответственности ревьюайериста за то как работает чужой код. Просто накапливается статистика, кто часто ошибается, и кого потом обделить на делёжке добычи по любому другому поводу.
Здравствуйте, Философ, Вы писали:
Ф>Для меня это настоящая работа.
Так это и есть часть настоящей работы.
Ф>Во-вторых, я спотыкаюсь о то, что я раньше аппрувил задачи с косяками.
Это неприятно, но бывает. С другой стороны без ревью косяков бы меньше не стало. А есть опыт, когда на ревью удавалось находить и исправлять проблемы и это радует.
Ф>Как у вас с этим дело обстоит?
Ну да, это серьезная работа. Чем-то она легче чем самому писать, так как тут все написано, надо только прочитать и обдумать. Но чем-то сложнее, т.к. надо достаточно быстро осмыслить и проверить что другой делал куда дольше.
Работа просто другая, но тоже работе и тоже нужная — это возможность убрать баг, и не разбираться с ним потом в спешке готовя фикс.
O>>Ревьюайеризм не предполагает ответственности ревьюайериста... Ф>Можно не читать — просто жмякать Approve?
Либо делаешь бесплатно эту дополнительную работу непонятной стоимости (непонятно сколько туда надо внимания вложить чтобы не пропустить неизвестные проблемы — значит для работодателя есть вероятность, что работник вложит по собственной инициативе/из страха гораздо больше, чем если с ним явно договариваться), либо жмёшь Approve на свой постепенный переход в статус неполноправного и отчуждённого от карьеры.
Так в чем все-таки проблема, не хочешь ревьюить в принципе или не хочешь тратить на это непрогнозируемое количество времени?
Если первое — становись менеджером, будешь делегировать ревью другим.
Если второе — трекай в задаче время, потраченное на ревью. И установи какой-то лимит, который допустимо потратить на ревью одной задачи. Не уложился — ну что ж, чем смог — помог.
Здравствуйте, Философ, Вы писали:
Ф>Как у вас с этим дело обстоит?
В нашей комманде, любой знает, что если ты делаешь какой то адское изменение, которая затрагивает кучу кода, логика не тривиальная. То уже на начальном этапе разработке, думает парарельно кто это, и как будет ревьюить. Ну, соответственно время ревьювера также дополнительно оценивается и включается в планирование, чтобы его загруженность дала ему возможность это все адекватно отревьюить.
Если кто то под конец спринта, придет с каким то адским ревью, который нужно дня два потратить. То будут конечно разборки, почему заранее не предупредил, почему так сложно. А дальше вопрос приоритетов, кого то срывать с его задач, если эта фича важнее. Или фича ждет пока кто то освободиться.
Отдельно всегда на ревью, лично я смотрю можно ли все это было сделать проще.
Здравствуйте, Философ, Вы писали:
Ф>Во-первых, мне тяжело что-либо ревьюить код, если я не вник в суть задачи. Я при ревью спотыкаюсь об вопросы типа, решает ли код подставленную задачу и решает ли он её полностью.
Потребуй сопроводить код тестами, которые четко описывают все кейсы. Потребуй наличие юзерстори или юзкейса.
Если это багфикс, потребуй описания шагов бага, и также наличия теста на данный сценарий.
Если тесты будут написаны непонятно, потребуй, чтобы их написал понятно и наглядно (например, в теста на rest api наглядность теста повышает замена точечных ассертов на полный json реквеста и респонза).
Здравствуйте, Философ, Вы писали:
Ф>Во-первых, мне тяжело что-либо ревьюить код, если я не вник в суть задачи.
А зачем это нужно? Если сильно хочется вникать да контролировать плотно, то выгоднее идти через парно-программирование.
Если такой роскоши нет, то на ревью можно завести чек-лист, и каждый ревьюер будет идти по нем.
— размер пр. Если слишком много — пусть автор заводит фича бранч, сплитает фичу на промежуточные пр.
— есть ли валидация параметров публичных методов
— есть ли тесты — юниты, функциональные, e2e
— корректна ли документация на методы
— изобретены ли велосипеды
— именование публичных методов
— есть ли обработка ошибок
— корректно ли оформлены конфиги
— есть ли магические константы итд
— мутный код вида "а херлиты в базу лезешь сразу из контролера"
— секурити типа "распаковывать jwt токен без валидации ой-ой-ой" создан тикет №10123
До кучи, правила ревьюеров, запретить всё ниже
— переделай, измени, убери — вместо этого интервьюер сообщает, какая проблема с кодом, если надо, то создаёт тикет. Если же хочется идти по варианту "переделай, измени, убери", то парно-программирование будет лучше.
— это не секюрно. Вместо этого интервьюер сообщает, почему не секюрно, и создает тикет.
— идиотский код. Вместо этого интервьюер задает вопросы, уточняет и тд.
— нет форматирования итд. Для этого есть автоматические тулы
То есть, вместо два-три дня на ревью быстрый проход по чеклисту, на выходе список тикетов. Мелкие и критические тикеты исправляются сразу, остальные уходят в баклог как технические задачи. Дальше ПР мергается в транк.
Идея в том, что бы кодревью прошел быстро, и бранча не тухла неделями. Иначе проблем она создаст гораздо больше. Чем позже мерж, тем больше геморроя при мерже-ребейзе и тем больше скрытых багов
Здравствуйте, Философ, Вы писали:
Ф>Как у вас с этим дело обстоит?
Аналогично. Но даже низкое качество ревью и просто попытка разобраться помогают автору переделать всё так, чтоб более грамотный (и более занятый) сотрудник потратит меньше своего ценного времени на это и больше времени на твой собственный код. И, глядя на чужие косяки, как бы сам слегка растёшь над собой.
Здравствуйте, Философ, Вы писали:
Ф>Как у вас с этим дело обстоит?
плохо
мне часто предлагают ревьювить код который реализует бизнес логику или GUI на java
а мой код на Си обрабатывающий видео поток отдают на ревью java программистам
Ф>Во-первых, мне тяжело что-либо ревьюить код, если я не вник в суть задачи. Я при ревью спотыкаюсь об вопросы типа, решает ли код подставленную задачу и решает ли он её полностью. Т.е. мне прежде чем ревьюить нужно сначала прочитать задачу, её предысторию (связанные обсуждения) и только потом я могу приступать к коду. Для меня это настоящая работа.
Ф>Во-вторых, я спотыкаюсь о то, что я раньше аппрувил задачи с косяками. Такой опыт заставляет немного нервничать, когда курсор зависает над кнопкой Approve.
Ф>Как у вас с этим дело обстоит?
Спокойно к этому отношусь.
Надо понимать, что качественное ревью, со вниканием во все детали — это как заново написать этот код. Слишком трудоемко и обычно не требуется. Смотрю обычно явную лажу или какие-то типовые косяки у новичков. Ну что бы что-нибудь не отломали в моём коде. Глубоко не вникаю.
Здравствуйте, sergey2b, Вы писали:
S>мне часто предлагают ревьювить код который реализует бизнес логику или GUI на java S>а мой код на Си обрабатывающий видео поток отдают на ревью java программистам
Капец какой бардак!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Tourist, Вы писали:
T>Если кто то под конец спринта, придет с каким то адским ревью, который нужно дня два потратить. То будут конечно разборки, почему заранее не предупредил, почему так сложно. А дальше вопрос приоритетов, кого то срывать с его задач, если эта фича важнее. Или фича ждет пока кто то освободиться.
Забавно бывает. То на задаче где просто ресурс надо было поправить кто-то докапывается до какой-то мелочи, а потом вливаешь какой-то неслабый кусок функционала — и все такие ну давай мёржить, а потом пусть тестеры баги заводят ну это было в старом проекте, где на платформе Eclipse пилили RCP/RAP приложение. Сейчас на проектах уже обычно не так, а тут в эффектор вливаюсь и чёт пока прям сложненько, больно сильно логика размазана...
Здравствуйте, CreatorCray, Вы писали:
S>>а мой код на Си обрабатывающий видео поток отдают на ревью java программистам CC>Капец какой бардак!
ну а если больше нет си-шных программистов, надо же что-то делать
Когда мы старый проект индусам передавали, рассказывали им про всякие разные части проекта — и вот в очередной раз когда рассказываем про очередной кусок, который представляет собой тотальный редизайн, на половине! рассказа где-то через минут 45 прибегает в конфу менеджер индусский и говорит — ой это конечно всё хорошо что вы тут рассказываете, но эти индусы в этом ничего не понимают. Давайте позже эту встречу повторим, мы найдём тех, кто в этом рубит
всё конечно кончилось просто тем, что тупо час скринкаста записали, в конфлюенс залили и всё
Здравствуйте, CreatorCray, Вы писали:
S>>мне часто предлагают ревьювить код который реализует бизнес логику или GUI на java S>>а мой код на Си обрабатывающий видео поток отдают на ревью java программистам CC>Капец какой бардак!
Это состояние индустрии такое. Например, в команде джавист, сиплюсник и пейтон. Это препятствие для код ревью, но вовсе не повод отказываться от него.
Здравствуйте, Философ, Вы писали:
Ф>Во-первых, мне тяжело что-либо ревьюить код, если я не вник в суть задачи. Я при ревью спотыкаюсь об вопросы типа, решает ли код подставленную задачу и решает ли он её полностью.
Проверка работоспособности изменений на QA. Ревью кода- это незамыленный взгляд со стороны.
Я вот сталкиваюсь, что подчинённые неохотно ревьювят мои PR, а когда задают правильные вопросы- я не всегда переделываю. За что и поплатился недавно регрессией в продакшене.
Здравствуйте, Философ, Вы писали:
Ф>Как у вас с этим дело обстоит?
Я считаю, что вопросы о "решает и решает ли полностью" это зона ответственности тестировщиков, а не ревьюеров. Ревью это проверка соответствия формальным параметрам, которые не удалось автоматизировать. Ну и шанс найти баги, которые можно увидеть "свежим глазом". Если я буду в каждую задачу погружаться, по которой делаю ревью, то я больше ничем заниматься не буду.
По идее погружение это про парное программирование больше.
Хотя, конечно, тут вопрос больше к менеджерам. Если на ревью выделяется достаточно времени (процентов 20-50 от времени выполнения задачи) — ну классно.
Здравствуйте, Pauel, Вы писали:
P>Это препятствие для код ревью, но вовсе не повод отказываться от него.
Это профанация. Процесс ради процесса а не результата.
Ибо довольно бессмысленно давать код на review тем, кто ни в зуб ногой в тематике.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Артём, Вы писали:
S>>>а мой код на Си обрабатывающий видео поток отдают на ревью java программистам CC>>Капец какой бардак! Аё>Да как они смеют!
Артёмка как обычно нихрена не понял.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>Это препятствие для код ревью, но вовсе не повод отказываться от него. CC>Это профанация. Процесс ради процесса а не результата. CC>Ибо довольно бессмысленно давать код на review тем, кто ни в зуб ногой в тематике.
Вот чеклист для код ревью. Здесь по большому счету ничего не требует глубокого знания яп, хватит и поверхностных
— размер пр. Если слишком много — пусть автор заводит фича бранч, сплитает фичу на промежуточные пр.
— есть ли валидация параметров публичных методов
— есть ли тесты — юниты, функциональные, e2e
— корректна ли документация на методы
— изобретены ли велосипеды
— именование публичных методов
— есть ли обработка ошибок
— корректно ли оформлены конфиги
— есть ли магические константы итд
— мутный код вида "а херлиты в базу лезешь сразу из контролера"
— секурити типа "распаковывать jwt токен без валидации ой-ой-ой" создан тикет №10123
А вот если хочется продублировать работу автора кода, т.е. ровно тот кейс, для которого код ревью не нужен, тогда нужно глубокое знание.
И на это потребуется куда бОльшее количество времени, и эффект будет вообще говоря ничтожным.
Здравствуйте, Pauel, Вы писали:
P>Вот чеклист для код ревью.
Мда... симптоматичненько.
P>А вот если хочется продублировать работу автора кода, т.е. ровно тот кейс, для которого код ревью не нужен, тогда нужно глубокое знание. P>И на это потребуется куда бОльшее количество времени, и эффект будет вообще говоря ничтожным.
Мы с тобой настолько на разных уровнях отвественности что даже не интересно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>А бюджеты резиновые, да?
CC>Раз больше сишников кроме него нету то это какой то ССЗБ, ибо bus factor никто не отменял.
Сейчас почти вся индустрия так работает. Позволить себе дублирование инженеров могут только самые денежные конторы. У всех остальных висит этот риск в той или иной степени.
Здравствуйте, Pauel, Вы писали:
P>— изобретены ли велосипеды
Вот как питонист оценит это в плюсовом коде? В плюсах количество необходимых велосипедов сильно отличается в зависимости от версии, тут даже плюсовику может быть не просто.
Здравствуйте, CreatorCray, Вы писали:
P>>И на это потребуется куда бОльшее количество времени, и эффект будет вообще говоря ничтожным. CC> CC>Мы с тобой настолько на разных уровнях отвественности что даже не интересно.
Код ревью, как и любой процесс, строится под конкретные условия, а не от балды, "как правильно", итд. Что бы пересматривать всю логику, как делает ТС, должны быть веские основания.
Здравствуйте, Skorodum, Вы писали:
P>>— изобретены ли велосипеды S>Вот как питонист оценит это в плюсовом коде? В плюсах количество необходимых велосипедов сильно отличается в зависимости от версии, тут даже плюсовику может быть не просто.
Смотря что. Мелкую механику "вычислим смещение и засетаем по указателю" — скорее всего никак. Более крупную, типа "парсим xml регекспами в стиле Шеридана" — вполне себе. А вот все остальные пункты — вообще влёт.
Здравствуйте, Pauel, Вы писали:
CC>>Раз больше сишников кроме него нету то это какой то ССЗБ, ибо bus factor никто не отменял. P>Сейчас почти вся индустрия так работает.
С одним единственным инженером который тянет на себе часть проекта?
Чо, правда?
P> Позволить себе дублирование инженеров могут только самые денежные конторы.
Когда у тебя такой только один это не дублирование.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>Сейчас почти вся индустрия так работает. CC>С одним единственным инженером который тянет на себе часть проекта? CC>Чо, правда?
Именно. Такое вот положение дел в индустрии. Проектов, которые ведет один человек, пруд пруди. Проектов, где зоны ответсвенности разработчиков слабо пересекаются много больше. Например, один разработчик ведет кучку пакетов-модулей-фич, другой — другую такую кучку. Пересечение разве что в пакетах которые не сильно важны, что бы выделять на них одного человека.
В редких случаях это иначе.
Разделение труда на марше, такое проходили все отрасли во все времена.
P>> Позволить себе дублирование инженеров могут только самые денежные конторы. CC>Когда у тебя такой только один это не дублирование.
Здравствуйте, Артём, Вы писали:
CC>>Раз больше сишников кроме него нету то это какой то ССЗБ, ибо bus factor никто не отменял.
Аё>У меня несколько коллег- жавистов, которые в прошлом писали на C++. No big deal поревьювить.
Самый лучший код ревью, который у меня был, это ревью от менеджера, который еще кодит на джаве время от времени.
Постоянно находит кучу важных проблем в апи, тестах, итд. Естественно, в мелкую моторику он не лезет — это и не нужно.
Здравствуйте, Pauel, Вы писали:
P>Именно. Такое вот положение дел в индустрии. Проектов, которые ведет один человек, пруд пруди.
Мы с тобой работаем в сильно разных индустриях.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>Именно. Такое вот положение дел в индустрии. Проектов, которые ведет один человек, пруд пруди. CC>Мы с тобой работаем в сильно разных индустриях.
Это одна индустрия Просто ты работаешь в конторе где денег более чем достаточно для разработки. Из этого не следует, что у всех так же как и тебя.
Дело не в стеке технологий. Основные причины это бюджеты и цена ошибки на проекте.
Подавляющая часть ИТ это мелочевка, на самом деле, денег еле-еле хватает оплачивать команду, и цена ошибки невысокая. Отсюда ясно, что дублирование это роскошь.
Например, если у конторы большой бюджет, цена ошибки на фронтенде высокая — разумеется это отразится и на том, как комплектуются команды.
А если нативный кодинг, по уши где то в кернел моде, но бюджеты небольшие и цена ошибки невысокая, то здесь будет полно разработчиков одиночек.
Потому в норме нехватку людей можно видеть и в нативной разработке, ос-драйвера-итд, и в веб, бакенде, фронтенде, мобайле, мл, джава, дотнет — где угодно.
Здравствуйте, Артём, Вы писали:
Аё>>>У меня... CC>>А у него сколько таких?
Аё>Взять любого жависта кто начинал в середине-конце 90-х,когда C++ был мейнстримом.
Таких на рынке около нуля. Задача не совсем ясна — глазом баги искать?
Здравствуйте, Pauel, Вы писали:
P>Это одна индустрия
Дадада, производство реактивных двигателей и однотактовых дырчиков для мопеда это тоже "одна индустрия".
P>Из этого не следует, что у всех так же как и тебя.
Поэтому они клепают из говна и палок и при этом считают что так оно и должно быть.
P>Дело не в стеке технологий.
Никто и не говорил про стек.
P>Основные причины это бюджеты и цена ошибки на проекте.
Я уже говорил что у нас с тобой разные уровни отвественности. На моём описанный тобой в соседней подветке процесс — лютое говно и повод выгнать пинками на мороз.
P>Подавляющая часть ИТ это мелочевка, на самом деле, денег еле-еле хватает оплачивать команду, и цена ошибки невысокая. Отсюда ясно, что дублирование это роскошь.
Там и процветает херак херак и в продакшен. Ну грохнется всё у клиента, похоронит с собой всё что было — "пустяки, дело житейское" (С).
P>А если нативный кодинг, по уши где то в кернел моде, но бюджеты небольшие и цена ошибки невысокая, то здесь будет полно разработчиков одиночек.
Ну удачи, чо!
P>Потому в норме нехватку людей можно видеть и в нативной разработке, ос-драйвера-итд, и в веб, бакенде, фронтенде, мобайле, мл, джава, дотнет — где угодно.
Нехватку людей можно видеть только в говноклёпстве, а никак не разработке.
Ну и в стартапах ещё на ранней стадии.
Во всех остальных случаях такая экономия это путь к банкротству.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Дадада, производство реактивных двигателей и однотактовых дырчиков для мопеда это тоже "одна индустрия".
iOS это такие "реактивные двигатели" После Андроида, где всё работает, открываю свой веб код в айпада- и ой. Яблочко как всегда, отстаёт на пару лет от Андрюши. Что характерно, и от MS (Edge) отстаёт.
P>>Основные причины это бюджеты и цена ошибки на проекте. CC>Я уже говорил что у нас с тобой разные уровни отвественности. На моём описанный тобой в соседней подветке процесс — лютое говно и повод выгнать пинками на мороз.
Здравствуйте, CreatorCray, Вы писали:
P>>Основные причины это бюджеты и цена ошибки на проекте. CC>Я уже говорил что у нас с тобой разные уровни отвественности.
У меня два вопроса:
Что у тебя за особый уровень ответсвенности?
Какой, по твоему, у меня уровень ответственности?
> На моём описанный тобой в соседней подветке процесс — лютое говно и повод выгнать пинками на мороз.
У тебя как обычно исключительно эмоциональные аргументы.
Что конкретно не так с процессом в подветке?
Как конкретно выглядит код ревью у тебя на конторе?
P>>Это одна индустрия CC>Дадада, производство реактивных двигателей и однотактовых дырчиков для мопеда это тоже "одна индустрия".
Ты путаешь домен и индустрию. Индустрия — ИТ, домен — реактивные двигатели.
P>>Из этого не следует, что у всех так же как и тебя. CC>Поэтому они клепают из говна и палок и при этом считают что так оно и должно быть.
Кто это они? В прошлый раз мы выясняли, что у тебя сотни сайтов якобы глючат, а ты притащил ажно один пример, который оказался нерелевантным, и далее ты начал хамить.
P>>Подавляющая часть ИТ это мелочевка, на самом деле, денег еле-еле хватает оплачивать команду, и цена ошибки невысокая. Отсюда ясно, что дублирование это роскошь. CC>Там и процветает херак херак и в продакшен. Ну грохнется всё у клиента, похоронит с собой всё что было — "пустяки, дело житейское" (С).
Снова эмоциональный аргумент. Ни разу не видел "грохнется всё — пустяки". Вероятно, это твои персональные страхи.
P>>А если нативный кодинг, по уши где то в кернел моде, но бюджеты небольшие и цена ошибки невысокая, то здесь будет полно разработчиков одиночек. CC> CC>Ну удачи, чо!
Расскажи, как иначе, если у людей есть деньги на примерно половину разработчика. Где им взять двух целых, что бы код-рьевью делать?
P>>Потому в норме нехватку людей можно видеть и в нативной разработке, ос-драйвера-итд, и в веб, бакенде, фронтенде, мобайле, мл, джава, дотнет — где угодно. CC>Нехватку людей можно видеть только в говноклёпстве, а никак не разработке.
Вероятно в твоём мирке бюджеты резиновые, ну или к зп разработчиков не привязаны. В обычном мире это почти всегда не так.
CC>Ну и в стартапах ещё на ранней стадии. CC>Во всех остальных случаях такая экономия это путь к банкротству.
Выше бюджета всё равно не прыгнешь. Вот есть у тебя денег на пол-разработчика. Кто будет делать код-ревью?
чеклист для код ревью
Здесь по большому счету ничего не требует глубокого знания яп, хватит и поверхностных
— размер пр. Если слишком много — пусть автор заводит фича бранч, сплитает фичу на промежуточные пр.
— есть ли валидация параметров публичных методов
— есть ли тесты — юниты, функциональные, e2e
— корректна ли документация на методы
— изобретены ли велосипеды
— именование публичных методов
— есть ли обработка ошибок
— корректно ли оформлены конфиги
— есть ли магические константы итд
— мутный код вида "а херлиты в базу лезешь сразу из контролера"
— секурити типа "распаковывать jwt токен без валидации ой-ой-ой" создан тикет №10123
Если это то, как ты делаешь ревью то дальше не интересно совсем
P>У тебя как обычно исключительно эмоциональные аргументы.
Это knee jerk reaction на узнаваемые причины капитальных факапов в прошлом, кои имел сомнительное удовольствие наблюдать в достаточной близости.
P>Что конкретно не так с процессом в подветке?
Он пустой.
P>Как конкретно выглядит код ревью у тебя на конторе?
Фокус на том, что изменение конкретно делает и делает ли оно это правильно.
P>Ты путаешь домен и индустрию. Индустрия — ИТ, домен — реактивные двигатели.
Тогда это становится настолько общим что смысл имеет примерно как средняя температура по больнице.
P>у тебя сотни сайтов якобы глючат
Ну и ты конечно щас подтвердишь заявленное ссылкой, да?
P> а ты притащил ажно один пример, который оказался нерелевантным
Напомню как оно было
P>>>денег еле-еле хватает оплачивать команду, и цена ошибки невысокая. CC>>Там и процветает херак херак и в продакшен. Ну грохнется всё у клиента, похоронит с собой всё что было — "пустяки, дело житейское" (С). P>Ни разу не видел "грохнется всё — пустяки".
Напомню, речь о случае
P>>>денег еле-еле хватает оплачивать команду, и цена ошибки невысокая.
Ты хочешь сказать что вот эта команда в голодном обмороке да ещё и зная что "цена ошибки невысокая" (С) Икемфула напишет качественный production ready код?
Чота в реальности у таких выходит всё больше спагетти в стиле "я его слепила из того, что было" почему то.
P>Расскажи, как иначе, если у людей есть деньги на примерно половину разработчика.
Да уже рассказал. Будет то же самое когда нет денег на нормального плиточника:
АКА "херак херак и в продакшен".
P>Вот есть у тебя денег на пол-разработчика.
Я умный, я с таким бюджетом даже не возьмусь, ибо как жопу не рви — получится говно.
А плохо делать — себе дороже, со всех сторон.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Артём, Вы писали:
Аё>Здравствуйте, Pauel, Вы писали:
Аё>>>Взять любого жависта кто начинал в середине-конце 90-х,когда C++ был мейнстримом.
P>>Таких на рынке около нуля.
Аё>40+ летних жавистов совсем нет в РФ? Ну ок, м.б. и так- сидят каждый на своём шестке, пилят на чём начинали карьеру
да не, просто на зарплату в "пол программиста" не идут. подумать только — какие меркантильные и жадные личности
Во первых всё заканчивается синтаксическими и стилистическими ошибками, неправильно (в их мнении) именованными переменными, вопросами форматирования и т.д.. Всё заканчивается личностными перетягами, мой стиль кода лучше или твой.
Никто не вникает в суть задачи. Все работают в своём потоке, в голове свои задачи. Сложно даже лидам/менеджерам — они хоть и в курсе задачи но за всеми телодвижениями в коде не уследишь — нужно знать и АПИ которое используется, и документацию, язык в конце концов и много чего. Тем более что код-ревью на сайте не предлагает какой то осмысленной навигации по коду — вот просто текст и ты сам себе буратинос.
Такие ревью это корпоративный стандарт, проталкиваемый гитхабами. Гнилые коммиты постоянно проскальзывают в релиз, но ревьюеры обычно к коду не возвращаются и с них спроса никакого.
Один раз было только полезно, когда чувак полез переделывать мой код и получил кучу конструктивного (и я подчёркиваю, конструктивного, никакой иронии) потока замечаний что он просто отдал бранч мне. Тут мы как бы поменялись ролями.
Если уж всё формализировано, как тут советовали, формализируйте до конца — проверяйте наличие тестов, отсутствие pragma warning off, использование правильных контейнеров, отсутствие/правильная обработка исключений, что то вам важно. Всё то, что лежит на поверхности и хорошо формализуется. Наставил галочек и пошёл ковырять в зубах дальше спокойно.
Есть правда и альтернативы PR-ам: парное программирование (тут тоже упоминали) звучит многим нереалистично, на практике можно брать оттуда какие то элементы. И вот в одной из контор, в целях ревью мы как раз садились с программистом вместе и он показывал код и рассказывал что и как код делает, какую он задачу решает, какие абстракции он ввёл и зачем и т.д.. Золотые были времена. Особенно полезно когда в конторе есть расслоение на джун и сеньоров — сеньор проводит глубокую проработку кода, дизайна и т.д., а джуны очень быстро учатся.
Здравствуйте, CreatorCray, Вы писали:
P>>Как конкретно выглядит код ревью у тебя на конторе? CC>Фокус на том, что изменение конкретно делает и делает ли оно это правильно.
Капитан очевидность ? Каждый пр подразумевает это по дефолту.
P>> а ты притащил ажно один пример, который оказался нерелевантным CC>Напомню как оно было
И поскольку
1 воспроизводится только на самом мощном железе,
2 не воспроизводится на среднем, т.е. намного более слабом
3 признаки тормозов на этом среднем железе отсутствуют
то следовательно проблема с завыванием находится точно не в жээсе.
P>>Ни разу не видел "грохнется всё — пустяки".
CC>Напомню, речь о случае CC>
P>>>>денег еле-еле хватает оплачивать команду, и цена ошибки невысокая.
А как ты понимаешь, что по твоему, означает фраза "цена ошибки невысокая" ?
Я вот ни разу не видел такого, что бы цена "грохнется всё" была невысокой. А у тебя это возможно. Что за чудо такое?
CC>Да уже рассказал. Будет то же самое когда нет денег на нормального плиточника:
Итого — ты долго метал понты, а потом вдруг задним числом согласился с моим утверждением про бюджеты.
P>>Вот есть у тебя денег на пол-разработчика. CC>Я умный, я с таким бюджетом даже не возьмусь, ибо как жопу не рви — получится говно.
Здравствуйте, Артём, Вы писали:
Аё>Здравствуйте, Pauel, Вы писали:
Аё>>>Взять любого жависта кто начинал в середине-конце 90-х,когда C++ был мейнстримом.
P>>Таких на рынке около нуля.
Аё>40+ летних жавистов совсем нет в РФ? Ну ок, м.б. и так- сидят каждый на своём шестке, пилят на чём начинали карьеру
40+ летних разрабов от силы единицы процентов по всему миру. В ИТ в силу быстрого роста большинство покидает линейные должности типа разработчика уже к 30 годам.
Здравствуйте, Pauel, Вы писали:
P>Капитан очевидность ? Каждый пр подразумевает это по дефолту.
Да ну! Тогда из твоего списка выходит что например "есть ли обработка ошибок" НЕ подразумевается по дефолту.
Ты уж определись что ли.
P>то следовательно проблема с завыванием находится точно не в жээсе.
Профайлер при этом показывал как раз на JS
P>А как ты понимаешь, что по твоему, означает фраза "цена ошибки невысокая"? P>Я вот ни разу не видел такого, что бы цена "грохнется всё" была невысокой.
Это вопрос к тому, что ТЫ понимаешь. Ибо "цена ошибки невысокая" написано именно тобой.
CC>>Да уже рассказал. Будет то же самое когда нет денег на нормального плиточника: P>Итого — ты долго метал понты, а потом вдруг задним числом согласился
Нет, ты опять выдаёшь желаемое за действительное.
Я сказал что если нет нормального бюджета то неизменно получится говно. Потому не надо даже за такое браться.
P>Эдак все стартапы у тебя разбегутся.
Стартапы в которых я участвовал и в которые меня звали но я отказался все имели достаточно денег на куда больше чем полтора землекопа.
Я не знаю ни одного стартапа с раскладом "есть деньги на примерно половину разработчика" который бы дожил до зимы.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Артём, Вы писали:
P>>В ИТ в силу быстрого роста большинство покидает линейные должности типа разработчика уже к 30 годам.
Аё>Ого! И в кого это большинство переквалифицируется уже к 30 годам?
Большинство становится тимлидами, архитекторами-консультантами разных сортов, дев-менеджерами, департмент-менеджерами, деливери. Как бы и разработка, но это уже нелинейные должности, отдельными фичами и всякой рутиной коей на любом проекте 80-90% такие люди как правило не занимаются.
Остальные идут в пм, програм, ресурсменеджмент и даже в HR, стаффинг, рекрутинг. Многие открывают свои студии-конторы. Значительная часть вообще уходит из разработки в бизнес.
Вы можете глянуть демографику контингента на SO. Старше 35 всего 30%. И это все пользователи, как линейных профилей, так и нелинейных.
Оставаться на линейных должностях чем старше тем труднее. Когда рост индустрии замедлится, это выровняется, а пока что как есть.
Даже если такой разраб остался на линейной позиции, его ЗП выдержит далеко не любой бюджет.
Отсюда ясно, что расчитывать стоит на свои силы, и правильно организовывать процесс разработки.
Здравствуйте, CreatorCray, Вы писали:
P>>Капитан очевидность ? Каждый пр подразумевает это по дефолту. CC>Да ну! Тогда из твоего списка выходит что например "есть ли обработка ошибок" НЕ подразумевается по дефолту. CC>Ты уж определись что ли.
А что тут определяться? Вероятно, ты чеклист понял как формальное отношение вида "нашел try-catch и поставил галку"
Чеклист нужен для того, что бы в обязательном порядке покрыть наиболее важные источники проблем, которые плохо отлавливаются другими методами типа тестов, логирования итд. Например, "отсутствие тестов" не проверяется самими тестами.
Соответсвенно ревьюер смотрит проверку ошибок, проверяет, покрыто ли это тестами, и если да, то ставит галочку "еррор хандлинг есть и покрыт тестами".
С таким подходом эффекта от код-ревью больше, и отнимает времени меньше. Естественно, всё это в привязке к конкретной задаче.
P>>то следовательно проблема с завыванием находится точно не в жээсе. CC>Профайлер при этом показывал как раз на JS
Если тормозов нет на хилом железе, то неважно, что там в профайлере. А именно этот кейс мы имеем. По крайней мере так дело на всех компах, где я это проверял. Вобщем, твоя проблема нерелевантна.
P>>А как ты понимаешь, что по твоему, означает фраза "цена ошибки невысокая"? P>>Я вот ни разу не видел такого, что бы цена "грохнется всё" была невысокой. CC>Это вопрос к тому, что ТЫ понимаешь. Ибо "цена ошибки невысокая" написано именно тобой.
Я ж написал — ни разу не видел, что "грохнется всё" имело бы низкую цену ошибки. А у тебя, похоже, это норма. Может дело в тебе?
P>>Итого — ты долго метал понты, а потом вдруг задним числом согласился CC>Нет, ты опять выдаёшь желаемое за действительное. CC>Я сказал что если нет нормального бюджета то неизменно получится говно. Потому не надо даже за такое браться.
Снова эмоциональные и чрезмерно категоричные аргументы!
Как минимум, есть варианты вида "из 100 фич оставить 5 самых важных". Или так "сделаейте нам каркас что бы с фичами справился наш мидл Вася". Или так "вместо своего бакенда купим сервис и обойдемся небольшой надстройкой что бы хватило на год-два"
P>>Эдак все стартапы у тебя разбегутся. CC>Стартапы в которых я участвовал и в которые меня звали но я отказался все имели достаточно денег на куда больше чем полтора землекопа. CC>Я не знаю ни одного стартапа с раскладом "есть деньги на примерно половину разработчика" который бы дожил до зимы.
Стартапы это всегда про желание инвестировать личное время в силу личного интереса к продукту. Инвесторы как правило подключаются на более позднем этапе.
Здравствуйте, Pauel, Вы писали:
P>Вы можете глянуть демографику контингента на SO. Старше 35 всего 30%.
Да потому что людям постарше этот детсад попросту не интересен.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pauel, Вы писали:
P>Большинство становится тимлидами, архитекторами-консультантами разных сортов, дев-менеджерами, департмент-менеджерами, деливери.
90% застревает на должности "синьёр-помидор". Причём, чтобы подняться выше, нужны не программистские скиллы.
Здравствуйте, CreatorCray, Вы писали:
P>>Вы можете глянуть демографику контингента на SO. Старше 35 всего 30%. CC>Да потому что людям постарше этот детсад попросту не интересен.
Именно — потому, что этот "детский сад" актуален именно для линейных разработчиков. А дальше совсем другая работа.
Здравствуйте, Pauel, Вы писали:
P>Из тех, с кем я учился, те самые 90% уже не разработчики.
практика показывает, что цифра 75% работает гораздо лучше
(если чё, то моя реплика о полной фуфлёжности приводимых выше цифр)
P>Из моих студентов уже слишком много нелинейных — тл, архитекторы,девменеджеры итд.
вам бы договориться о терминологии. "нелинейный" — это как? звучит как "не программист уровня мидл или джун".
ну да, таких после 40 трудно найти
P>По конторе — к 40 сеньоров остается ничтжное количество.
и да и нет. у нас, например джунов не нанимают. так что картинка строго обратная, можно делать не верные выводы о ничтожном количестве джунов "по конторе"
полагаю сеньоров не надо столько же сколько нужно "линейных" (откуда этот термин вообще взялся?) вот они и расползаются: кто в менеджеры, кто в архитекторы, ну а кто-то уходит в свободное плавание или из профессии
P>Хотелось бы взглянуть на ваши источники.
Здравствуйте, Философ, Вы писали:
Ф>Во-первых, мне тяжело что-либо ревьюить код, если я не вник в суть задачи. Я при ревью спотыкаюсь об вопросы типа, решает ли код подставленную задачу и решает ли он её полностью. Т.е. мне прежде чем ревьюить нужно сначала прочитать задачу, её предысторию (связанные обсуждения) и только потом я могу приступать к коду. Для меня это настоящая работа.
если при ревью что то не ясно, то надо задавать вопрос в комментах, а не жать на аппрув. попроси автора написать подробнее, что он/она там сделали и зачем
Ф>Во-вторых, я спотыкаюсь о то, что я раньше аппрувил задачи с косяками. Такой опыт заставляет немного нервничать, когда курсор зависает над кнопкой Approve.
такое бывает, проходит с опытом и лучшем знании проекта на котором работаешь
Ф>Как у вас с этим дело обстоит?
нормально обстоит делаю довольно много их (1 — 3 в день) если что то не ясно или выглядит подозрительно не апрувлю пока не объяснят или не исправят. иногда для ревью создается целый митинг и на нем очень тщательно все проверяем
Здравствуйте, baxton_ulf, Вы писали:
P>>Из моих студентов уже слишком много нелинейных — тл, архитекторы,девменеджеры итд.
_>вам бы договориться о терминологии. "нелинейный" — это как? звучит как "не программист уровня мидл или джун".
Линейный — джун, мидл, сеньор. После линейных идут менеджерские разновидности, например, тот же архитектор или r&d, тимлид, дев менеджер, департмент, деливери, пм итд.
_>и да и нет. у нас, например джунов не нанимают.
Сеньоры пилят в том числе и мелочевку и рутинные задачи? Ну круто. Только зачем?
Кстати, у меня в скайпе подпись: "команда сеньоров без джунов это команда мидлов"
_>полагаю сеньоров не надо столько же сколько нужно "линейных" (откуда этот термин вообще взялся?)
Рутинного кода на любом проекте в районе 80-90%
У вас или сеньоры — лиды будут этим заняты, или двуны разгружают сеньоров и постепенно вырастают
_>источник под названием: что вижу, то пою.
Здравствуйте, RedUser, Вы писали:
_>>нормально обстоит делаю довольно много их (1 — 3 в день)
RU>А какой в средней объём изменений в строчках?
я продвигаю идею маленьких ПРов, если приходит простыня с изменениями за неделю (месяц и тд) я прошу разбить на части.
RU>Сколько комментариев на одно ревью?
когда как, может и ни одного. особенно если где-то уже все обсудили. а может и много. но если уж совсем много получается, то это признак того, что сделано совсем уж плохо
Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, baxton_ulf, Вы писали:
P>>>Из моих студентов уже слишком много нелинейных — тл, архитекторы,девменеджеры итд.
_>>вам бы договориться о терминологии. "нелинейный" — это как? звучит как "не программист уровня мидл или джун".
P>Линейный — джун, мидл, сеньор. После линейных идут менеджерские разновидности, например, тот же архитектор или r&d, тимлид, дев менеджер, департмент, деливери, пм итд.
ясно. значит я все еще "линейный"
менеджеры и архитекторы — это отдельные виды. у них у самих то же самое деление — джун, мидл, сеньор. у нас возможно мигрировать между этими видами.
_>>и да и нет. у нас, например джунов не нанимают.
P>Сеньоры пилят в том числе и мелочевку и рутинные задачи? Ну круто. Только зачем?
сеньеры или мидлы, кому что перепадет тот то и пилит.
в терминах этого топика у нас "очень высокая цена ошибки", потому и нет джунов
P>Кстати, у меня в скайпе подпись: "команда сеньоров без джунов это команда мидлов"
я не против
_>>полагаю сеньоров не надо столько же сколько нужно "линейных" (откуда этот термин вообще взялся?)
P>Рутинного кода на любом проекте в районе 80-90% P>У вас или сеньоры — лиды будут этим заняты, или двуны разгружают сеньоров и постепенно вырастают
ну примерно так, только мидлы разгружают
_>>источник под названием: что вижу, то пою.
P>Демографика на SO куда более релевантный источник
Здравствуйте, johny5, Вы писали:
J>отсутствие pragma warning off
Чем не угодили pragma warning off? Это хорошая вещь, помогающая держать treat warnings as errors включенным, чтобы в нужных местах сказать железному мозгу, что человек обо всём подумал, и это осознанное решение.
Здравствуйте, Pauel, Вы писали:
P>Из моих студентов уже слишком много нелинейных
Что такое "линейный"? Механический кодер, без малейшего просвета своих мыслей?
P>По конторе — к 40 сеньоров остается ничтжное количество.
Настоящий senior способен взять фичу на этапе "есть намётки что мы хотим получить", задизайнить и реализовать, включая cross-team взаимодействие.
Это и архитект и частично менеджер в одном флаконе.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
Аё>>открываю свой веб код в айпада CC>А я то тут каким боком, Артёмка
А ты, когда про рокет саенс сипипи команд написал- ты не про "что вижу, то и пою"? Ты же яблочко видишь изнутри. Так вот я тебе про "особенность" яблочка, когда вроде бы ну что можно испогагить- бери из хромиума, но нет, везде свой "штрижок". Рокет саентисты <.>.
P>Рутинного кода на любом проекте в районе 80-90% P>У вас или сеньоры — лиды будут этим заняты, или двуны разгружают сеньоров и постепенно вырастают
Что для сеньора рутинная задача, для джуна — совсем не факт.
Сеньор, может быть, быстренько сделал бы это сам.
А для джуна нужна чёткая постановка задачи.
Иногда с указанием, как именно это делать, чтобы он не начал делать что-нибудь не то.
Потом несколько итераций merge request-а, где сеньору надо будет расписывать для джуна, почему делать вот так не надо.
В процессе джун ещё будет дёргать сеньора с вопросами, как вот это или то лучше сделать.
Разгружает ли это сеньора — ну не знаю, не похоже.
Здравствуйте, Артём, Вы писали:
Аё>А ты, когда про рокет саенс сипипи команд написал- ты не про "что вижу, то и пою"? Ты же яблочко видишь изнутри. Так вот я тебе про "особенность" яблочка, когда вроде бы ну что можно испогагить- бери из хромиума, но нет, везде свой "штрижок". Рокет саентисты <.>.
Здравствуйте, CreatorCray, Вы писали:
A>>держать treat warnings as errors включенным CC>Это как по мне обязательно и безальтернативно.
Соглы. Для этого и нужен #pragma disable, который позволяет игнорировать ворнинги точечно, а не все сразу. Навскидку пара примеров: хедер может придти из источника, над которым нет власти, а это библиотека, которую нельзя не использовать. Ну и deprecated, когда в нём почему-либо есть нужда.
Здравствуйте, Alekzander, Вы писали:
A>Здравствуйте, CreatorCray, Вы писали:
A>>>держать treat warnings as errors включенным CC>>Это как по мне обязательно и безальтернативно.
A>Соглы. Для этого и нужен #pragma disable, который позволяет игнорировать ворнинги точечно, а не все сразу. Навскидку пара примеров: хедер может придти из источника, над которым нет власти, а это библиотека, которую нельзя не использовать. Ну и deprecated, когда в нём почему-либо есть нужда.
Ну я не говорю что это абсолютное зло а то, за чем можно поглядывать в чужом коде и требовать обоснования использования. Впрочем это вершина айсберга того что должно быть вообще проверено во время ревью.
Здравствуйте, CreatorCray, Вы писали:
P>>Из моих студентов уже слишком много нелинейных CC>Что такое "линейный"? Механический кодер, без малейшего просвета своих мыслей?
До сеньора включительно. Это сотруднтки, которые выполняют основную работу, коей под 80-90%
CC>Это и архитект и частично менеджер в одном флаконе.
Архитектор и менеджер в одном флаконе это точно выше сеньора.
Здравствуйте, Артём, Вы писали:
Аё>А ты, когда про рокет саенс сипипи команд написал
Артёмка, спикай на каком нить уж одном езыге
А то твои экзесисы нихрена не компренде
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, RedUser, Вы писали:
Аё>>Да, это совметная работа Гугл, Эппл и МС насколько я понимаю. Но API почему-то работают немножко по-разному между Хром / Эдж и Сафари.
RU>Google сделал свой форк (и Edge его использует): RU>https://ru.wikipedia.org/wiki/WebKit#Форк_движка_(Blink)
Blink — свободный движок для отображения веб-страниц, разработанный американской компанией Google Inc. на основе кода WebCore из WebKit для браузера Chromium.
Сафари не использует Хромиум? Ну м.б. в этом причина странных отличий Сафари.
Здравствуйте, RedUser, Вы писали:
RU>Что для сеньора рутинная задача, для джуна — совсем не факт. RU>Сеньор, может быть, быстренько сделал бы это сам. RU>А для джуна нужна чёткая постановка задачи. RU>Иногда с указанием, как именно это делать, чтобы он не начал делать что-нибудь не то. RU>Потом несколько итераций merge request-а, где сеньору надо будет расписывать для джуна, почему делать вот так не надо. RU>В процессе джун ещё будет дёргать сеньора с вопросами, как вот это или то лучше сделать. RU>Разгружает ли это сеньора — ну не знаю, не похоже.
Первые месяцы так и будет. Джун это примерно до года опыта. В итоге мы получаем полностью готового мидла, под ключ. Самое главное это заниматься своими делами, а джуну указать границы ответственности.
Не хотите джунов — есть мидлы. Только они всё равно требуют супервайза, их всё равно нужно вводить в проект, и у них далеко не всегда есть все нужные баззворды итд.
Здравствуйте, Pauel, Вы писали:
P>Джун это примерно до года опыта. В итоге мы получаем полностью готового мидла, под ключ.
Миддл это примерно до 2 года опыта. В итоге мы получаем полностью готового помидора, под ключ
Помидор это примерно до 3 года опыта. В итоге мы получаем полностью готового техлида, под ключ
Техлид это примерно до 4 года опыта. В итоге мы получаем полностью готового директора разработки, под ключ
Ну и т.д.
Реально, если отбросить фальшивые "синьёр" приставки, распределение такое:
0-5 лет — джун. Может получать лычки "синьёр, но границы ответственности и уровень зп- джун
5-9 лет — миддл. Не нужен присмотр за ним, но он ещё не может присматривать за другими
9+ лет- синьёр. Ветеран индустрии, к его мнению начинают прислушиваться. Мидлы обращаются за советом в трудной ситуации. Присматривает за другими, ревьювит код и т.п.
Дальше- стеклянный потолок программиста. Для роста в техлида или в тимлида, нужно качать софт скиллы.
Здравствуйте, johny5, Вы писали:
A>>>>держать treat warnings as errors включенным CC>>>Это как по мне обязательно и безальтернативно.
A>>Соглы. Для этого и нужен #pragma disable, который позволяет игнорировать ворнинги точечно, а не все сразу. Навскидку пара примеров: хедер может придти из источника, над которым нет власти, а это библиотека, которую нельзя не использовать. Ну и deprecated, когда в нём почему-либо есть нужда.
J>Ну я не говорю что это абсолютное зло а то, за чем можно поглядывать в чужом коде и требовать обоснования использования. Впрочем это вершина айсберга того что должно быть вообще проверено во время ревью.
Про обоснование это хороший поинт. Я как раз порылся в старых проектах, вспомнить не мог, зачем там всё так, и что за 4995 и 4996 встречаются чаще всего. Надо было в комментариях обосновывать. Смутно вспоминаю, что с переходом на более новые функции ломалась сборка под XP. В общем, маркетологам дали рычаг давления на программистов в виде __declspec(deprecated)/[deprecated]] (если, конечно, правильно вспомнил), надо же как-то с этим было бороться.
А с остальным согласен. Вот с этим особенно:
>Есть правда и альтернативы PR-ам: парное программирование (тут тоже упоминали) звучит многим нереалистично, на практике можно брать оттуда какие то элементы. И вот в одной из контор, в целях ревью мы как раз садились с программистом вместе и он показывал код и рассказывал что и как код делает, какую он задачу решает, какие абстракции он ввёл и зачем и т.д.. Золотые были времена.
Аналогичный опыт, мы с коллегой работали парой над одним продуктом, каждый у себя больше времени проводил, но постоянно друг к другу ходили, обсуждали всё, критиковали, делились хорошими практиками и т.п. "Золотые были времена"!
Я так обобщу эту мысль. Хорошо, когда в команде обсуждения, критика, обмен идеями, и в целом — коммуникация на высоте. А когда это всё заменяют паллиативом в виде бездушного CR, результат соответствующий.
Здравствуйте, Артём, Вы писали:
Аё>Миддл это примерно до 2 года опыта. В итоге мы получаем полностью готового помидора, под ключ Аё>Помидор это примерно до 3 года опыта. В итоге мы получаем полностью готового техлида, под ключ Аё>Техлид это примерно до 4 года опыта. В итоге мы получаем полностью готового директора разработки, под ключ Аё>Ну и т.д.
Я не понял, что вы хотели этим сказать.
Аё>Реально, если отбросить фальшивые "синьёр" приставки, распределение такое: Аё>0-5 лет — джун. Может получать лычки "синьёр, но границы ответственности и уровень зп- джун
Джун и 5 лет опыта? Вы давно на линкедин ходили?
Аё>5-9 лет — миддл. Не нужен присмотр за ним, но он ещё не может присматривать за другими
Это какой то запущеный случай, когда 5-9 лет опыта и не научился присматривать за другими. Обычно такой скил уверенно демонстрируют примерно к 4м годам опыта, а у вас это джун
Аё>9+ лет- синьёр. Ветеран индустрии, к его мнению начинают прислушиваться. Мидлы обращаются за советом в трудной ситуации. Присматривает за другими, ревьювит код и т.п.
Линкедин с вами не согласен. Поискал, для интересу, требования к Principal Developer, по годам получается около 8 лет суммарного опыта разработчиком. При этом Principal Developer уже относится к менеджменту, а не линейным разработчикам.
Здравствуйте, Артём, Вы писали:
A>>Чел может быть сеньором в одной и джуном в другой, неужели к тебе на интервью такие не приходили?
Аё>Ко мне приходил кандидат, по резюме- техлид до переезда в Австралию. Я его подло завалил на развороте строки
Терминология в индустрии еще не устаканилась. Техлид это может быть менеджер, а может быть и сеньор+. Можно спрашивать про обязанности конкретного кандидата, это сэкономит время и вам и ему. По обязанностями будет видно, что к чему.
Здравствуйте, Alekzander, Вы писали:
A>Аналогичный опыт, мы с коллегой работали парой над одним продуктом, каждый у себя больше времени проводил, но постоянно друг к другу ходили, обсуждали всё, критиковали, делились хорошими практиками и т.п. "Золотые были времена"! A>Я так обобщу эту мысль. Хорошо, когда в команде обсуждения, критика, обмен идеями, и в целом — коммуникация на высоте. А когда это всё заменяют паллиативом в виде бездушного CR, результат соответствующий.
Как я вижу, идет тренд примерно такой — системы становятся больше, а приложения — меньше. Потому, даже находясь в одном стеке, разработчки отдаляются друг от друга, зоны ответсвенности пересекаются слабовато.
Удаленная работа, распределенные команды только усиливают этот эффект.
Потому код-ревью компенсирует нехватку совместной работы над конкретной частью. При этом код-ревью одних только пул-реквестов обычно слишком мало, нужно чтото кроме этого. Например, отдельно согласовать дизайн решения, а дальше уже каждый сам.
Здравствуйте, Философ, Вы писали:
Ф>Я при ревью спотыкаюсь об вопросы типа, решает ли код подставленную задачу и решает ли он её полностью.
Вообще говоря, это — задача тестировщика (и ответственность автора кода).
Ф>Во-вторых, я спотыкаюсь о то, что я раньше аппрувил задачи с косяками. Такой опыт заставляет немного нервничать, когда курсор зависает над кнопкой Approve.
И это — тоже задача тестировщика (и ответственность автора кода).
Ф>Как у вас с этим дело обстоит?
Ваша задача проверить:
1. Адекватно ли выбрана архитектура решения? (не говнокод и не овердизайн)
2. Удачные ли подобраны имена объектов и сигнатуры функций?
3. Есть ли явные косяки?
4. Есть ли скрытые косяки? (типа undefined behaviour или висячих ссылок)
И всё. Такой подход помогает поддерживать высокое качество кода и не слишком загружает ревьюера.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, Pauel, Вы писали:
P>Это какой то запущеный случай, когда 5-9 лет опыта и не научился присматривать за другими. Обычно такой скил уверенно демонстрируют примерно к 4м годам опыта, а у вас это джун
Сильно зависит от места работы и проектов, если повезло попасть на реальные проекты с сильными разрабами, то джун за пару-тройку лет станет крепким мидлом, а лет за 6 — вполне и сениором.
Также от страны зависит, в России с ее сильной нехваткой разрабов сениорские должности получают и с 5 годами опыта, просто потому что других нет
А в среднем по больнице сеньорами становятся лет через 10. Именно с этого времени у них просветляется голова, начинают дизайнить и писать правильный код, получают навыки работы в коллективе, в стрессовых ситуациях, принимать компромиссные решения и тд
Здравствуйте, Артём, Вы писали:
Аё>Ко мне приходил кандидат, по резюме- техлид до переезда в Австралию. Я его подло завалил на развороте строки
Подобных "интервьюверов" надо в шею гнать из компании за растрату рабочего времени и ресурсов компании на чесание своего чвс
Здравствуйте, Nnova, Вы писали:
N>А в среднем по больнице сеньорами становятся лет через 10. Именно с этого времени у них просветляется голова, начинают дизайнить и писать правильный код, получают навыки работы в коллективе, в стрессовых ситуациях, принимать компромиссные решения и тд
Непохоже, если честно. Линкедин, сайты по рекрутингу — ничего такого не видел.
Здравствуйте, Философ, Вы писали:
Ф>Во-первых, мне тяжело что-либо ревьюить код, если я не вник в суть задачи.
Описание задачи и testing plan должно быть в описании PR с ссылками, для этого делают обычно авто-шаблон для PR.
Если у вас принято вникать, то, соответственно, смотри чтобы ревьюил тот, кому это ближе, а не ты. Так-то, по идее, хотя бы 2 человека должны быть в курсе любой задачи.
Ф> Я при ревью спотыкаюсь об вопросы типа, решает ли код подставленную задачу и решает ли он её полностью.
Это хороший подход имхо. Попробуй мб просмотреть тест план, задать вопрос предусмотрена ли обработка corner case (перечислить), переложив ответственность и доказательство на автора за это. В крайнем случаи запросить input/output теста.
Ф> Т.е. мне прежде чем ревьюить нужно сначала прочитать задачу, её предысторию (связанные обсуждения) и только потом я могу приступать к коду. Для меня это настоящая работа.
Ф>Во-вторых, я спотыкаюсь о то, что я раньше аппрувил задачи с косяками. Такой опыт заставляет немного нервничать, когда курсор зависает над кнопкой Approve.
Всем пофиг.
Проси чтобы после тебя кто-то еще более осведомленный просмотрел.
Ф>Как у вас с этим дело обстоит?
1) хорошо когда есть feature switch (у нас он обязателен, когда это возможно), тогда часто можно ограничиться тем, что весь код находится под ним и в случае бага это откатывается переключением switch-а
2) дальше если задачу делает другой сеньор можно переживать по-меньше и делать формально, если, например, пишет задачу твой студент и цена ошибки велика, тут или при PR или при тестировании придется попотеть, альтернативно лучше сразу планировать что студент первую версию сам сделает бажную и вложить время для правок
3) дальше просто ограниваешь себя по количеству комментов и времени, например, человек пишет на python не очень, пусть учится, но и не за 1 PR, а постепенно, чтобы не угас огонь в глазах, соотвественно переходишь от более критичных комментов к менее
Другой подход — сесть с человеком и просить ему все рассказать, задавая вопросы. Это помогает, когда ну вообще не хочется въезжать в проблему самому, да и в целом довольно здоровая практика, ускоряющая процесс.
