Как быстро въехать в чужой проект?

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

Подливают масла в огонь и архитектурные моменты: какие-то свои термины для описания функционала, свои правила наименования, построения и прочего.

Никаких документаций по проекту, комментариев к столбцам в БД нет. Плюс область самих программ совершенно не знакомая.

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

Поделитесь своим опытом в таких ситуациях.
  • Вопрос задан
  • 1055 просмотров
Решения вопроса 1
YershovAleksandr
@YershovAleksandr
Java Developer
Все свои полученные знания по проекту нужно сразу фиксировать. В идеале в электронном виде, но можно и на бумаге. Это твоя документация.
Имей ввиду что в зависимости от руководства тебя могут или похвалить или на оборот скажут что ты время зря тратишь и так всё понятно. Скорее будет второе!
Для прокачки кармы, если захочешь, потом передашь свою писанину следующему гребцу.
Ответ написан
Пригласить эксперта
Ответы на вопрос 6
@stratosmi
Подливают масла в огонь и архитектурные моменты: какие-то свои термины для описания функционала, свои правила наименования, построения и прочего.

Это нормально.
Регулярно сталкиваюсь там, где есть постоянный коллектив - свои собственные только ими употребляемые внутренние термины.
Например, в одной косметической компании клиенты зовутся словом "тётки".

Никаких документаций по проекту, комментариев к столбцам в БД нет. Плюс область самих программ совершенно не знакомая.

Это совершенно нормально.
Типовая ситуация.

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

Ты хочешь какую-то свою выдуманную проблему решать за зарплату или всё же проблему для фирмы?
Спрашивать - это совершенно нормально.

Ты вовсе не глупость показываешь свою.
А выясняешь особенности уникального проекта.

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

Кто кроме тебя самого знает что тебе непонятно.

Как работодатель отношу неумение общаться по работе - к огромным минусам.
Сидит себе в уголке, ни у кого не спрашивает, ничего не знает...
Что он там делает? Как он там делает? Так как положено у нас на фирме? Нет, конечно.
Делает какую-то самопридуманную фигню, да еще и за наши деньги.

Решает какую-то свою надуманную проблему, а не ту проблему фирмы, что его наняли решить.
Ответ написан
@BorLaze
Java developer
Багфиксинг, если коротко.
Только нужен толковый ПМ, чтобы задачи подбирал по уровню.

Т.е. сначала что-то легенькое, на что спецов отвлекать просто расточительство. В идеале - еще чтоб и модуль подсказал, где искать.
Потом - баги посложне, потом еще сложнее...

Тут уже и на реализацию новых фич можно подключать.

Так можно легко и непринужденно ознакомиться со всей системой, и пятым колесом себя не чувствовать.
Ответ написан
angrySCV
@angrySCV
machine learning, programming, startuping
Работаю не один, никакого вводного брифинга толком не было, а постоянно бегать за помощью считаю очень постыдным занятием, к тому же отвлекающим других от своей работы.

Если у компании нет проработанной процедуры обмена знаниями (в виде например парного программирования, или какого-то обучения, документации), то видимо им пофигу на новичков (очень типичная ситуация), твои вопросы реально будут отвлекать человека на котором уже висят какие-либо задачи (соответственно ты будешь мешать ему выполнять эти задачи), как быть в таком случае -> скорее всего реально тебе никто не поможет (кроме поверхностных советов), поэтому тебе надо отработать схему изучения чужого продукта, тут самый главный навык - работать с дебагом, научится экспериментировать с продуктом и отслеживать изменения.
Рекомендую еще начать с изучения тестов - там должна быть описана основная логика приложения.
Ответ написан
OTCloud
@OTCloud
Не кради код ближнего своего.
Постыдно бегать за помощью? Так ты не бегай с вопросом "Как?". Если тебе нужна эта работа, садись, бери мандаринку и изучай все с чем вы там работаете. Предполагай какими принципами и методами пользовались бывшие/текущие девы и уже подходи к своим сенам с вопросом 'Вы так это задумывали?'.

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

Поймешь что 'курилось' во время разработки - поймешь как строилась архитектура проекта (ов). Удачи!
Ответ написан
Martovitskiy
@Martovitskiy
front-end
карты ТАРО, могут еще звезды помочь.

Не знаешь - спроси. Ничего в этом такого нет, когда новый сотрудник вникает и спрашивает.
Ответ написан
@mletov

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


Нет в этом ничего постыдного, особенно поначалу. Коль понаписали интуитивно непонятный код и не подготовили никакой документации, то пусть изволят объяснять. Я вот на текущем месте 3+ года работаю, так до сих пор периодически натыкаюсь в проектах на непонятки 5-10 летней давности, которые своим умом не осмыслишь. Только спрашивать.
Ответ написан
Ваш ответ на вопрос

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

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