Как быстро разобраться в чужом проекте?

Пришел на проект, другой программист уходит через две недели.
Можете порекомендовать план, как максимально эффективно использовать эти две недели, чтобы по максимуму вникнуть в код?
Доков особо нет. Что точно должно быть задокументировано?
  • Вопрос задан
  • 467 просмотров
Пригласить эксперта
Ответы на вопрос 5
Zoominger
@Zoominger
System Integrator
Обратиться к программисту с просьбой всё рассказать.
Две недели - вполне достаточно для проекта средненького пошиба.

Ну или бежать, пушо вот это:
Доков особо нет.

Вместо тысячи слов говорит об уровне конторы и постановке работы отдела разработки.
Ответ написан
BojackHorseman
@BojackHorseman
...в творческом отпуске...
сидеть и дебажить. что тут еще остается делать.
код не умеете читать что ли?
Ответ написан
@pavelsha
Эти две недели "Живите вместе" с прежним разрабом.

1) Пусть расскажет архитектуру, надет все обрывки по постановке ТЗ и выполнению, детально их покажет и отсортирует.

2) Пройдите с ним по типовым кейсам поддержки / доработки. На второй неделе садитесь сами выполнять все заявки по системе, которые приходят на разраба (он чтобы был рядом как тьютор)

3) Фиксируй для себя сразу, что было не понятно. И спрашивай

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

5) Пусть старожил расскажет бытовые / политические / экономические особенности этого работодателя.
У тебя идет испытательный срок? Прекрасно! В случае Пушного зверька на горизонте имеешь право уйти одним днем.

6) Если время позволяет и ресурс есть, то пусть аналитики или этот разраб (если он Алл-инклюзив) садаться и ночами пишут доки по системе. Со стороны работодателя будет корректно предложить за это премию / бонус / договор ГПХ после увольнения разраба.
Ответ написан
Комментировать
saboteur_kiev
@saboteur_kiev Куратор тега Организация работы
software engineer
Доков особо нет. Что точно должно быть задокументировано?

Все логины, пароли, хостинги, зависимости, версии использованного ПО и либ, структура БД, политика бэкапов.

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

Если лениво поддерживать, то уведомив о рисках что проект неизвестный, можно неторопясь разбираться.
Ответ написан
Комментировать
alexgp13
@alexgp13
Руководитель ИТ-проектов
Умение читать чужой код - чуть ли не первое, что спрашивают при трудоустройстве. В первую очередь изучите, как ПО должно работать с точки зрения пользователя, по пользовательским инструкциям (заодно уточнив, реально ли это сделано или только в планах). А дальше, если голова на плечах, можно и разобраться.
Ответ написан
Ваш ответ на вопрос

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

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