Как вы при разработке в крупном проекте обнаруживаете выходы за рамки своей части, и как вообще изучаете проект за пределами задачи?

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

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

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

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

Вопрос первый - как с этим бороться?
Тупо ставить себе на каждой задаче четкий вопрос, "А что за этим тянется?"
Или лучше еще ранее изучить чужую часть, и запомнить при каких задачах задавать такой вопрос относительно этой части?

И тут вопрос второй - а как лучше изучать чужую часть?
Тимлиду еще попроще, потому что он и весь вмерживаемый код при желании может следить (ианередко и должен), и в то же время обсуждает архитектуру с участниками словесно.
А как это делать простому джуну? Его глазам ничего, кроме вмерживаемого кода, и недоступно? Или тут есть и джуны, которым словесные обсуждения тоже доступны? Или никто из присутствующих вообще не изучает чужой код своей команды?
  • Вопрос задан
  • 704 просмотра
Решения вопроса 2
BojackHorseman
@BojackHorseman
...в творческом отпуске...
это неправильный подход. если каждый пилит только свой кусок, то такая задача тебе никогда не попадется. в противном случае "чужих" кусков нет, а есть лишь "пока незнакомый". что там можно изучать заранее, я не знаю, таким никогда не занимался. просто каждому новенькому на испыталке кидал мелкие таски из разных частей, чтобы максимально возможно поглазели проект.

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

встречный вопрос: в скольких проектах вы принимали участие? даже не крупных, но где участников больше двух.
если ответ меньше трёх, то это вообще не вопрос.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
Adamos
@Adamos
Если есть тимлид - то однозначно нужно обратиться к нему. Потому что джун может быть уверен, что ради его правок нужно пересобачить половину готового кода и заработать канделябры от тех, кто его отлаживал. А тимлид ткнет его носом в простой и естественный способ ничего лишнего не ломать. Даже если на это потребуется в десять раз больше времени того зеленого джуна.
Ответ написан
1) Берешь задачу в разработку
2) Изучаешь код
3) Говоришь менеджеру (тех-лиду), что ты тут нифига не понимаешь => потребуется больше времени, чем обычно
4) Говоришь отделу тестированию, что ты вообще нифига не понимаешь, что сделал - пусть протестируют твои правки тщательнее.

Как-то так=)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы