Как вы при разработке в крупном проекте обнаруживаете выходы за рамки своей части, и как вообще изучаете проект за пределами задачи?
Периодически возникают такие задачи, когда, внося изменения в свою часть, требуется также внести их в ту часть, над которой тебе работать не приходилось. А еще иногда нужно сперва изучить ту часть. Ну или даже не изучить и не внести, но убедиться, что соответствующий человек в курсе и их туда внесет.
Что будет, если не учитывать это?
В лучшем случае на твою ошибку тебе укажут. А лучше бы сам...
В худшем же случае, никто может и не заметить проблему вовремя, поскольку главный спец по той части не ревьюит твой код, а те, кто ревьюит, даже если это тимлид всей команды, могут не знать таких деталей.
И ладно, если модули связаны напрямую. Там тебе ничто не мешает понять, что надо докопаться до самого глубокого из всех модулей, созданных твоей командой - и глянуть все эти модули. И, возможно, понять, что сделать упор надо вообще не на твой модуль, а как раз на самый глубокий.
А вот если "тот" модуль прилеплен где-то сбоку, то даже зная о его существовании и принципах работы, можно просто забыть, что с ним связана очередная задача.
Вопрос первый - как с этим бороться?
Тупо ставить себе на каждой задаче четкий вопрос, "А что за этим тянется?"
Или лучше еще ранее изучить чужую часть, и запомнить при каких задачах задавать такой вопрос относительно этой части?
И тут вопрос второй - а как лучше изучать чужую часть?
Тимлиду еще попроще, потому что он и весь вмерживаемый код при желании может следить (ианередко и должен), и в то же время обсуждает архитектуру с участниками словесно.
А как это делать простому джуну? Его глазам ничего, кроме вмерживаемого кода, и недоступно? Или тут есть и джуны, которым словесные обсуждения тоже доступны? Или никто из присутствующих вообще не изучает чужой код своей команды?
Максим Федоров, в то же время программист, который должен получать информацию только общением, тоже модель не состоятельная.
так как распределить?
и еще момент: если джун будет всю работу миддлов и синьоров всегда сваливать на миддлов и синьоров, то он не может быть повышен до миддла, потому что не имеет никакого опыта работы на уровне миддла.
я сам в течение нескольких лет очень много отвечал на некоторых форумах. и на мой взгляд интереснее получать лайки и "отметки" только тогда, когда ответ реально помогает. а не сиюминутные реакции "о, полезно", которые спустя неделю тщетных попыток претворить в жизнь превратятся в "нифига не выходит".
поэтому не спешу отмечать. но и аккаунт не забрасываю. если в итоге все это вместе поможет, и мне ничто не помешает отметить ответы, то я отмечу их все разом
beem7, свою работу скидывать не нужно никуда, тк нужно, чтобы не вам сделали, а вам объяснили, при чем не конкретный случай и конкретную проблему, а более общи принцип работы...
Например вы запутались в настройке сложного устройства модуля, который . сложно настраивается, все это скрыто, ну я так абстрактно...
Помимо того, что вам нужно что-то доработать -- вы в принципе не втыкаете, что и как происходит... неплохо бы крупными мазками чтобы вам накидали картину происходящего...
это прикольно коррелирует со всякими тезисами, что "правильно объясненная проблема - 80% решения", "моя кошка отличный программист, вот объясню проблему своей кошке - и сразу понимаю, как ее решить".
да никак. пока ты раб - ты делаешь то, что сказали, и ничего более.
когда ты перестал быть рабом, вопросы возникают совсем другие.
встречный вопрос: в скольких проектах вы принимали участие? даже не крупных, но где участников больше двух.
если ответ меньше трёх, то это вообще не вопрос.
Если есть тимлид - то однозначно нужно обратиться к нему. Потому что джун может быть уверен, что ради его правок нужно пересобачить половину готового кода и заработать канделябры от тех, кто его отлаживал. А тимлид ткнет его носом в простой и естественный способ ничего лишнего не ломать. Даже если на это потребуется в десять раз больше времени того зеленого джуна.
Потому что джун может быть уверен, что ради его правок нужно пересобачить половину готового кода
ну так у джунов такая же проблема и со своей частью.
но если все сваливать на старших и никогда даже не пытаться поработать на более высоком уровне (хотя бы уровне миддла), то неясно с какой стати тебя должны повышать до миддла, и в какой момент.
а так бы повысили в тот момент, когда стал бы более-менее успешно работать на более высоком уровне, заработал навык быстро генерировать оптимальные решения именно по незнакомому коду.
beem7, желание переделать то, что работает - это именно проблемы роста программиста. С опытом учишься его сдерживать. Со своим кодом, конечно, можешь зарабатывать опыт, сколько влезет... точнее - сколько позволят.
но если все сваливать на старших и никогда даже не пытаться поработать на более высоком уровне (хотя бы уровне миддла), то неясно с какой стати тебя должны повышать до миддла, и в какой момент.
Данным вопросом вы подтверждаете статус джуниора.
Мидл это не тот, кто пытается работать на "более высоком уровне", это тот, кто уже обладает достаточным опытом, чтобы понимать как такой вопрос решить.
Не пытайтесь прыгать выше головы - спрашивайте у старших, набирайтесь опыта.
Если же вы хотите стать опытным программистом спрашивая тостер, а не ваших коллег - то такой путь займет в разы больше времени.
Мидл это не тот, кто пытается работать на "более высоком уровне", это тот, кто уже обладает достаточным опытом, чтобы понимать как такой вопрос решить.
а опыт откуда взять? не от попыток самостоятельного решения задач?
при этом "попытки" не означают, что все надо изучать только на опыте. книжки почитать тоже можно.
а вот спрашивать кого-то, то есть вытягивать информацию дополнительно к той, которую и так говорят и пишут - вообще не очень желательно. на тостере я задаю только самые глобальные вопросы. их надо именно на тостер, а не коллегам, потому, что для них нужно побольше ответчиков. например, коллеги могли с рождения быть более талантливыми в абстрактном интеллекте, чем я. тогда через многие мои проблемы они не прошли и совет дать не могут.
beem7,
"а опыт откуда взять? не от попыток самостоятельного решения задач?"
Во-первых опыт это и есть решение задач, но джуниору обычно ставят задачу, которая ему должна быть по силам. Во-вторых, для вопросов по архитектуре проекта нужно спрашивать либо тех, кто дольше работает в проекте и это знает, либо вашего куратора.
У вас вопрос слишком конкретный, а вы хотите ответ слишком глобальный. В конкретном вопросе про то, как решать проблему из другого модуля - ответом будет уточнить у вашего куратора, тимлида, более опытного коллеги.
Если глобально - то сам опыт берется в процессе работы над проектом в команде. Вы можете попроситься быть ревьювером чужих коммитов (просто смотреть), и попросить поучаствовать в парном программировании, и просто решая задачи вы знакомитесь с проектом.
Книжки - обычно о том, как должно быть, а не как реализовано именно у вас...
1) Берешь задачу в разработку
2) Изучаешь код
3) Говоришь менеджеру (тех-лиду), что ты тут нифига не понимаешь => потребуется больше времени, чем обычно
4) Говоришь отделу тестированию, что ты вообще нифига не понимаешь, что сделал - пусть протестируют твои правки тщательнее.
