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

 Поделитесь своим опытом в таких ситуациях. 

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

Имей ввиду что в зависимости от руководства тебя могут или похвалить или на оборот скажут что ты время зря тратишь и так всё понятно. Скорее будет второе!  

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

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

  

Это нормально.  

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

Например, в одной косметической компании клиенты зовутся словом "тётки".  
  

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

  

Это совершенно нормально.  

Типовая ситуация.  
  

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

  

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

Спрашивать - это совершенно нормально.  
  

Ты вовсе не глупость показываешь свою.  

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

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

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

Как работодатель отношу неумение общаться по работе - к огромным минусам.  

Сидит себе в уголке, ни у кого не спрашивает, ничего не знает...  

Что он там делает? Как он там делает? Так как положено у нас на фирме? Нет, конечно.  

Делает какую-то самопридуманную фигню, да еще и за наши деньги.  
  

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

 Багфиксинг, если коротко.  

Только нужен толковый ПМ, чтобы задачи подбирал по уровню.  
  

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

Потом - баги посложне, потом еще сложнее...   
  

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

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

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

  

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

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

 Постыдно бегать за помощью? Так ты не бегай с вопросом "Как?". Если тебе нужна эта работа, садись, бери мандаринку и изучай все с чем вы там работаете. Предполагай какими принципами и методами пользовались бывшие/текущие девы и уже подходи к своим сенам с вопросом 'Вы так это задумывали?'.   
  

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

Поймешь что 'курилось' во время разработки - поймешь как строилась архитектура проекта (ов). Удачи! 

 карты ТАРО, могут еще звезды помочь.  
  

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

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

  
  

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