[Анализ и проектирование систем, Управление разработкой] Почему никогда не стоит использовать Proof of Concept в продакшене (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Никогда не встречал разработчика, не любящего создавать всевозможные proof of concept (POC). Возможность построить что-то новое с нуля, чтобы протестировать теорию/процесс/технологию… Сама мысль об этом вдохновляет меня.
Есть в них что-то, что стимулирует наше творческое мышление. Вероятно, это отсутствие всяческих ограничений. Может, быть, это просто восторг от разработки «с чистого листа». Как бы то ни было, разработчикам это нравится.
Частично привлекательность создания proof of concept заключается в широте способов их применения. Можно создать POC для чего угодно! Хотите ли вы создать что-то забавное, научить кого-то незнакомой концепции, придумать идею для бизнеса или научиться использовать новую технологию для решения проблемы — варианты просто бесчисленны.
Но стоит быть аккуратными со своими ожиданиями. Я постоянно вижу, как разработчиков просят просто брать в продакшен их POC. Не делайте этого!
Proof of concept — это именно концепция. Это не «рабочая лошадка» для продакшена, соответствующая всем рекомендациям, общепринятым шаблонам и процессам разработки. Это инструмент для демонстрации идеи за короткий промежуток времени.
Сегодня мы поговорим о четырёх причинах, по которым POC ни за что не должно попадать в продакшен.
Продакшен изменяет способ разработки
Один из удобных аспектов создания POC заключается в том, что вы не скованы привычными ограничениями разработки. Вы можете писать на любом языке, использовать «быстрые и грязные» решения, а также хардкодить.
Не важно, как вы реализуете результат, если в результате сможете доказать свою правоту.
Если бы вы предполагали, что POC будет использоваться в продакшене, то подходили бы к кодингу немного иначе. Вы бы выбирали другие архитектурные решения, намеренно использовали другие шаблоны и придирчивее обрабатывали бы ошибки. Иными словами, вы бы двигались медленнее.
БОльшую часть времени нужно тратить на реальный продукт, а не на POC, которое продаёт вашу идею владельцу продукта.
Proof of concept должно передать вашу идею за как можно более короткий промежуток времени.
ПО пишется не одним человеком. Оно производится командой разнообразно мыслящих людей, что стимулирует творчество и продвигает инновации. POC чаще всего создаются одним человеком. Когда вы хотите реализовать настоящий продукт, то вам нужна команда, способная выложиться по максимуму и повысить его потенциал.
Оно не предназначено для этого
Ваше POC создавалось, чтобы проиллюстрировать суть. Это идея. Она не создавалась с расчётом на нагрузки продакшена.
Перед ремонтом дома вы набрасываете свои идеи на листе бумаги, чтобы показать их друзьям, семье и рабочим. Все понимают, чего вы хотите, но этот черновик с каракулями явно не стоит отдавать строителям.
Нет, вы попросите составить чертёж в CAD, всё просчитать, найти несущие нагрузку конструкции и формализовать проект, прежде чем к нему приступать.
Ваше proof of concept — это набросок на листе. Он выполнил свою цель и продемонстрировал чёткое направление, но в продакшене вы использовать его точно не будете. Его нужно проработать, правильно спроектировать, разбить на истории и задокументировать.
Если команда разработки использует методологии agile, то этот процесс будет выглядеть примерно так:
- Создаём POC.
- Демонстрируем его на обзоре спринта.
- Дожидаемся, пока аналитик не напишет полное решение.
- Разбиваем решение на отдельные истории, над которыми можно работать, повышающие коммерческую ценность продукта.
- Работаем над историями на протяжении нескольких спринтов.
Реализация этапов этого процесса гарантирует, что предприняты необходимые меры для создания ПО предназначенного для продакшена, обеспечивающего высокую надёжность и безопасность.
Proof of Concept хрупки
Вы отлично справились. Вы создали POC, единственное назначение которого — демонстрация работающего примера новой концепции. Его создание почти не заняло времени, и вашему руководству оно понравилось. Отлично!
Как и можно было ожидать, владелец продукта просит вас просто вывести его в продакшен, потому что, по его мнению, у вас уже есть работающий продукт.
Но вы-то знаете правду.
В нём нет обработки ошибок. Вы создали ПО, которое будет работать в идеальных условиях. Как только вы отклонитесь от реализованного в коде процесса, он сломается.
На обзоре спринта вы не отклоняетесь от сценария демонстрации, и на то есть причины. Если вы нажмёте кнопку X вместо кнопки Y, всё развалится. Но это нормально! Вы создали именно то, что и должны были создать. Proof of concept продемонстрировало именно то, что и должно было показать.
Хотя подобные ситуации в продакшене считаются багами, в proof of concept они багами не являются. Помните, это просто черновик, а не готовый чертёж.
Стоит ожидать, что вы столкнётесь с нехваткой фич, забавными багами, ошибками путей выполнения, дырами в безопасности и отсутствием наблюдаемостью системы. Всё, чего не хватает, появится позже, в реальной сборке. Но пока считайте, что в вашем POC больше дыр, чем в швейцарском сыре.
Во второй раз всегда получается лучше
Век живи — век учись. Практикуйся. В следующий раз повезёт.
Что общего у всех этих фраз?
Они подразумевают, что чем больше вы чем-то занимаетесь, тем лучше будут результаты.
Вы же не думаете, что спортсмены не тренируются перед соревнованиями? Конечно же, они тренируются, ожидая, что чем больше практикуешься, тем лучше проявишь себя.
Тот же принцип применим и к созданию ПО. Когда ты в первый раз что-то пишешь (например, POC), то находишься в фазе исследования. Изучаешь все аспекты, пытаясь собрать что-нибудь.
Во второй раз ты движешься быстрее, потому что узнал часть нюансов. Ты пишешь более производительный код, который проще поддерживать. Ты пишешь лучше.
Воспринимайте POC как поучительный урок. Проиллюстрируйте идею и научитесь кодировать концепцию. Найдите все подводные камни. Будьте готовы, что потом найдёте новые. Приготовьтесь к созданию более качественного ПО.
Заключение
Proof of concept всегда стоит потраченного на него времени. Даже если результат докажет, что вам не стоит использовать проверяемую концепцию, по крайней мере, вы не потратили на выяснение этого много времени.
POC дают нам шанс поэкспериментировать с чем-то новым и взвесить свои решения перед тем, как приступать к реализации. Но они не являются реализацией. Хотя иногда может возникать искушение встроить этот код в приложение в продакшене, не стоит этого делать.
Используйте proof of concept как отправную точку. Пользуйтесь его уроками как руководством, чтобы создать нечто лучшее. Ужесточите требования к тому, что вы сделали. А потом начинайте новую итерацию.
Не распыляйтесь при создании сборок POC. Создавайте их как можно быстрее. Тратьте максимально возможное время на работу над реальным ПО, обладающим безопасностью, устойчивостью к сбоям и надлежащей обработкой ошибок.
На правах рекламы
Серверы для разработчиков и не только! Недорогие VDS на базе новейших процессоров AMD EPYC и хранилища на основе NVMe дисков от Intel для размещения проектов любой сложности, создавайте собственную конфигурацию сервера в пару кликов!
оригинал
===========
Источник:
habr.com
===========
===========
Автор оригинала: Allen Helton
===========Похожие новости:
- [Анализ и проектирование систем, Системное программирование, Алгоритмы, C, Процессоры] 4K страницы: навсегда, на веки вечные
- [Управление разработкой, Agile] Have we ever been working by the Waterfall?
- [Тестирование IT-систем, Анализ и проектирование систем, Отладка] Язык моделирования Alloy и приключения с параллельными запросами к базе данных (перевод)
- [Программирование, Управление разработкой, Управление персоналом, DevOps] Стратегии выплаты технического долга (перевод)
- [Игры и игровые приставки] Самые зрелищные игры для тех, кто не любит играть (перевод)
- [Open source, Системное администрирование, IT-инфраструктура, Серверное администрирование] Мощный мониторинг за пять минут с помощью Glances
- [Анализ и проектирование систем, Проектирование и рефакторинг, Подготовка технической документации] О роли системного аналитика и шаблон для проектирования
- [Гаджеты, Настольные компьютеры, Ноутбуки, Периферия] Анатомия клавиатуры (перевод)
- [Управление разработкой, Управление проектами, Управление персоналом, История IT] −2000 строк кода (перевод)
- [Разработка веб-сайтов, Программирование, Анализ и проектирование систем, SQL, Прототипирование] Применяем NOCODE и LOWCODE для вычислений
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_upravlenie_razrabotkoj (Управление разработкой), #_poc, #_proof_of_concept, #_blog_kompanii_vdsina.ru (
Блог компании VDSina.ru
), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_upravlenie_razrabotkoj (
Управление разработкой
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:43
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Никогда не встречал разработчика, не любящего создавать всевозможные proof of concept (POC). Возможность построить что-то новое с нуля, чтобы протестировать теорию/процесс/технологию… Сама мысль об этом вдохновляет меня. Есть в них что-то, что стимулирует наше творческое мышление. Вероятно, это отсутствие всяческих ограничений. Может, быть, это просто восторг от разработки «с чистого листа». Как бы то ни было, разработчикам это нравится. Частично привлекательность создания proof of concept заключается в широте способов их применения. Можно создать POC для чего угодно! Хотите ли вы создать что-то забавное, научить кого-то незнакомой концепции, придумать идею для бизнеса или научиться использовать новую технологию для решения проблемы — варианты просто бесчисленны. Но стоит быть аккуратными со своими ожиданиями. Я постоянно вижу, как разработчиков просят просто брать в продакшен их POC. Не делайте этого! Proof of concept — это именно концепция. Это не «рабочая лошадка» для продакшена, соответствующая всем рекомендациям, общепринятым шаблонам и процессам разработки. Это инструмент для демонстрации идеи за короткий промежуток времени. Сегодня мы поговорим о четырёх причинах, по которым POC ни за что не должно попадать в продакшен. Продакшен изменяет способ разработки Один из удобных аспектов создания POC заключается в том, что вы не скованы привычными ограничениями разработки. Вы можете писать на любом языке, использовать «быстрые и грязные» решения, а также хардкодить. Не важно, как вы реализуете результат, если в результате сможете доказать свою правоту. Если бы вы предполагали, что POC будет использоваться в продакшене, то подходили бы к кодингу немного иначе. Вы бы выбирали другие архитектурные решения, намеренно использовали другие шаблоны и придирчивее обрабатывали бы ошибки. Иными словами, вы бы двигались медленнее. БОльшую часть времени нужно тратить на реальный продукт, а не на POC, которое продаёт вашу идею владельцу продукта. Proof of concept должно передать вашу идею за как можно более короткий промежуток времени. ПО пишется не одним человеком. Оно производится командой разнообразно мыслящих людей, что стимулирует творчество и продвигает инновации. POC чаще всего создаются одним человеком. Когда вы хотите реализовать настоящий продукт, то вам нужна команда, способная выложиться по максимуму и повысить его потенциал.  Оно не предназначено для этого Ваше POC создавалось, чтобы проиллюстрировать суть. Это идея. Она не создавалась с расчётом на нагрузки продакшена. Перед ремонтом дома вы набрасываете свои идеи на листе бумаги, чтобы показать их друзьям, семье и рабочим. Все понимают, чего вы хотите, но этот черновик с каракулями явно не стоит отдавать строителям. Нет, вы попросите составить чертёж в CAD, всё просчитать, найти несущие нагрузку конструкции и формализовать проект, прежде чем к нему приступать. Ваше proof of concept — это набросок на листе. Он выполнил свою цель и продемонстрировал чёткое направление, но в продакшене вы использовать его точно не будете. Его нужно проработать, правильно спроектировать, разбить на истории и задокументировать. Если команда разработки использует методологии agile, то этот процесс будет выглядеть примерно так:
Реализация этапов этого процесса гарантирует, что предприняты необходимые меры для создания ПО предназначенного для продакшена, обеспечивающего высокую надёжность и безопасность. Proof of Concept хрупки Вы отлично справились. Вы создали POC, единственное назначение которого — демонстрация работающего примера новой концепции. Его создание почти не заняло времени, и вашему руководству оно понравилось. Отлично! Как и можно было ожидать, владелец продукта просит вас просто вывести его в продакшен, потому что, по его мнению, у вас уже есть работающий продукт. Но вы-то знаете правду. В нём нет обработки ошибок. Вы создали ПО, которое будет работать в идеальных условиях. Как только вы отклонитесь от реализованного в коде процесса, он сломается. На обзоре спринта вы не отклоняетесь от сценария демонстрации, и на то есть причины. Если вы нажмёте кнопку X вместо кнопки Y, всё развалится. Но это нормально! Вы создали именно то, что и должны были создать. Proof of concept продемонстрировало именно то, что и должно было показать. Хотя подобные ситуации в продакшене считаются багами, в proof of concept они багами не являются. Помните, это просто черновик, а не готовый чертёж. Стоит ожидать, что вы столкнётесь с нехваткой фич, забавными багами, ошибками путей выполнения, дырами в безопасности и отсутствием наблюдаемостью системы. Всё, чего не хватает, появится позже, в реальной сборке. Но пока считайте, что в вашем POC больше дыр, чем в швейцарском сыре. Во второй раз всегда получается лучше Век живи — век учись. Практикуйся. В следующий раз повезёт. Что общего у всех этих фраз? Они подразумевают, что чем больше вы чем-то занимаетесь, тем лучше будут результаты. Вы же не думаете, что спортсмены не тренируются перед соревнованиями? Конечно же, они тренируются, ожидая, что чем больше практикуешься, тем лучше проявишь себя. Тот же принцип применим и к созданию ПО. Когда ты в первый раз что-то пишешь (например, POC), то находишься в фазе исследования. Изучаешь все аспекты, пытаясь собрать что-нибудь. Во второй раз ты движешься быстрее, потому что узнал часть нюансов. Ты пишешь более производительный код, который проще поддерживать. Ты пишешь лучше. Воспринимайте POC как поучительный урок. Проиллюстрируйте идею и научитесь кодировать концепцию. Найдите все подводные камни. Будьте готовы, что потом найдёте новые. Приготовьтесь к созданию более качественного ПО. Заключение Proof of concept всегда стоит потраченного на него времени. Даже если результат докажет, что вам не стоит использовать проверяемую концепцию, по крайней мере, вы не потратили на выяснение этого много времени. POC дают нам шанс поэкспериментировать с чем-то новым и взвесить свои решения перед тем, как приступать к реализации. Но они не являются реализацией. Хотя иногда может возникать искушение встроить этот код в приложение в продакшене, не стоит этого делать. Используйте proof of concept как отправную точку. Пользуйтесь его уроками как руководством, чтобы создать нечто лучшее. Ужесточите требования к тому, что вы сделали. А потом начинайте новую итерацию. Не распыляйтесь при создании сборок POC. Создавайте их как можно быстрее. Тратьте максимально возможное время на работу над реальным ПО, обладающим безопасностью, устойчивостью к сбоям и надлежащей обработкой ошибок. На правах рекламы Серверы для разработчиков и не только! Недорогие VDS на базе новейших процессоров AMD EPYC и хранилища на основе NVMe дисков от Intel для размещения проектов любой сложности, создавайте собственную конфигурацию сервера в пару кликов!  оригинал =========== Источник: habr.com =========== =========== Автор оригинала: Allen Helton ===========Похожие новости:
Блог компании VDSina.ru ), #_analiz_i_proektirovanie_sistem ( Анализ и проектирование систем ), #_upravlenie_razrabotkoj ( Управление разработкой ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:43
Часовой пояс: UTC + 5