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

Ответ 1

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

Задать

• Если вы можете записать разговор
• Для обзора архитектуры
• Почему они приняли определенные архитектурные решения над другими.
• Полный список зависимостей (если вы не можете понять это самостоятельно)
• Каковы самые большие проблемы
• Какие части проектов всегда/никогда не фиксируются.
• Какова ахиллесова пята проекта
• Что вызовет самые большие головные боли
• Какие проблемы с безопасностью существуют и каково ограничение для его исправления.
• Что бы вы сделали дальше, если бы вы были мной?
• Что вы должны знать, что не спрашивали (самый важный вопрос)

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

Ответ 2

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

Ответ 3

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

Например...

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

Ничего себе! Все отличные ответы, вплоть до куки.

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

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

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

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

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

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

Дон