Что я должен спросить предыдущую группу разработчиков во время своей единственной (1-3hr) встречи?

Я бы попросил прохождение кода. Не построчно, а больше для общей структуры проекта, отношений между отдельными модулями и т. Д.

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

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

Принесите печенье (или пиццу, пиво или вино в зависимости от обстоятельств); вы захотите, чтобы у них остались положительные воспоминания о вас, когда вы звоните с вопросами.

Изменить: , чтобы сформулировать свой ответ в форме вопроса: «Могу я предложить вам домашнее печенье?»

Возможно, вы уже это сделали, но я бы хотел убедиться, что вы можете:

• Оформить последнюю версию версия
• Выполнить все миграции
• Выполнить все тесты
• Развернуть (даже если на промежуточный сервер)
• Запустить приложение локально

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

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

Также получите их электронные письма. , так как у вас будут еще вопросы.

Другие вещи, которые могут быть полезны

• модель данных
• Каркасы пользовательского интерфейса
• данные для отслеживания ошибок / данные для отслеживания проблем
• , которые являются клиентами / людьми, представляющими клиентов
• конфигурация среды разработки
• расположение элементов управления исходным кодом и т. д.
• объяснение специальных параметров конфигурации

Вау! Все отличные ответы, вплоть до печенья.

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

1. Повестка дня. Разделите встречу на несколько частей, например:

   • Краткое (15 минут) введение и обзор арки
   • Один на один с членами команды
   • Обзор проекта в группе и т. Д.

2. Позитивная энергия . Особенно, если отношения по своей сути сложные, сохраняйте позитивный фокус, постулируя: какие улучшения вы бы внесли в следующую версию - (переписывать - не вариант, верно, Джоэл) - фиксируйте каждый нюанс и переходите к их уровню комфорта только ближе конец.

3. Координатор . Используйте обученного фасилитатора встречи по дизайну Они могут помочь подготовиться к встрече, провести собеседование перед встречей, составить повестку дня. Во время встречи они могут управлять интенсивностью и сохранять концентрацию. Они также могут предложить формы сбора того, что может быть значительным объемом информации.

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

Дон

Узнайте, почему. Как это достаточно легко увидеть в кодовой базе, но почему иногда невозможно понять, и это укусит вас за задницу.

Например ...

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

Почему вы выбрали шаблон / инструмент / библиотеку x? Что еще вы рассматривали? Почему?

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