03.05.2023 13:58
mixkorshun 2 2100 Источник

Вопрос скорости и качества стоит в разработке особенно остро. Мы привыкли думать, что чем больше времени было потрачено на разработку продукта, тем лучше результат, и наоборот. Но так ли это на самом деле?

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

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

Способ 1. Сокращаем возможности продукта

Главная задача MVP, да и практически любой фичи — решить какую-то проблему клиента. Подумайте, так уж ли важен весь тот функционал, который вы запланировали? От чего можно отказаться, чтобы сократить время разработки? Что все же придется воплотить в MVP?

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

Способ 2. Сокращаем количество поддерживаемых платформ и вариантов

Например, на первых порах вы можете выпустить только desktop приложение для Windows, или отказаться от поддержки изображений в любых форматах — ограничьтесь JPEG. Подчеркну, что здесь я имею в виду не продуктовые фичи как таковые (о них речь шла выше), а скорее их техническую реализацию.

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

def normalize_image(filename):
  if not filename.endswith(".jpg"):
    raise NotImplementedError()
  ...

Способ 3. Упрощаем тестирование

Самый очевидный вариант — сократить время на тестирование. Да, тщательно протестировать продукт в этом случае не получится. Но, возможно, для MVP будет достаточно провести лишь необходимый минимум тестов — проверить код локально и в staging среде перед релизом. 

Я очень рекомендую описать unit тесты, но не запускать их. Даже если вы просто опишите тест-кейсы, вы сможете увидеть недоработки и получить неочевидные инсайты для последующей проверки вручную. Это прекрасный пример того, как можно получить 80% результата выполнив 20% работы, особенно в краткосрочной перспективе. Например так это выглядит в Jest:

test.todo("form shows error messaage for invalid credentials")

test.todo("form redirects on success login")
test.todo("redirect supports _next query param")
test.todo("_next query param validates url")

Способ 4. Используем более простую архитектуру

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

Применительно к архитектуре можно обозначить два основных правила:

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

  • Чем более базовым является компонент, тем важнее его качество, и наоборот

И еще три важных совета:

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

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

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

Вывод

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

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

Комментарии (2)