Принятие проекта - что я должен спросить у предыдущего программиста? [закрытый]

прежде чем вы посмотрите на код:

очистите objs и exes, и пусть он/она восстановит вещь. Следите за любым ручным взаимодействием (строится ли он через "make" в одиночку или есть какая-то возня).

еще лучше: дайте ему/ей голую (только что купленную) машину, пусть он / она продемонстрирует проверку и восстановит. Затем посмотрите, как приложение запускается и появляется (любые секретные параметры для ввода?).

затем: в сеансе парного программирования добавьте одну или две функции к системе и посмотреть, где и как они реализуются.

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

"Если бы вы могли вернуться назад и переделать эту систему, что бы вы сделали по-другому"

спросите: А) что вы не хотите, чтобы я спросил вас об этой системе? б) чему вы будете больше всего рады, когда перестанете работать над этим проектом? c) какие части системы являются слишком сложными для документирования?

его телефон.

кто ваши опытные пользователи - чье мнение я должен искать или доверять?

кто ваши опасные неопытные пользователи - кого я должен слушать, а затем активно игнорировать?

Что такое периодическая "ручная работа", которую требует система?

вы знаете, те маленькие задания, которые появляются так часто, что еще не были автоматизированы. Как вы это исправляете и как вы это узнаете.

спросить, что real требования. Большинство проектов либо не имеют письменных требований, либо устарели письменные требования. Реальная документация, как правило, устные разговоры. Узнай, с кем поговорить. Если у вас есть противоречивые требования от разных пользователей, узнайте, кто является наиболее важным, чтобы сделать счастливым.

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

¹ известно только ему или ей

первый вопрос, который я обычно задаю при принятии проекта, - это как вывести его из системы управления версиями (в основном: "где это?"). Кроме этого, я думаю, что вы достигли всех высоких точек.

настройки интегрированной среды разработки модульных тестов, развертывания механизма

вероятно, самые важные вещи, о которых вы можете спросить.

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

убедитесь, что вы можете построить его и освободить его.

слишком часто возникают проблемы с недостающей информацией.

вы должны знать все вспомогательные вещи.

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

изменить: после этого было бы: "что все вещи, которые вы хотели исправить, но не добрались и нигде не документированы"?

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

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

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

например, в одном из приложений, которые я в настоящее время поддерживаю, мы взаимодействуем с сторонней системой, которая имеет клиент типа "web viewer". "Gotcha" с этим заключается в том, что web viewer неправильно обслуживает пользователя состояние сеанса (нарушено, когда он был обновлен до последней версии, чтобы исправить другие критические проблемы). В результате я должен время от времени напоминать пользователям просто минимизировать окно браузера, чтобы тайм-аут происходил естественным образом, иначе они будут заблокированы в течение длительного периода времени, пока люди Ops Здесь не установят более новую версию.

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

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

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

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

от 2 до 3 дней звучит коротко для передачи, так что не бойтесь просить больше.

сначала получите рабочую локальную среду с управлением версиями, ide, этапами сборки и выпуска при локальном запуске.

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

однако все, что касается развертывания, БД сервера, стратегии резервного копирования , регистраций и т. д. надо проверить. Также Все лицензии для библиотек и т. д., а также список наиболее распространенных ошибок (если они есть инструмент отслеживания ошибок это может быть полезно)

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

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

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

в любом случае, говорить с прошлым разработчиком-это наименее полезная вещь, потому что в любом случае вы застряли это сейчас.

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

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

спросите о любых блокпостах или обходных путях, с которыми столкнулся оригинальный разработчик.

Узнайте и о своих клиентах. Они разборчивы? А чего они ждут?