[Перевод] Что иметь ввиду при переписывании программного обеспечения
При разработке каких-либо продуктов у команды зачастую возникает желание перестать бороться с текущим состоянием проекта и переписать всё снова, на этот раз «правильно» и «по науке». Обычно такие порывы не одобряются, но в этот раз я бы хотел предложить к прочтению перевод поста Hugo Baraúna, посвященного тому, какие вопросы нужно задать себе, если всё же решили переписывать.
Также, как и большой рефакторинг, переписывание продукта — непростая штука. За много лет мы приобрели достаточно опыта, чтобы указать, что вам следует обдумать, планируя и осуществляя процесс переписывания.
Будут ли обе платформы существовать одновременно, или нет?
Планируете ли вы поддерживать устаревшую и новую версии на продакшене? Если да, то как долго? Вам следует избегать обслуживания двух версий на продакшене в течение долгого времени из-за операционных расходов.
Кто будет заниматься переписыванием, а кто — поддерживать старую версию?
Разработчики предпочитают работать над перспективными проектами (green field projects). Вам следует иметь это ввиду, когда будете принимать решение, кто будет поддерживать старую версию и кто будет работать над новой.
Переписывать все и сразу не имеет смысла
Не рационально иметь сопоставление 1-к-1 между старой и новой версиями. Другими словами, какие именно возможности вам следует начать переписывать?
Примите во внимание то, какое влияние на клиентов окажет продукт с меньшим количеством возможностей.
Переписывание замедлит или остановит внедрение новых возможностей в старую версию
Скорее всего, вы не будете внедрять новые возможности в старую версию в процессе её переписывания. Новые возможности не получат не только конечные пользователи, но и внутренние клиенты (коммерческий и продуктовый отделы). Ваши внутренние клиенты и акционеры будут требовать от вас появления новых возможностей.
Убедитесь, что взаимодействие до и во время переписывания налажено и что все заинтересованные лица согласны с конечными целями.
Держать в секрете или опубликовать?
Представьте, что вы — потенциальный клиент программного продукта. Вы планируете купить его, но вы только что обнаружили, что совершенно новая версия будет представлена через три месяца. Купите ли вы устаревшую версию или подождете три месяца? Помножьте это на дюжины или сотни потенциальных покупателей. Поставщик может потерять кучу денег.
Поэтому, если вы поставщик продукта, вам следует старательно обдумать, как и когда вы собираете опубликовать информацию о принципиально новой версии.
Миграция данных
Переписывание это не просто разработка возможностей. Вам также следует запланировать миграцию данных. Люди обычно недооценивают сложность и затраты, необходимые для миграции данных со старой версии на новую. Эта деятельность не должна быть просто одной задачей на в вашем списке с заголовком «миграция данных».
Например, предположим, что вам нужно перенести учетные записи пользователей. Если ваша устаревшая версия управляется третьей стороной, скорее всего у вас нет доступа к зашифрованным паролям пользователей, так что вы будете не в состоянии и перенести их. Вам потребуется попросить каждого пользователя в отдельности сбросить его пароль в новой версии. Это тоже часть процесса миграции данных.
Будьте готовы к возможному снижению конверсии
Вы запустите новую версию с новыми возможностями. Кто может гарантировать, что конверсия останется той же? Конверсия жизненно важна в некоторых областях, таки как e-commerce.
В идеале, у вас должна быть возможность сохранить обе версии, новую и старую, на некоторое время, на случай, если падение конверсии будет слишком сильным.
Выделите время на обучение внутренних пользователей
Это тоже часто упускают из виду. План переписывания должен иметь фазу, посвященную обучению внутренних пользователей до передачи вашего нового продукта в продакшен. Это также нельзя недооценивать. Может пройти много времени, прежде чем ваши внутренние пользователи смогут дать вам обратную связи о том, что, возможно, следует изменить.
Внутренние пользователи могут быть найдены в разных областях, таких как служба поддержки и продажи.
А как насчёт вас? Есть ли у вас советы о том, о чем стоит побеспокоится при переписывании продукта? Поделитесь с нами!
Комментарии (1)
28 июля 2016 в 21:25
+1↑
↓
У меня такое было…
Дам совет из личного опыта, при разработке занимайтесь проектированием бд до самого последнего поля и ключика.
Планируйте архитектуру приложения заранее, с возможностью расширения не за счет «костылей», а за счет добавления новых архитектурных модулей или компонентов.
Лишние пару дней проектирования сэкономят пару лней разработки, а впоследствии еще и пару дней на тесты и исправления
