Я занимаюсь разработкой коммерческого веб-сайта. Этот сайт был разработан в течение двух лет другим программистом. Это, в основном, работа с одним человеком (поддерживать и расширять сайт). У меня будет переход на 2-3 дня, когда другой программист покажет мне систему. Но из того, что я знаю, документации мало. Все находится в коде (который является документированным). Вот что я собираюсь задать до сих пор:
Любые другие, что мне не хватает?
[EDIT] Спасибо всем. Потеря хороших предложений. Мне хотелось бы принять более одного ответа! Кроме того, я бы добавил:
Последнее: разработчик сказал, что он будет готов ответить на мои вопросы позже, если мне это нужно. Это его "ребенок" в конце концов. Но я действительно думаю, что через 6 месяцев он будет продвигаться дальше, и его доступность будет намного меньше!
Обязательно попросите все данные для входа в веб-серверы, регистраторы доменов, серверы баз данных, серверы электронной почты и все, что вы можете придумать. Это звучит безумно, но часто разработчики регистрируют доменные имена сами по себе как административные и технические контакты. Затем компании придется перепрыгнуть через все виды обручей с регистратором, чтобы вернуть домен обратно, если с исходным программистом нельзя связаться.
Перед просмотром кода:
Очистите objs и exes, и пусть он/она восстановит вещь. Следите за любым ручным взаимодействием (он строит через "make" в одиночку или участвует в какой-то игре).
Еще лучше: дайте ему голую (только что купленную) машину, пусть он/она продемонстрирует чек и перестроит. Затем посмотрите, как приложение запускается и появляется (какие-либо секретные опции для ввода?).
Затем: в сеансе парного программирования добавьте одну или две функции в систему и посмотрите, где и как они реализованы.
Вышеизложенное может показаться глупым, но я видел проекты, в которых только строительство было кошмаром, и много знаний было в мозгу разработчика. Отсутствие надежной среды сборки и необходимость выяснять, как перестраивать, - это nighmare.
"Если бы вы могли вернуться и переделать эту систему, что бы вы сделали по-другому"
Спросите: а) что вы не хотите, чтобы я спросил вас об этой системе? б) что вам больше всего понравится, когда вы больше не будете работать над этим проектом? c) Каковы части системы, которые слишком сложны для документирования?
Его телефон.
Кто ваши опытные пользователи - чье мнение я должен искать или доверять?
Кто ваши опасные неопытные пользователи - кого я должен слушать, а затем активно игнорировать?
1 Известный только ему или ей
Какова периодическая "ручная работа", требуемая системой?
Вы знаете, те маленькие задания, которые возникают каждый раз так часто, что еще не были автоматизированы. Как вы его исправите и как вы его узнаете.
Спросите, каковы реальные требования. Большинство проектов либо не имеют письменных требований, либо устаревших письменных требований. Реальная документация - это обычно устные разговоры. Узнайте, с кем поговорить. Если у вас есть противоречивые требования от разных пользователей, узнайте, кто наиболее важно сделать счастливым.
Первый вопрос, который я обычно задаю при принятии проекта, заключается в том, как вывести его из источника управления (в основном, "Где это?" ). Кроме этого, я думаю, вы попали во все высокие очки.
Настройка IDE, модульные тесты, механизм развертывания
вероятно, самые важные вещи, о которых вы можете спросить.
Когда вы спрашиваете, какие веб-сайты влияют на тот, который вы принимаете, убедитесь, что вы получили список ссылок. Я обнаружил, что многие разработчики сохраняют закладки на сайтах, на которых они были взяты. Убедитесь, что вы их получили.
Удостоверьтесь, что вы можете ПОСТРОИТЬ ЭТО И ВЫПУСКАТЬ ЭТО.
Слишком много раз возникают проблемы с отсутствующей информацией.
Вам нужно ЗНАТЬ ВСЕ вспомогательные вещи.
Получите новую машину и убедитесь, что вы можете дублировать сборку и выпуск.
EDIT: после этого это будет: "Что все, что вы хотели исправить, но не дошли до и нигде не документированы?"
Не спрашивайте. Заблокируйте его в комнате - проинструктируйте его, что он не получит пищу или воду, пока он не начнет с самого начала, и не сообщит вам все, что он знает о системе. Затем задайте соответствующие вопросы по мере их появления. После этого - потратьте пару дней на просмотр кода. Затем повторите процесс. Сделайте это, пока вы не почувствуете себя комфортно с системой.
Обязательно получите все "gotchas" для приложения. Они часто представляют собой данные или бизнес-элементы, которые слишком ничтожны или причудливы, чтобы иметь официальную документацию, но при этом возникают большие удары или много времени отладки, если вы не знаете, что происходит.
Например, в одном из приложений, которые я поддерживаю в настоящее время, мы взаимодействуем с третьей стороной, у которой есть клиент типа "веб-просмотрщик". "Gotcha" заключается в том, что веб-просмотрщик не поддерживает состояние пользовательского сеанса (сломан, когда он был обновлен до последней версии, чтобы исправить другие критические проблемы). В результате я должен время от времени напоминать пользователям, чтобы просто минимизировать окно браузера, чтобы тайм-аут происходил естественным образом, иначе они будут заблокированы в течение длительного периода времени, пока люди Ops здесь не смогут установить более новую версию.
Какие самые большие проблемы, с которыми столкнулся сайт, были и как они были решены? Слишком легко попытаться исправить что-то, что совершенно не имеет смысла только для того, чтобы обнаружить, что то, что кажется бессмысленным, на самом деле является единственным исправлением для некоторой тонкой, но неприятной ошибки.
Просматривая код и просматривая все, что сложно понять, и просто спрашивает: "Что это делает, почему вы его добавили?"
Обязательно запишите свои ответы - возможно, даже прокомментируйте их в коде, чтобы они были там, когда они вам понадобятся. Нет ничего более раздражающего, чем чувство "Я знаю, что мне сказали об этом..."
Как и технические вещи (что "легко" выяснить:)) узнать о бизнес-правилах! Они редко документируются должным образом (по моему опыту), и вы обычно обнаруживаете только трудный путь, когда что-то идет не так.
От 2 до 3 дней звучит коротко для передачи, поэтому не бойтесь просить больше.
Сначала создайте рабочую локальную среду с помощью элементов управления версиями, ide, build и release, которые выполняются локально.
Затем попробуйте и получите представление о качестве кода, кратко просмотрев его. Если это выглядит плохо, вы можете не получить так много полезной информации о реализации от вашего предшественника.
Однако необходимо проверить все, что касается развертываний, серверов db, стратегии резервного копирования, регистрации и т.д. Также все лицензии для библиотек и т.д., А также список наиболее распространенных ошибок (если у них есть средство отслеживания ошибок, это может быть полезно)
Также вам нужно понять, насколько полезен ваш предшественник, так как я видел несколько стилей передачи, которые были переданы хэндоверу, который был дружелюбен, но вводил в заблуждение, где они давали саркастические ответы на заданные им вопросы в форме вопросник (который в то время как забавный был не профессиональным) просто незаинтересован.
Взгляд на код для 5 минут - лучший старт, если код действительно хорошо организован и прокомментирован, не может быть никаких оснований вообще разговаривать с ним.
Если код является отвратительным, не ожидайте разумных причин, почему он взломал что-то вместе, в лучшем случае вы можете использовать его в качестве ссылки для некоторого грубого кода и спрашивает, в чем цель.
В любом случае, говорить с прошлым разработчиком - это наименее полезная вещь, потому что в любом случае вы застряли с ней сейчас.
Внимательно просмотрите приложение и попытайтесь выяснить его в первую очередь. Затем перейдите на свою встречу с вопросами и, что наиболее важно, контекст.
Вы работаете в одной компании?
Если нет, и это напрямую не связано с проектом, я бы спросил его, почему он уходит. Это может дать вам некоторое представление о вовлеченной политике или если что-то мешает ему работать с ним или с клиентом.
Спросите о каких-либо препятствиях или обходах, с которыми столкнулся оригинальный разработчик.
Узнайте о своих клиентах. Они придирчивы? Что они ожидают?