Здравствуйте, 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, а постепенно, чтобы не угас огонь в глазах, соотвественно переходишь от более критичных комментов к менее
Другой подход — сесть с человеком и просить ему все рассказать, задавая вопросы. Это помогает, когда ну вообще не хочется въезжать в проблему самому, да и в целом довольно здоровая практика, ускоряющая процесс.
