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

Передачи - неизбежная часть разработки программного обеспечения (никто не работает над всем вечно!), Но одни и те же сбои имеют тенденцию повторяться снова и снова.

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

Документация

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

По моему опыту, документацию просто забывают. Во время активной разработки это никому не нужно прямо сейчас, поэтому стимула мало. Затем наступает время передачи, и README о том, как загрузить код, устарел на 2 года, имеет старые ссылки или просто ошибочен.

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

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

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

Спаривание и совместная работа

Нет лучшего способа изучить кодовую базу, чем запачкать руки.

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

Если нет времени пересекаться и вместе работать над новыми проблемами, по крайней мере выделите время (2–3 часа), чтобы вместе обсудить основы.

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

Долгосрочный план

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

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

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

Однако эти 5 часов в месяц обычно не вызывают ошибок ...

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

Приобретая программное обеспечение, легко забыть о «других» вещах (DevOps), и это требует длительного планирования. Позже будет неинтересно узнать, что настоящей производственной среды нет, конвейеров CI / CD или что ваш сертификат SSL скоро устареет. Как и в большинстве случаев, чем раньше вы узнаете, что что-то не так, тем лучше. Поэтому убедитесь, что кто-то задает правильные вопросы, и не думайте, что только потому, что это работает сейчас, это будет работать долго.

Образ мышления и культура

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

Очень заманчиво винить во всем старую команду, но не стоит. Это может стать фактическим оправданием любой проблемы. Ошибки? Пропущенные сроки? И все из-за кода старой команды, плохих архитектурных решений или множества оправданий, требующих «перекладывания денег».

Трудно взяться за новый код, и часто лучшее, что мы можем сказать, это: «Я бы так не поступил». Но помните, что у вас не всегда есть весь контекст того, почему были приняты исходные решения, и у первоначальных разработчиков могли быть веские причины для всего, что они делали.

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

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

Несчастные случаи:

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

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

Заключение

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

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

Наконец, может быть трудно синхронизировать старые и новые команды, особенно когда культура, как правило, остается закулисной областью раздора. У разных команд могут быть разные представления о том, что важно, как должны быть настроены конвейеры, как должны работать PR и т. Д. Это нормально! Все начинается с сочувствия, рассудительности в отношении того, откуда исходит другая команда (без навязывания им своих методов и культуры), и совместной работы над проблемами!