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

Question

Существует проект Ruby on Rails (1.8, 2.3.2). Первая версия проекта была сделана какой-то организацией. Я буду реализовывать следующие версии этого проекта без какой-либо помощи со стороны этой организации. Я смогу поговорить с разработчиками из предыдущей команды разработчиков во время встречи (1-3 часа).

Статистика проекта: ~ 10k LOC, отношение кода к тесту 1,0 / 0,6, rspec

Какие вопросы о проекте вы можете порекомендовать задать?

Answer 1

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

Спросите

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

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

Answer 2

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

Answer 3

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

Например ...

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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

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

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

Don

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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

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