Вхід і реєстрація
Про роботу · 22 січня 2018, 15:16 8157
Chaz Ashley

Скільки часу дають новачку на вивчення проекту?

Цікавить тема, як відносяться до новачків/джунів в різних компаніях, коли той новачок починає працювати над немаленьким проектом.

Скажімо, був деякий проект, над ним працювала людина і наробила вже купу всього, після чого на цей проект саджають іншу людину, котра бачить то все вперше в житті. Досвіду роботи з подібними проектами не має.

Судячи з вашого досвіду, який найменший, середній, та найдовший термін дається новачку на вивчення проекту, після котрого від нього починають вимагати продуктивної роботи?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Denys Poltorak 22.01.2018 17:34

Залежить. 1-2 дні на поставити софт, зареєструватись в системі. По тому можуть давати якісь маленькі баги фіксити. Поки фіксиш — потроху розбираєшся в проекті.
Це якщо окрім тебе ще хтось на ньому є. Якщо усі розбіглися, ніхто не знає, як воно працює, і тут тобі кажуть «розбирайся» — треба робити ноги, бо коли всі розбіглися — то вони розбіглися не марно, щось в конторі чи на проекті дуже недобре. Зазвичай це недобре вилізе протягом пів-року.
Якщо прожив на проеті пів-року — вважається, що можеш ефективно працювати в тій частині проекта, з якою маєш повсякденну активність.

Перейти до дискусії
Artem Bondarenko 22.01.2018 21:06

Остаток первого дня который остался после всякой бюрократии: подписать ДНА, кучу других бамажек и выдать весло. После этого показать с чем работать придется, и отправить домой плакать.

Перейти до дискусії
Sеrgejs Bоrуsson 23.01.2018 14:14

y = c*f(a, b), где
a — опыт девелопера
b — размер и длительность существующего проекта
c — коэффициент горящих жоп и клюющих петухов на проекте

Перейти до дискусії
Ctrl + Enter
Ctrl + Enter
Ivan Pruchai FullStack YOLO Engineer 03.02.2018 13:33

Все як завжди індивідуально, від компанії, проекту, кількості людей і так далі. Як на мене то куча нюансів. Спочатку звісно дадуть якийсь час щоб поставити собі весь необхідний софт, підготувати свою робочу машину, а потім в бій на якісь прості таски (багфікс і тп) і як бачуть що все путьом — рівень тяжкості буде виростати.

Відповісти
Підтримати
Anton Khristiansen 23.01.2018 20:58

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

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

Відповісти
Підтримати
Dmytro Shakhov CEO, Founder в Pravdalist.ai 23.01.2018 14:23

Это сильно зависит от проекта и точности постановки задач. Я например работал на проекте где ни один не знал все полностью на столько он был большим. При этом исправление каждого бага превращалось в инвестигейшин того как оно работает, как должно работать, в чем баг, как его исправить, починить баг за неделю было нормой.

Відповісти
Підтримати
Andrii Shchurkov Senior Software Engineer 23.01.2018 15:23

Мы все на нём работали, брат! *Пускает скупую слезу*

Відповісти
Підтримати
Dmytro Shakhov
Sеrgejs Bоrуsson Senior Tractorist 23.01.2018 14:14

y = c*f(a, b), где
a — опыт девелопера
b — размер и длительность существующего проекта
c — коэффициент горящих жоп и клюющих петухов на проекте

Відповісти
Підтримати
Anton Melnyk Software Engineer в Printify 23.01.2018 14:12

Дали задание поправить две строчки по мелочи. Но для этого нужно было у себя локально развернуть систему, разобраться в свалке контроллеров и моделей, найти нужную строчку, разобраться как идет работа с гитом, ветками, разобраться с бд... в итоге на 2 строчки во вьюхе ушло полтора дня пота. Зато потом когда в целом рамки работы и общая система проекта понятны, то уже проще и понемногу в течении первых недель давали мелкие задания по верстке. А через месяц уже сам добавлял новые страницы и функционал. А через полгода собственно был главный ответственный по фронту.

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

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

Відповісти
Підтримати
Oleksii Samokhvalov Працює в Business Class 23.01.2018 13:30

Бывает случаи, что чуть ли не сразу задачки маленькие могут давать.Заодно и в проекте начнешь осваиваться. Распространенная практика — садить новичка тестами покрывать сразу.

Відповісти
Підтримати
Vadim Kopanev Architect 23.01.2018 14:01
Распространенная практика — садить новичка тестами покрывать сразу

это крайне сомнительная практика

Відповісти
Підтримати
Oleksii Samokhvalov
Іван Довгай PHP Developer 23.01.2018 13:16

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

Відповісти
Підтримати
Dmytro Koshevets Frontend developer в Infopulse 23.01.2018 13:09

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

Відповісти
Підтримати
flyman 23.01.2018 12:58

консультанту: до двох тижнів, работніку на ставці — до 3х місяців (залежності от сложності праекту), в особо унилому інтерпрайзі i за 3 года можна оставаться в нєвєдініі WAT GOING ON

Відповісти
Підтримати
Vadym Senior Java Software Engineer в Sony 23.01.2018 14:15

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

Відповісти
Підтримати
flyman
flyman 23.01.2018 14:35

Коментар порушує правила спільноти і видалений модераторами.

Nikita Lovygin Senior Salesforce Commerce Cloud Developer в Toptal 23.01.2018 12:44

Сколько нужно времени? От проекта зависит и от команды. Опять же, изучение проекта может быть поверхностным или углублённым, с пониманием всех процесов и откуда какие ноги растут. На это может уйти и год и два.
Идеальный вариант для новичка — это когда тебе дают задачу и сразу solution approach, тогда ты уже знаешь, куда копать и какие части проекта тебе сейчас нужно будет проковырять.
И код ревью — тогда можно не так сильно напрягаться из-за того, что что-то мог на заметить и поломать. Зная, что есть команда поддержки, работается легче :)

В моём случае заход на каждый проект длился от 0 до 2 дней. Но начиналось всё с маленьких багов, потом побольше, потом уже фичи. Архитектура каждого проекта примерно одна и та же, но есть существенные различия в имплементации и куча местных лайфхаков, на них уходит очень много времени, но сталкиваешься с ними уже по ходу работы.
Это на галерах.

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

Відповісти
Підтримати
Oleg Kariakin Senior Java Developer 23.01.2018 12:02

Ты сразу у менеджера спроси об этом и не давай ему съезжать с этого вопроса, пока не услышишь конкретный ответ. Потом уже проси себе ментора, пояснений от BA и тд, т.к. это не твоя прихоть, а уже требования менеджера.

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

Відповісти
Підтримати
Ювженко Денис System Architect в Intellias 23.01.2018 11:40

В ідеальних умовах, коли є тімлід, документація, проект побудований з використанням найкращих архітектурних практик, то це до місяця часу.
Якщо на проекті більше нікого нема, то це мінімум два місяці з моменту скачування проекту і до подання на код-рев"ю більш-менш адекватного рішення по конкретному багу чи фічі.
Якщо ви підозрюєте, що в проекті відсутня адекватна архітектура і все на костилях, то це три місяці.
Якщо нема з ким радитись, нема документації, нема продукт овнера або замовника з яким можна узгодити вимоги і бізнес-логіку, то це чотири місяці.
За озвучений період, людина мала б продебагати більшу частину проекту, подивитись що як і за чим, було б добре, аби покрила юніт-тестами код(де це можливо), можливо, навіть чисто для себе, створила якусь сиру документацію, підтягнути до необхідного рівня всі використовувані технології.
Звісно, озвучений вище підхід має сенс, якщо вам необхідно будувати якісний продукт і ви хочете, що б працівник почувався ± комфортно, якщо ж треба на вчора, а реалізація підійде на "від"їбись", то тут і тижня вистачить, що б починати щось костилями підпирати.

Відповісти
Підтримати
chronoman 23.01.2018 11:02

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

Відповісти
Підтримати
Oleg Kariakin Senior Java Developer 23.01.2018 11:54
Ну а если ты гей, то тебя вообще не уволят, а в самом худшем случае переведут в другой отдел компании.

в гомо-отдел большого Эла-Гомосека ?

Відповісти
Підтримати
chronoman
chronoman 23.01.2018 11:57

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

Відповісти
Підтримати
Oleg Kariakin
Andrii Shchurkov Senior Software Engineer 23.01.2018 15:18

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

Відповісти
Підтримати
chronoman
chronoman 23.01.2018 15:32

развлекайтесь, тут попытались собрать самые сливки, потом можно зайти на сайт компании из списка и найти там планы на пятилетку вперед, до какой цифры надо добить процент сотрудников по каждому минорити...
www.businessinsider.com/...​ernational=true&r=US&IR=T

Відповісти
Підтримати
Andrii Shchurkov
Andrii Shchurkov Senior Software Engineer 23.01.2018 15:44

Окей, я думал, вы говорите про политику в голландских компаниях. Если worldwide, то пофиг.

Відповісти
Підтримати
chronoman
chronoman 23.01.2018 15:59

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

Відповісти
Підтримати
Andrii Shchurkov
Vitaliy Fedoriv Java Developer 23.01.2018 16:15

Це ж давно почалось, і не тільки в IT.
Навіть рейтинги всякі складають. От, Workplace Equality Index
www.stonewall.org.uk/workplace-equality-index
MI5 на 5 місці, Карл !

Відповісти
Підтримати
chronoman
chronoman 23.01.2018 16:21

фух порадовали коллеги пожарники из нотингема :), они на почетном 99м месте :), а за МИ5, ну да и бог с ними

Відповісти
Підтримати
Vitaliy Fedoriv
Alex Koshterek погромизд 23.01.2018 12:01

Могут просто не продлить контракт

Відповісти
Підтримати
chronoman
chronoman 23.01.2018 12:03

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

Відповісти
Підтримати
Alex Koshterek
Vitaliy Fedoriv Java Developer 23.01.2018 12:31

то просто був не гей-френдлі код :)))

Відповісти
Підтримати
chronoman
Alex Koshterek погромизд 23.01.2018 10:50

от 0 до 3х месяцев

Відповісти
Підтримати
Формошлеп 22.01.2018 23:42

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

Відповісти
Підтримати
Кодерок 22.01.2018 22:46

От компании и вида трудоустройства зависит.
Скажем, в западном концерне, да для постоянного работника — никаких особых ожиданий нет, т.к. всё равно уволить невозможно.
От контракторов, как правило — хотят чтобы въехал в тему и начал контрибьютить полезное, уже «вчера».

Відповісти
Підтримати
Grez 22.01.2018 22:17
над немаленьким проектом.

Степени немаленькости могут сильно отличаться. Можно годами вникать.

після котрого від нього починають вимагати продуктивної роботи?

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

Відповісти
Підтримати
Artem Bondarenko Embedded enginner (HW/FW/SW) в Looking for relocation. 22.01.2018 21:06

Остаток первого дня который остался после всякой бюрократии: подписать ДНА, кучу других бамажек и выдать весло. После этого показать с чем работать придется, и отправить домой плакать.

Відповісти
Підтримати
Mikhail Boiko SE 22.01.2018 20:07

Около 6 месяцев. В моей практике обычно первый месяц «читаешь», потом дают небольшие дефекты. В течении года вникаешь в проект и начинаешь делать что-то полезное.

Відповісти
Підтримати
anonymus ps 22.01.2018 20:23

Сразу видно классический ентерпрайз

Відповісти
Підтримати
Mikhail Boiko
Oleg Kariakin Senior Java Developer 23.01.2018 11:58

первые два месяца только подымаешь проект )))

Відповісти
Підтримати
anonymous
Grez 24.01.2018 05:38

Вы смеетесь, а чет хочеться плакать...

Відповісти
Підтримати
Oleg Kariakin
Grez 24.01.2018 05:41

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

Если что — риал стори, как бы печально эт не звучало.

Відповісти
Підтримати
Oleg Kariakin
Vitaliy Fedoriv Java Developer 24.01.2018 09:55

підсумуючи :)
— Как у него прошел испытательный срок?
— Все нормально, компьютер выдали, доступ к проекту дали, пытается поднять.

Відповісти
Підтримати
Grez
Oleg Kariakin Senior Java Developer 24.01.2018 13:03

Та я в курсе или месяц vpn ждать )))

Відповісти
Підтримати
Grez
Oleh Koval 23.01.2018 12:38

При этом надо не расслабляться и заранее искать новую работу для перехода на +$500.

Відповісти
Підтримати
Mikhail Boiko
Николай Ник 22.01.2018 19:35

Месяц иначе пинка дадут. Если терпеливый работодатель то три месяца максимум.

Відповісти
Підтримати
Bob Dilan 22.01.2018 20:17

это какие то нано проекты раз их можно выучить

Відповісти
Підтримати
anonymous
Bob Dilan 22.01.2018 20:21

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

Відповісти
Підтримати
anonymous
Oleg Shastitko 22.01.2018 21:07

SOLID архитектура спасёт (в большинстве случаев) отца русской демократии проект от таких нежданчиков

Відповісти
Підтримати
anonymous
Oleg Shastitko 22.01.2018 21:29
не на большом масштабе, к сожалению)

Моя практика говорит, что дело если и в масштабе, то он не столь уж и значительно влияет на хрупкость. Хотя соглашусь, что даже следование SOLID — не панацея. Всё равно где-то что-то можно зацепить

Відповісти
Підтримати
anonymous
Vitalii Maklai Senior Backend Developer в Nowsite 28.01.2018 22:29

На большом масштабе нужно что-то SOLIDнее, чем SOLID...

Відповісти
Підтримати
anonymous
Alex Fogol Software Developer, C/C++ Expert 23.01.2018 13:23

И другие страшные слова но реальность тут в том самом малом нюансе даже прямо тут и озвученном в оговорке

(в большинстве случаев)

— как говорится «а осадочек-то остался» (к) (тм)

Відповісти
Підтримати
Oleg Shastitko
Oleg Shastitko 23.01.2018 22:30
— как говорится «а осадочек-то остался» (к) (тм)

да, с оговоркой, но это именно небольшая оговорка, т.к. реальность на самом деле такова, что если проект (большой, маленький, неважно) легко ломается джуном (да и не джуном тоже), то у него плохо реализована архитектура. Если для внесения фичи легче написать в обход архитектуры или совсем в другом подходе — то у него также плохо реализована архитектура. И мой 15+ летний опыт разработки коммерческих проектов говорит о том, что хоть SOLID не панацея и всё равно можно что-то поломать, в целом следование его принципам + покрытие тестами даёт довольно хорошую гарантию стабильности системы и устойчивости к поломкам.

Відповісти
Підтримати
Alex Fogol
Alex Fogol Software Developer, C/C++ Expert 23.01.2018 22:43
если проект легко ломается то у него плохо реализована архитектура

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

ЗЫ: даже более того первая часть цитаты также работает «а все счастливые счастливы одинаково» (к) (тм)

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

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

Но в целом да я признаю что в условно идеальной либо достаточно приближённой системе будет так пусть даже гарантия скажем .99 ну может 0.98 )) но лично я таких систем не видел кроме вычислительных центров в которых всё это реализуется конкретно целенаправленно отдельно за деньги и на уровне вполне объяснимых операционных и орг. процедур вроде дублирования / резервирования.

Можно например брать те же ж методы и «условных джунов условно дублировать» ))

Відповісти
Підтримати
Oleg Shastitko
Oleg Shastitko 23.01.2018 23:01
Ну из своего опыта я бы б уточнил этот момент как «даёт достаточно проверенный инструмент как процесс» и возвращаясь к нашим джунам обратно таки если введение джунов в суть дела поставлено как процесс оно работает

Ну даже если и не поставлено, то всё равно, если у нас скажем нет прямого доступа к БД из проекта, а только через абстракции, то он через абстракции. И если мы джуну не даём возможности добавлять прямые референсы на другие проекты, то он никак не сможет наговнокодить, добавив прямое обращение к БД. Если джун что-то легко сломал — то виноват, прежде всего не джун, а архитектор и ещё ряд людей :)

А так да, редко попадается проект с нормальной реализацией. Чаще скорее даже говоришь заказчику, что всё криво, а он ещё и обижается

Відповісти
Підтримати
Alex Fogol
Alex Fogol Software Developer, C/C++ Expert 23.01.2018 23:15
то он никак не сможет наговнокодить

Может. Ну вот например «через абстракции» а они у нас внезапно все рукописные и чтобы просто чтобы что-то пофиксить или тем более добавить а уж тем более удалить надо сделать кучу телодвижений в тех самых +50 разных файлов ну мы как бы вообще-то собирались написать на всё это генератор и даже был чувак который начал было но теперь он не с нами...

Если джун что-то легко сломал — то виноват

Да не вопрос же ж в том чтобы джун сломал...

Пусть будет вопрос в том что на самом деле весь этот проект на самом деле делался непрерывным потоком джунов приходящих на 3-4 месяца и соотв. внутре там «вот это всё».

а он ещё и обижается

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

Відповісти
Підтримати
Oleg Shastitko
Oleg Shastitko 24.01.2018 00:44
Может. Ну вот например «через абстракции» а они у нас внезапно все рукописные и чтобы просто чтобы что-то пофиксить или тем более добавить а уж тем более удалить надо сделать кучу телодвижений в тех самых +50 разных файлов

уже значит что-то не так в архитектуре, если нужно сделать изменения в +50 разных файлах :)

Пусть будет вопрос в том что на самом деле весь этот проект на самом деле делался непрерывным потоком джунов приходящих на 3-4 месяца и соотв. внутре там «вот это всё».

ну дык, поздно пить боржоми

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

а из классики : «у нас всё феншуй, обхаять может каждый, зря я вообще с вами связался, раз хаете чудесный код, написанный Акаршом и Мурали за доллар в час»

Відповісти
Підтримати
Alex Fogol
Alex Fogol Software Developer, C/C++ Expert 24.01.2018 01:39
а из классики : «у нас всё феншуй, обхаять может каждый, зря я вообще с вами связался, раз хаете чудесный код, написанный Акаршом и Мурали за доллар в час»

Да нет же ж фокус не в коде фокус в конкретной баге конкретно воспроизводимой т.е. тупо во внешнем проявлении ну ок ))

Відповісти
Підтримати
Oleg Shastitko
Platan 24.01.2018 08:54
уже значит что-то не так в архитектуре, если нужно сделать изменения в +50 разных файлах :)

Именно так. Что-то не так в архитектуре.
И что глубокоуважаемый человек предложит в этом случае разработчикам, которые работают последние 3 месяца (3 года) на проекте, которому 30 лет?
Свалить с проекта на −1500$ с фразой «Я с говном не работаю»?
Или поменять сферу деятельности и пойти вышивать крестиком, что-бы никогда в жизни больше не видеть плозой архитектуры?

Відповісти
Підтримати
Oleg Shastitko
Denys Poltorak Embedded | C++ (opentowork) 24.01.2018 12:39

А откуда вообще взялись +1500 на этом проекте?

Відповісти
Підтримати
Platan
Platan 24.01.2018 15:58

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

Відповісти
Підтримати
Denys Poltorak
Denys Poltorak Embedded | C++ (opentowork) 24.01.2018 15:59

А при чем клиент к зарплате программиста?

Відповісти
Підтримати
Platan
Platan 24.01.2018 16:01

Исправил ошибку в прошлом сообщении. Хотя клиент отношение таки имеет. Если программисты уйдут и новые фичи, интеграции с новыми системами не будут допиливатся — клиент с большей вероятностью в близжайшие несколько лет перейдет к другому поставщику...

Відповісти
Підтримати
Denys Poltorak
Denys Poltorak Embedded | C++ (opentowork) 24.01.2018 16:02

Думаю, за 5500 много кто согласится сидеть пить чай на старом проекте

Відповісти
Підтримати
Platan
Denys Poltorak Embedded | C++ (opentowork) 05.02.2018 13:51

Там у чувака все время все уходят с понижением на 1500. Вот я и прикинул, сколько это должно было быть. Его и спрашивай, где такой проект есть.

Відповісти
Підтримати
flyman
Platan 05.02.2018 14:18

Ну, в моем мире 27-летних мидлов больше чем 3к в других местах никто не предлагал.

Потому да. Уходил на −1500.

Відповісти
Підтримати
Denys Poltorak
anonymus ps 23.01.2018 12:05

это понятно, но код ревью должно предотвращать от того что изменения расыпят всю систему + есть такая штука как тестирования

Відповісти
Підтримати
anonymous
Oleg Kariakin Senior Java Developer 23.01.2018 12:18

Не особо решает, когда 10-20-50 измененных файлов (половина — тесты) люди уже особо не вчитываются в каждую строчку, а поверхностно смотрят — нет ли какашек в коде. Или как в индусских проектах — подлез он своим if-чиком в твой метод — и как понять ломается теперь фича или нет?

Відповісти
Підтримати
anonymus ps
anonymus ps 23.01.2018 12:21

если нет сеньоров на проекте — то именно так и будет.

Відповісти
Підтримати
Oleg Kariakin
Oleg Kariakin Senior Java Developer 23.01.2018 12:25

Не понял, чем сеньйор/ы помогут тут ?

Відповісти
Підтримати
anonymus ps
anonymus ps 23.01.2018 13:01

а что за проблема проревьювить 50 файлов?

Відповісти
Підтримати
Oleg Kariakin
Alex Fogol Software Developer, C/C++ Expert 23.01.2018 13:25

Видимо в том что при «среднем джуне» ревью 50 файлов поглотит чуть более 100% времени синьора это без учёта возможности джунов нескольких.

ЗЫ: плюс некоторые копроративные особенности самого процесса и подходов к и целей его ))

Відповісти
Підтримати
anonymus ps
anonymus ps 23.01.2018 13:43

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

Відповісти
Підтримати
Alex Fogol
Vitaliy Fedoriv Java Developer 23.01.2018 13:48

:) дедушки дали духу портянки стирать

Відповісти
Підтримати
anonymus ps
Alex Fogol Software Developer, C/C++ Expert 23.01.2018 13:58

)) а оно было небольшое там меняется в одном файлике который лежит в 46-й папке слева и легко гуглится по всему коду что все обычно и делают когда нужно поменять просто все про это знают и особо не задумываются над «обобщённым заданием» а то что это всё проявляется в тех 50 файлах ну да такая «бага кода» есть надо бы б пофиксить но на самом деле всё правится в том только одном файле так бывает ))

Ну да утрировано основано на реальных событиях но не суть.

Суть что код ревью на самом деле мало что решает и всегда «возможны варианты».

Но таки да достаточно большой во временном протяжении проект и достаточно большая для массового подхода к джунам должна иметь чисто технические уже заранее поставленные процессы «вхождения джунов» вплоть до чек-листа что нужно сделать по пунктам и описания неподсредственно в доках (актуальных ага ага) как именно это нужно сделать по пунктам включая пул задач опять же ж таки с конкретным описанием по пунктам что это где это и более common зачем это со ссылками на доки (актуальные ага ага) по которым джун либо кто-либо другой может сходу начать «входить прямо не угадывая».

Но в реальности таки да маемо тэ що маемо (к) (тм) я проверял ))

Відповісти
Підтримати
anonymus ps
Denys Poltorak Embedded | C++ (opentowork) 23.01.2018 14:01

В реальности должен быть лид или синьор, который дважды в день будет подходить и спрашивать «как дела»

Відповісти
Підтримати
Alex Fogol
Alex Fogol Software Developer, C/C++ Expert 23.01.2018 14:07
подходить и спрашивать «как дела»

Вот-вот а зачем? Есть же ж код есть же ж современный процесс есть же ж сеть есть же ж гит пусть будет свн или там даже перфорс это же ж не конец 70-х большая ЭВМ перфокарты и необходимость самому сходить спрашивать в конце коридора потому что ничего ещё нет будет через 40 лет.

ЗЫ: вот скажем классика ну да ответ на «как дела?» есть но по факту финальный коммит прилетает с комментарием на страницу машинописного текста «ничосси вотзэфак» но потом всё равно оказывается «что это нормально» джун реально пишет такие коментарии (его взяли за хороший английский ага литературный) которые ну вот честно отдельно надо «компилировать» продираясь через глаголы и сложносочинённые времена и редкоземельные существительные и прочие части речи с тем чтобы понять об чём вообще речь и что конкретно в этом коммите. Получается «как дела?» «всё норм вопросов нет» «а ну ок» «вот результат» «ой...ля...» (к) (тм)

Відповісти
Підтримати
Denys Poltorak
Denys Poltorak Embedded | C++ (opentowork) 23.01.2018 12:26

Это джуну дали фичу, которая в 50 файлах делает нетривиальные изменения?

Відповісти
Підтримати
Oleg Kariakin
Platan 23.01.2018 12:29

Ты думаешь поменять цвет в конкретном текст-инпуте это такая простая задача на проекте, которому 30 лет?

Відповісти
Підтримати
Denys Poltorak
Denys Poltorak Embedded | C++ (opentowork) 23.01.2018 12:32

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

Відповісти
Підтримати
Platan
Platan 23.01.2018 13:21

А если дали задачу миниор девелоперу опытом работы 10 лет?
И он на протяжении 1,5 месяцев сидит с дебагером и яростью в взгляде, и пытается понять, как сделать «Мелкую фишку».
И остальные люди на проекте знают про этот модуль не больше. А последнего человека, который был знаком с этим модулем недавно переманили на −1500$ в другую контору?

Відповісти
Підтримати
Denys Poltorak
Denys Poltorak Embedded | C++ (opentowork) 23.01.2018 13:53

1) Если с сотрудниками плохие отношения, они сваливают и не отвечают на вопросы — проблема менеджмента. В таком случае лучше самому последовать их примеру.
2) Новичок становится новым овнером модуля, и теперь менеджмент должен решать, удовлетворены ли они новым овнером. Но я бы посоветовал свалить от такого начальства, пока оно не взяло инициативу на себя.

Відповісти
Підтримати
Platan
Platan 23.01.2018 13:58
В таком случае лучше самому последовать их примеру.

И тоже уйти на с −1500$.
В принципе разумно. Но квартира на печерске саму себя не купит. (Шутка)

пока оно не взяло инициативу на себя

И не свалило первым?)

Відповісти
Підтримати
Denys Poltorak
chronoman 23.01.2018 13:54

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

Відповісти
Підтримати
Platan
Denys Poltorak Embedded | C++ (opentowork) 23.01.2018 13:59

Не знаю как там у пожарников, а в эмбедеде перебирать сотрудниками не приходится.

Відповісти
Підтримати
chronoman
chronoman 23.01.2018 14:01

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

Відповісти
Підтримати
Denys Poltorak
flyman 23.01.2018 14:42

дати шо?
Бондаренко уже с веслом на галєрє?

Відповісти
Підтримати
Denys Poltorak
flyman 05.02.2018 13:31

пише що вже має весло і гребе в морі авна

Відповісти
Підтримати
anonymous
Platan 23.01.2018 14:03

Это работает в нормальных условиях.
А если человек реально работает и ищет проблему? И все его затыки абсолютно адекватны. Технарь адекватный. В проекте — жопа.
Проект — 1 гиг исходников. Больше 60 тысяч ревижнов в СВН-е.
(Это при том что свн-ом начали пользоватся через 15 лет после старта проекта).
Больше 300 юзеров в свн-е.
10 фултайм разработчиков на проекте.

Відповісти
Підтримати
chronoman
chronoman 23.01.2018 14:10

Не надо меня пугать вот только хаха исходниками или прочими размерами. Если у вас в проекте бесконечное число зависимостей, то значит у вас плохая архитектура. Адекватные люди приходят в проекте на 100+ активных коммитеров и начинают решать реальные технические задачи. Если человек адекватно (эффективно) в поисках решения затыка, или ознакомления с проектом, то наблюдение за процессом фикса несколько минут в день хватит, более того если человек стесняется задавать вопросы, то наблюдение подскажет какие дать рекомендации чтобы увеличить эффективность. Если человек в 100500 раз говорит одно и тоже «результат в процессе», «работаю», то как бы это ни о чем. Слон должен быть нарезан тонко и подаваться горяченьким.

Відповісти
Підтримати
Platan
Denys Poltorak Embedded | C++ (opentowork) 23.01.2018 14:12
наблюдение за процессом фикса несколько минут в день хватит

Особенно когда он ловит нестабильный креш, про который все знают, но боятся связываться)

Відповісти
Підтримати
chronoman
chronoman 23.01.2018 14:17

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

Відповісти
Підтримати
Denys Poltorak
Denys Poltorak Embedded | C++ (opentowork) 23.01.2018 14:23

Да, но с такими штуками можно несколько месяцев возиться. И что ты увидишь за 2 минуты наблюдения процесса?

Відповісти
Підтримати
chronoman
chronoman 23.01.2018 14:42

ты реально считаешь, что я не увижу за 2мин процесса в день поиска креша, как человек его ищет, что проверяет, я увижу, поверь, и пойму человек как дебил бьется в одну точку каждый день головой об стенку, или обследует системно раз за разом, я пойму это дон кихот скачущий на мельницы, или это человек рыбачок, который ловко закидывает удочку, увеличивает планомерно шанс креша и таки решает задачу. А почему ты решил что этим можно возиться несколько месяцев, а не там несколько лет, ну или вообще бесконечность. Ведь можно же и так, и оставить человека, пусть копается себе бесконечность. Нет уж. Ну и так, чтобы уже наверняка. Я не дам новичку разбираться со старым крешом, которого все боятся, все о нем уже знают куй знает скока и сторонятся. Новичок, пусть даже и сеньер-лид, получит нормальный таск, а вот если в результате этого задания полезет креш, вот с ним, со свеженьким, я его заставлю разобраться. И это далеко не месяца работы. Ну как пример, давно это было, пришел я к трактористам работать, дали мне докуя железа, сборку линука на 3х железках, причем разнородные, и сказали что типа у них уже 2года дурная бага в их самописных линух дровах и коннект между платами не работает. Ниче, взял, поковырял дрова, через неделю был первый коммит с нуля, еще через две недели сделал финальный коммит с полным фиксом дров. Мои новые сотрудники не могли найти, потому что методом тыка фиксили, не помогало — откатывали назад, пробовали следущее. Я же нашел просто что фиксить надо было в 2 разных местах и все заработало. Плюс по ходу увидел что некоторые коллеги чего то в эмбеддед недопонимают, и ставят принты в теле прерываний... и из-за этого меняют поведение системы хехе. Кстати ребята были суперские, было интересно работать, и это чуть ли не единственные, кто проводил реальное техническое собеседование в Голландии. Помню пацан один молодой но очень опытный задал вопрос «представьте, перед вами квадратная шина, ну или там обычный юарт, и у вас там че то не работает как надо, опишите на словах поиск что будете делать, чтобы найти баг». Очень просто показывает кругозор. Человек видит лишь одну точку на стекле, или видит и дальше.

Відповісти
Підтримати
Denys Poltorak
Alex Fogol Software Developer, C/C++ Expert 24.01.2018 13:29
Если пофиксит — это приятный бонус.

Не получится.

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

Відповісти
Підтримати
anonymous
Denys Poltorak Embedded | C++ (opentowork) 24.01.2018 14:41

Не ну есть такие баги, которые тупо не ловятся нормальными средствами. Видел как чел пару месяцев посидел на таком и уволился.

Відповісти
Підтримати
Alex Fogol
Alex Fogol Software Developer, C/C++ Expert 24.01.2018 14:49

А зачем такие «начинающему» давать? В чём цель вообще брать кого-то нового? Какой-то план всего этого есть (был)?

Відповісти
Підтримати
Denys Poltorak
Denys Poltorak Embedded | C++ (opentowork) 24.01.2018 15:47

Думаю, нет)
Или, как в каком-то более раннем коменте, для новичка было только 2 задачи: сходить за чаем или сидеть искать багу

Відповісти
Підтримати
Alex Fogol
Alex Fogol Software Developer, C/C++ Expert 24.01.2018 17:57

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

Почти 146% это также показатель «странности во всём» начиная от кода и продолжая но не заканчивая странности с гитом и любой другой репой (а особенно когда их несколько плюс географическое распределение) странности с багобазой странности с таскобазой (которых в свою очередь бывает и несколько) странности с офисом )) ну это уже скорее обобщение офисы как раз чаще годные и кофе норм и сахар есть (ан нет вспомнил всё равно странности).

ЗЫ: из странностей офисов в каких бывал в одном на кухнях по крайней мере доступного мне этажа конкретного здания кампуса было заметное видимо неслучайное количество пакетиков сахара таких «общемировостандартных» стиков просто надломанных но видимо не употреблённых или может употреблённых наполовину? специально проверил по всем кофепоинтам по доступному периметру везде так. Загадочные души тёмные умы. ))

Відповісти
Підтримати
anonymous
flyman 05.02.2018 13:33
Ещё раз смотри тут какой ход конём если новичка сажают «постарайся пофиксить не ты один не справился» (к) (тм) то это лишь прямо означает что контора прямо не знает зачем она вообще новичка в данный конкретный момент брала

баг не пофіксить, зато проєкт покопає (це як про півня і курку: «не дожену, то хоть зігріюся»)

Відповісти
Підтримати
Alex Fogol
Platan 23.01.2018 14:15
Если у вас в проекте бесконечное число зависимостей, то значит у вас плохая архитектура.

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

Відповісти
Підтримати
chronoman
Vitaliy Fedoriv Java Developer 23.01.2018 14:33

хе-хе. Я так колись завдання одному новому «програмісту» ставив.
Вася, от тобі ТЗ: треба прогу, яка буде набирати на модемі номери телефонів зі списку, отримувати результат (відповідь/не відповідь), писати це в лог. От тобі список номерів, от коробка з модемом. Ти на чому пишеш, ? На С ? Ну хз, тут ніби пару бібліотек по роботі з модемом є, подивись, яка тобі підходить. Питання є ? Немає ? Ок, будуть -
звертайся; працюй.
І залишив його на два тижні без контролю (very big mistake).
Через два тижні заходжу:
— Вася, ну що там з прогою?
— Та от, розбираюся з бібліотекою...
— І щось вже написав ?
— Та от. (всього коду рядків двадцять — просто відкривається файл і з нього читаються номери телефонів. Все)
— ...
Погляд на модем, який лежить в коробці там, де я його два тижні назад залишив.
— Добре, Вася, не треба вже розбиратися...
Забрав модем і пишов писати сам. :)

Відповісти
Підтримати
chronoman
chronoman 23.01.2018 15:10

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

Відповісти
Підтримати
Vitaliy Fedoriv
flyman 24.01.2018 10:20

а надо було показать стальние яйки
короче, слабоподкований и неидейний,
с таким камунизмъ\капитализмъ не построишь

Відповісти
Підтримати
anonymous
Alex Fogol Software Developer, C/C++ Expert 23.01.2018 13:34

Всякое бывает вообще чисто теоретически с моей практической точки зрения в этом должна быть работа менеджера «следить и проводить личную беседу и выдавать пряники и круты» в соотв. с техническим регламентом прописанным «создай новую ветку и пушай в неё каждый день» при этом наблюдаемость процесса реализуется налицо включая прогресс по которому можно увидеть что пошло не так и в каком месте свернуло и на основании синьорского опыта хождения по граблям почему так случилось но это непопулярный (и не только у нас) метод руководства правильным считается смотреть все ли пришли в офис не ушли ли раньше и хорошо ли сидели и «делать контакт 1 на 1» периодически спрашивая «ты чем сейчас занимаешься?»

Відповісти
Підтримати
Denys Poltorak
Oleg Kariakin Senior Java Developer 23.01.2018 12:31

Типичный CRUD приделать на энтерпрайзе — минимум 20 файлов он тронет. Чуть сложнее — приделать валидатор, а он свой не захотел, решил сделать абстрактный класс, перенес туда существующие валидаторы в ту иерархию и поломал уже часть фич. Это такой детский пример. Если UI — то вообще жесть что может быть )))

Відповісти
Підтримати
Denys Poltorak
Denys Poltorak Embedded | C++ (opentowork) 23.01.2018 12:32
нетривиальные изменения
Відповісти
Підтримати
Oleg Kariakin
Oleg Kariakin Senior Java Developer 23.01.2018 12:35

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

Відповісти
Підтримати
Denys Poltorak
Vitaliy Fedoriv Java Developer 23.01.2018 12:39

емм... може спочатку дати щось «пофіксити», а не «приделать»? Без знання структури проекту і бізнес-логіки він тобі «наприделивает»...

Відповісти
Підтримати
Oleg Kariakin
Platan 23.01.2018 13:22

Пофиксить зачастую сложнее. В проектах которм 10+ лет, на которых работает 10+ постоянных девов — простых тасков на пофиксить обычно не остается.

Відповісти
Підтримати
Vitaliy Fedoriv
Vitaliy Fedoriv Java Developer 23.01.2018 14:01

(несерйозно): а навіщо на проект взяли джуна, якщо там немає простої роботи для нього ?
(напівсерйозно): «10+ постоянных девов» могли б прийти на допомогу і підкинути йому якусь нескладну роботу, а не записувати її собі на баланс.

Відповісти
Підтримати
Platan
Alex Fogol Software Developer, C/C++ Expert 23.01.2018 14:05
(напівсерйозно): «10+ постоянных девов» могли б прийти на допомогу і підкинути йому якусь нескладну роботу

а) обычно такой работы попросту нет (проще сделать самому)

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

ЗЫ: о можно кофеварку помыть давно собирались и ещё сходить в дальний угол квартала там отличный магазинчик с чаем мы были один раз потом всё руки не доходили...

Відповісти
Підтримати
Vitaliy Fedoriv
Denys Poltorak Embedded | C++ (opentowork) 23.01.2018 14:08

Вопрос зачем вообще джуна брали на такой стадии проекта

Відповісти
Підтримати
Alex Fogol
Alex Fogol Software Developer, C/C++ Expert 23.01.2018 14:12

Это хороший вопрос годный я проверил.

Какие есть гипотезы? )) Эмпирические данные? ))

Відповісти
Підтримати
Denys Poltorak
Denys Poltorak Embedded | C++ (opentowork) 23.01.2018 14:15

1) Сбить денег с заказчика
2) Чтобы чай носил (скучно стало, слишком мужской коллектив)
3) Кто-то собирается на пенсию / за бугор

Відповісти
Підтримати
Alex Fogol
Alex Fogol Software Developer, C/C++ Expert 23.01.2018 14:31
1) Сбить денег с заказчика

+10050 ты знал

Відповісти
Підтримати
Denys Poltorak
Platan 23.01.2018 14:12
(несерйозно): а навіщо на проект взяли джуна, якщо там немає простої роботи для нього ?

Если заменить слово джун на (Матерый синиор с 10 годами опыта на тех-же технологиях) — то что-то изменится?

Відповісти
Підтримати
Vitaliy Fedoriv
Denys Poltorak Embedded | C++ (opentowork) 23.01.2018 14:13

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

Відповісти
Підтримати
Platan
Platan 23.01.2018 14:20

Изначально дискус начался с оспаривания следующего высказывания:

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

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

Відповісти
Підтримати
Denys Poltorak
Denys Poltorak Embedded | C++ (opentowork) 23.01.2018 14:24

Обычно первая польза от мелких багов или фич будет в первые недели работы. А продолжать въезжать можно долго.

Відповісти
Підтримати
Platan
Alex Fogol Software Developer, C/C++ Expert 23.01.2018 13:28

Ну да )) ну неподумавши да это бывает там надо было вынести в один и подключить вот в этом месте и синьор как бы сам так и подумал но он подумал что как сам так и все это ведь логично все же ж думают но джун решил иначе и закодил всё напрямую во всех 50-ти файлах и к тому же ж очень горд объёмом проделанной работы и ведь вроде как и бить сильно не то в принципе ведь поставленную задачу он таки сделал ну да в будущем ад и Израиль (к) (тм) о кстати это как раз был израильский код хе-хе-хе ))

Відповісти
Підтримати
Denys Poltorak
Vitaliy Fedoriv Java Developer 23.01.2018 13:51

нормально: тепер можна джуна садити за рефакторинг :)

Відповісти
Підтримати
Alex Fogol
Alex Fogol Software Developer, C/C++ Expert 23.01.2018 14:02

Который на самом деле суть есть вещь бессмысленная потому как весь этот код полностью «формально устаревший» потому как основная система ушла на 3 версии вперёд и поставщик её уже не то чтобы эту багу исправил просто он поменял архитектуру настолько что там этого места чисто технически уже нет от слова вообще но при этом конкретно эта версия используется «наследственно» потому как а) новая версия системы имеет свои баги и на наших инстансах просто не запускается да работа ведётся но старая пока живёт исходя из б) вообще-то нашего кода написано тоже немало и переписать его под новую версию та ещё работа и она тоже как бы ведётся но вот пока ещё нет тем более что и сама система в новой версии см. п.п. а)

Так бывает я проверял ))

Відповісти
Підтримати
Vitaliy Fedoriv
Max Shnurenok .NET Architect в LogiqApps 22.01.2018 21:43
а он и фиксит баги, ломая походу фичи в флоу номер 45, 567 и 870
А потом еще и сверху фичу налепит, которая добавит\изменит неожиданно данных в вф 46, 667 и 770

Код ревью передаёт привет). Если мы о новичках, то тройной привет.

а так да, незачем изучать весь проект

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

Відповісти
Підтримати
anonymous
Nikita Lovygin Senior Salesforce Commerce Cloud Developer в Toptal 23.01.2018 12:33

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

Відповісти
Підтримати
anonymous
Іван Довгай PHP Developer 24.01.2018 11:34

Тесты писать не пробовали?)

Відповісти
Підтримати
anonymous
Denys Poltorak Embedded | C++ (opentowork) 24.01.2018 12:41

Ну так под новую фичу надо же поменять тесты, иначе не вмержится)

Відповісти
Підтримати
Іван Довгай
Іван Довгай PHP Developer 24.01.2018 12:59

Это уже не будет неожиданностью

Відповісти
Підтримати
Denys Poltorak
chronoman 24.01.2018 13:42

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

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

Відповісти
Підтримати
Іван Довгай
Іван Довгай PHP Developer 24.01.2018 14:01

Первый вариант естественен и значит все хорошо. Второй вариант просто говнокодерство какое то.

Відповісти
Підтримати
chronoman
chronoman 24.01.2018 14:31

Хаха все хорошо в первом варианте, ты просто не понимаешь в насколько геометрической проекции такое говно выливается в поддержку тестов: ну вот добавил какую то кнопочку на экран, ну или текст кнопки на 1 буковку поменял, банально закодить сам функционал — это меньше минуты дела, фигня чисто тривиальная, ну написал тест под это добавление, а потом хрясь и у тебя в 100500 тестах фейл в 1% (а это на минуточку надо править 1005 скриптов). Ты представляешь себе эффорт на то, чтобы поддержать этого ченж. Причем для пользователя цвет кнопки непринципиален, а буковку-кнопку он сам захотел. И за это он щедро платит 1цент, а больше оно же и не должно стоить. А теперь подсчитай во что это тебе обойдется в апдейте всех кейсов. С кнопкой это просто пример. Их можно придумать 100500 разных вариантов. Я уже молчу за то, что зачастую автоматические тесты, тестовые фреймворки посылают накуй основной постулат метрологии, что объект измерения не должен быть изменен внесенным измерительным устройством. Поэтому вольтметры стараются делать с высоким внутренним сопротивлением, а амперметры наоборот с низким. А вот зачастую все эти тестовые фреймворки меняют поведение системы по отношению к системе без онных, накладывают ненужные ограничения на дизайн, характеристики системы и т.п. И смещают фокус с реализации функционала на поддержку максимального покрытия тестами.

Відповісти
Підтримати
Іван Довгай
Іван Довгай PHP Developer 25.01.2018 08:47

Ну тут уже к новичку какие вопросы? Такое обычно называют макаронным кодом и всячески осуждают

Відповісти
Підтримати
chronoman
Denys Poltorak Embedded | C++ (opentowork) 24.01.2018 14:43

Самое сложное — отличить первый вариант от второго)
Особенно если уже никто не понимает, как система работает в целом и в деталях

Відповісти
Підтримати
Іван Довгай
Denys Poltorak Embedded | C++ (opentowork) 24.01.2018 14:44

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

Відповісти
Підтримати
anonymous
Oleg Shastitko 22.01.2018 20:36

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

Відповісти
Підтримати
anonymous
Николай Ник 22.01.2018 21:13

Ага давай рассказывай фантазер, какие конторы будут держать пол года что бы чел просиживал штаны и ничего делал, а только «читал» проект и при этом получал зарплату, назови еще при этом цифру зарплаты. А ТС скорее всего время профукал и чует пахнет жареным, поэтому и спрашивает такие вопросы. И вместо суровой правды ты ему цепляешь розовые очки на нос.

Відповісти
Підтримати
anonymous
Grez 22.01.2018 22:23
есть проекты на которых синиорам надо пол года что бы полностью выучить проект,

«проект» в данном случае понятие очень растяжимое. Может быть весь AWS — где много команд, и врятли ктото себе полностью представляет вообще. А Может быть и «командлайн тул для работы с AWS», где одна тима полностью все покрывает; и чел может там баги фиксить через час чтения исходников, не особо зная чегото о амазоне.

Відповісти
Підтримати
anonymous
Eugene Rusakov [FE] Tech Lead в Сільпо 22.01.2018 19:22

Мне понадобилось два месяца, проект писался 2 года — 3 разработчиками

Відповісти
Підтримати
Andrey Rogovsky 22.01.2018 17:58

Зависит от деталей. Если проект сделан на фреймворке тот новичок должен сдать базовый тест на понимание концепта фреймворка.

А если это недокументированная самописка то срок скажет наставник после первого месяца.

Відповісти
Підтримати
De Money 22.01.2018 17:54

Від 0 до півроку. Як на мене «щось» треба вже через тиждень-два робити будь-де. А яка вам різниця? Це — не ваша проблема. Ваша проблема може бути в тому, що погано це вивчення йде, але це — інше і не пов’язано напряму із строками.

Відповісти
Підтримати
Denys Poltorak Embedded | C++ (opentowork) 22.01.2018 18:02

Ваша проблема ще може бути в Вашій конторі. Перше, що бажано зробити, потрапивши на старий проект — подивитись історію комітів:
1) Де ці всі люди зараз і що вони думають про цю контору
2) Що в конторі думають про цих людей
3) Яка кількість комітів та коду на тиждень в середньому в девелопера
4) Чи були ті, хто сильно відрізнявся (в обидва боки) від середньої швидкості
5) Що з ними сталось і наскільки швидко
6) Чи описана контора на коханому.іт, в негативних коментах ДОУ та на Glassdoor
7) Які власне стосунки в колективі, наскільки співробітники саркастичні у ставленні до проекта, начальства, один до одного, до новачків

Відповісти
Підтримати
De Money
De Money 22.01.2018 18:08

Хотів ще дописати, що зовсім не обов’язково ви винні і купа ще різного може бути. Але саме строки — поганий показник.
А ви правда міряли швидкість по коммітах? =) Ще й у малознайомому коді... пахне КРІ по кількості рядків коду (я в курсі, що це не такий і поганий показник може бути).

Відповісти
Підтримати
Denys Poltorak
Denys Poltorak Embedded | C++ (opentowork) 22.01.2018 18:18

Тут ідея, що:
а) можна прикинути, наскільки інтенсивної роботи від тебе будуть чекати.
б) у певних конторах чи проектах є правило звільняти тих, хто занадто повільно або занадто швидко працює. Зазвичай таких видно з історії, й видно, що вони довго не протрималися.

Відповісти
Підтримати
De Money
Think Different 22.01.2018 17:41

ты учишь проект по ходу тасков. Примерно месяц-3 понять 1/5 это при огромном проекте. Смотря как у тебя настравник еще, так как есть дубовые что год будешь смотреть и не понимать, а есть и толковые.

Відповісти
Підтримати
Denys Poltorak Embedded | C++ (opentowork) 22.01.2018 17:34

Залежить. 1-2 дні на поставити софт, зареєструватись в системі. По тому можуть давати якісь маленькі баги фіксити. Поки фіксиш — потроху розбираєшся в проекті.
Це якщо окрім тебе ще хтось на ньому є. Якщо усі розбіглися, ніхто не знає, як воно працює, і тут тобі кажуть «розбирайся» — треба робити ноги, бо коли всі розбіглися — то вони розбіглися не марно, щось в конторі чи на проекті дуже недобре. Зазвичай це недобре вилізе протягом пів-року.
Якщо прожив на проеті пів-року — вважається, що можеш ефективно працювати в тій частині проекта, з якою маєш повсякденну активність.

Відповісти
Підтримати
Костя Третяк 22.01.2018 17:17

Ви справді «дуже сильно новачок», якщо питаєте за терміни по вивченню «маленького проекта». Бувають такі малі проекти, що там чорт ногу зломить, а бувають великі проекти з хорошою документацією, з дотриманням різних конвеншинів, з хорошими коментарями і т.д., що їх можна вивчити швидше.

Схоже, вас не влаштовує, що від вас це вимагають. Так зробіть дослідження ринку праці, підтягніть що треба, виставіть резюме, навіть якщо його побачить поточний роботодавець, і — вперед. Якщо ж ви побачите, що у вас ще замало досвіду щоб безболісно змінити місце роботи, то... в теорії, у вас виникне бажання підтягнути що вимагають на поточному місці роботи.

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

Відповісти
Підтримати
Chaz Ashley 22.01.2018 21:40

Гадки не маю, з чого ви взяли, що мене щось не влаштовує. Мені просто були сказали, що в деяких конторах цілий місяць тільки розбираються, от я й запитався.

Відповісти
Підтримати
Костя Третяк
Bot Bot 22.01.2018 21:42

Я как-то пол года вьезжал. Не доки читал, а именно простыми тасками занимался и код ревью.

Відповісти
Підтримати
Chaz Ashley
Костя Третяк 22.01.2018 22:09
Гадки не маю, з чого ви взяли, що мене щось не влаштовує.

Цікаво, який висновок роблять інші читачі з вашого опису, коли ви говорите про новачка... до якого інша людина купу всього наробила... а потім саджають його і вимагають продуктивної роботи...

Відповісти
Підтримати
Chaz Ashley
Konstantin Uvarin Perl developer в WebbyLab 22.01.2018 16:46

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

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

Відповісти
Підтримати
Platan 22.01.2018 15:21

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

Відповісти
Підтримати

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.