Захват проекта - Что я должен задать предыдущему программисту?

Я занимаюсь разработкой коммерческого веб-сайта. Этот сайт был разработан в течение двух лет другим программистом. Это, в основном, работа с одним человеком (поддерживать и расширять сайт). У меня будет переход на 2-3 дня, когда другой программист покажет мне систему. Но из того, что я знаю, документации мало. Все находится в коде (который является документированным). Вот что я собираюсь задать до сих пор:

Объяснение наиболее сложных элементов системы
Описание общей архитектуры
Описание средств поддержки (настройка IDE, модульные тесты, развертывание механизм)
Любая книга, веб-сайт, подкаст, который он использовал, чтобы влиять на архитектуру система

Любые другие, что мне не хватает?

[EDIT] Спасибо всем. Потеря хороших предложений. Мне хотелось бы принять более одного ответа! Кроме того, я бы добавил:

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

Последнее: разработчик сказал, что он будет готов ответить на мои вопросы позже, если мне это нужно. Это его "ребенок" в конце концов. Но я действительно думаю, что через 6 месяцев он будет продвигаться дальше, и его доступность будет намного меньше!

Ответ 1

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

Ответ 2

Перед просмотром кода:

Очистите objs и exes, и пусть он/она восстановит вещь. Следите за любым ручным взаимодействием (он строит через "make" в одиночку или участвует в какой-то игре).

Еще лучше: дайте ему голую (только что купленную) машину, пусть он/она продемонстрирует чек и перестроит. Затем посмотрите, как приложение запускается и появляется (какие-либо секретные опции для ввода?).

Затем: в сеансе парного программирования добавьте одну или две функции в систему и посмотрите, где и как они реализованы.

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

Ответ 3

"Если бы вы могли вернуться и переделать эту систему, что бы вы сделали по-другому"

Ответ 4

Спросите: а) что вы не хотите, чтобы я спросил вас об этой системе? б) что вам больше всего понравится, когда вы больше не будете работать над этим проектом? c) Каковы части системы, которые слишком сложны для документирования?

Ответ 5

Его телефон.

Ответ 6

Кто ваши опытные пользователи - чье мнение я должен искать или доверять?

Кто ваши опасные неопытные пользователи - кого я должен слушать, а затем активно игнорировать?

Ответ 7

Известные проблемы ¹
Известные области улучшения ¹
Существующие данные покрытия кода, скорость прохождения теста и т.д., которые будут использоваться в качестве базовой линии
Советы по устранению неполадок (понимание файлов журнала, отладочных сбоев, общих ошибок)
Объяснение параметров конфигурации

¹ Известный только ему или ей

Ответ 8

Какова периодическая "ручная работа", требуемая системой?

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

Ответ 9

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

Ответ 10

Первый вопрос, который я обычно задаю при принятии проекта, заключается в том, как вывести его из источника управления (в основном, "Где это?" ). Кроме этого, я думаю, вы попали во все высокие очки.

Настройка IDE, модульные тесты, механизм развертывания

вероятно, самые важные вещи, о которых вы можете спросить.

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

Ответ 11

Удостоверьтесь, что вы можете ПОСТРОИТЬ ЭТО И ВЫПУСКАТЬ ЭТО.

Слишком много раз возникают проблемы с отсутствующей информацией.

Вам нужно ЗНАТЬ ВСЕ вспомогательные вещи.

Получите новую машину и убедитесь, что вы можете дублировать сборку и выпуск.

EDIT: после этого это будет: "Что все, что вы хотели исправить, но не дошли до и нигде не документированы?"

Ответ 12

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

Ответ 13

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

Ответ 14

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

Например, в одном из приложений, которые я поддерживаю в настоящее время, мы взаимодействуем с третьей стороной, у которой есть клиент типа "веб-просмотрщик". "Gotcha" заключается в том, что веб-просмотрщик не поддерживает состояние пользовательского сеанса (сломан, когда он был обновлен до последней версии, чтобы исправить другие критические проблемы). В результате я должен время от времени напоминать пользователям, чтобы просто минимизировать окно браузера, чтобы тайм-аут происходил естественным образом, иначе они будут заблокированы в течение длительного периода времени, пока люди Ops здесь не смогут установить более новую версию.

Ответ 15

Какие самые большие проблемы, с которыми столкнулся сайт, были и как они были решены? Слишком легко попытаться исправить что-то, что совершенно не имеет смысла только для того, чтобы обнаружить, что то, что кажется бессмысленным, на самом деле является единственным исправлением для некоторой тонкой, но неприятной ошибки.

Просматривая код и просматривая все, что сложно понять, и просто спрашивает: "Что это делает, почему вы его добавили?"

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

Ответ 16

Как и технические вещи (что "легко" выяснить:)) узнать о бизнес-правилах! Они редко документируются должным образом (по моему опыту), и вы обычно обнаруживаете только трудный путь, когда что-то идет не так.

Ответ 17

От 2 до 3 дней звучит коротко для передачи, поэтому не бойтесь просить больше.

Сначала создайте рабочую локальную среду с помощью элементов управления версиями, ide, build и release, которые выполняются локально.

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

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

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

Ответ 18

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

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

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

Ответ 19

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

Ответ 20

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

Ответ 21

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

Узнайте о своих клиентах. Они придирчивы? Что они ожидают?