[devel][внезапно] Как правильно принимать новый проект?

> Какие данные следует запрашивать в первую очередь

телефон разраба.

в общих чертах нарисовать схему по функциям/обьектам/etc, пусть скажет какие куски работают и трогать их не надо, какие вообще стоит переписать заново. ну и посидеть пару вечеров с пивом и кодом вместе, пусть обьяснит свое виденье проэкта.

ну кстати: самостоятельно 2 недели править баги и писать новое, пока консультант.

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

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

Остальное на совести документации.

> пока консультант.

пока консультант в наличии

Я понял, спасибо за советы.

>ну кстати: самостоятельно 2 недели править баги и писать новое, пока консультант.

Пробовал идти по этому пути, не очень-то помогает — я по натуре интроверт и начинаю раскапывать сам => потеря ценного времени.

1. Пошаговая инструкция по установке проекта на чистой девелоперской машине, все этапы сборки и выдача готового релизного артефакта. Включая всё ПО, которое нужно установить, все конфиги, которые нужно подправить. Т.е. без него ты должен смочь собрать проект. И если у тебя сломается машина, ты должен смочь собрать проект ещё раз.

2. Описание всех типичных задач, которые тебе надо будет делать, и то, как их надо будет делать. Их обычно не так много.

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

4. Очень желательно, чтобы начальство заключило договор с разработчиком на пару месяцев, чтобы ты мог его доставать любыми вопросами по проекту. Это будет гораздо дешевле, чем ты это будешь сам раскапывать. Если не вариант - значит налаживай отношения с этим разработчиком, бери его контакты.

5. Как сказали уже, когда развернёшь development environment, можешь начинать работать, и по ходу работы старайся лазить во все части проекта, разбираться во всём. Не тратя на это много времени, но примерно запоминая, что и где находится.

нужно:

1) Быть склонным к насилию психопатом

2) Узнать увольняющегося — где он живет.

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

Это нужно было делать, когда он начинал писать — тем более, что начинал не он — сейчас-то уже поздно %)

Похоже, это примерно то, что нужно. Спасибо за развёрнутый ответ.

>4. Очень желательно, чтобы начальство заключило договор с разработчиком на пару месяцев, чтобы ты мог его доставать любыми вопросами по проекту.

А ведь это было бы здорово, типа даём по уходе бабла за +две недели и на 80 часов консультаций в течение пары месяцев имеем законное право.

И почему такое сразу в контракте не предусмотрено? (...А всё оттого, Сильвер, что Вы слишком жадный! (с)...)

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

> Узнай почему валит

кстати, да. важный момент.

Никогда не принимай новые проекты, будешь долгое время раскапывать глюки, костыли и велосипеды прежнего программера. Остерегайся такой работы, лучше найти проект, который еще не начали писать.
Если уж вляпался, то убеди начальство, что то, что написано - полный атас и начни компанию по переписыванию всего заново и с нуля. ;-)
Вообще, да, есть случай, когда брать такие проекты целесообразно - натырить исходников и продать конкурентам.;-))

>глюки, костыли и велосипеды
Угу, меня как раз с такого счастья сняли. Но.

Во-первых, переписывать всё и сразу — кишка тонка. Во-вторых, я намерен на этом проекте срубить экспы.