Существует проект Ruby on Rails (1,8, 2,3,2). Первая версия проекта была сделана какой-то организацией. Я буду реализовывать следующие версии этого проекта без какой-либо помощи этой организации. Я смогу поговорить с разработчиками из предыдущей команды разработчиков во время встречи (1-3 часа).
Статистика проекта: ~ 10k LOC, 1.0/0.6 код для теста, rspec
Какие вопросы о проекте вы можете порекомендовать?
Сначала просмотрите весь проект и выясните насколько это возможно, чтобы у вас был контекст и вы можете понять, что они говорят вам.
Задать
Кроме того, не будьте осуждающими, вы хотите, чтобы они раскрывали любые проблемы, о которых они знают. Вероятно, в приложении что-то не так, что они смущены, о чем вам нужно знать раньше, чем позже. Они не собираются открывать вам, если они вам не доверяют.
Я бы попросил прохождение кода. Не по очереди, но больше для общей структуры проекта, отношений между отдельными модулями и т.д.
Узнайте, почему. Как легко видеть в кодовой базе, но почему это невозможно понять, и укусит вас в задницу.
Например...
Какие части приложения были самыми большими проблемами производительности? Какие из этих проблем были решены? Какие еще проблемы?
Почему вы выбрали шаблон/инструмент/библиотеку x? Что еще вы считали? Почему?
Это, мы надеемся. (Хит какой-то лес.) Помогите удержать вас от того, чтобы тащиться по той же кривой обучения и ошибкам, с которыми пришлось столкнуться первой команде, и должно дать вам хорошее представление о том, где первая команда действительно сделала плохой выбор, вместо того, выбор основан на факторах, которые вы еще не учли.
Спросите, будут ли новые функции вызывать какие-либо существенные изменения в существующем коде (архитектурно) и что импликация будет связана с другими зависимыми частями приложения.
Также получите свои электронные письма, так как у вас появятся дополнительные вопросы.
Одна из самых важных вещей, на мой взгляд, состоит в том, чтобы получить столько технической документации, сколько вы можете до встречи с ними. Вам следует попытаться войти в собрание как можно более информированным, чтобы вы не только знали, в каких областях вам нужно больше всего сосредоточиться, но и иметь уже существующее знание о том, как некоторые из подсистем связаны друг с другом.
Кроме того, не бойтесь спросить, что бы они сделали по-другому, если бы дали шанс. Некоторые из лучших идей приходят слишком поздно в процессе разработки, который должен быть реализован - будь то доступность библиотеки, изменение требований, изменение в команде и т.д.
Принесите куки (или пиццу, пиво или вино, если необходимо); вы захотите, чтобы у них были положительные воспоминания о вас, когда вы звоните с вопросами.
Изменить:, чтобы ответить на вопрос: "Могу ли я предложить вам печенье, приготовленное на дому?"
Возможно, вы уже это сделали, но я бы удостоверился, что вы можете:
Перед тем, как идти на собрание, чтобы вы могли убедиться, что сможете, когда закончите.
Другие вещи, которые могут быть полезны
Ничего себе! Все отличные ответы, вплоть до куки.
Мой вклад предполагает, что это ваш единственный шанс получить доступ к старой команде разработчиков, поэтому вам нужно отбросить ее на ступеньку:
Повестка дня. Разделите встречу на несколько частей, например:
Положительная энергия. Особенно, если отношения по своей сути сложны, держите позитивный фокус, постулируя: какие улучшения вы бы поместили в следующую версию - (переписать не вариант, прямо Joel) - захватить каждый нюанс и проскользнуть мимо их уровня комфорта только ближе к конец.
Ведущий. Используйте обученного координатора проектных совещаний. Они могут помочь подготовиться к встрече, провести предварительные собеседования, разработать повестку дня. Во время встречи они могут управлять интенсивностью и держать фокус. Они также могут предлагать формы захвата того, что может быть достаточным объемом информации.
Кроме того, я попытался бы идентифицировать все артефакты дизайна вне кода, если таковые имеются, и понять, насколько он точен. Это может включать в себя выполнение проектных обзоров ключевых элементов этих документов по отношению к построенной системе.
Дон