В статье рассматривается вопрос целесообразности использования быстрых архитектурных решений в проектах инновационного типа. Основной тезис статьи в том, что осознанное использование концепции технического долга на ранних стадиях высокорискованных программных разработок позволяет получить экономию финансовых и трудовых ресурсов. Рефакторинг, т. е. улучшение и оптимизация программной архитектуры, является важной составляющей процесса разработки, но заниматься ею целесообразно после верификации бизнес-модели. На ранних этапах, предшествующих подтверждению бизнес-гипотез относительно рынка сбыта, глубокий рефакторинг может замедлить выпуск прототипа и увеличить бюджет проекта, еще до подтверждения его коммерческого потенциала. Данное утверждение справедливо с учетом некоторых оговорок. Участники процесса должны понимать концепцию технического долга и использовать его осмысленно. Даже на ранних этапах проекта, еще до верификации бизнес-модели можно существенно осложнить разработку, если совсем не уделять внимания внутреннему качеству кода. Если технический долг тормозит разработку проекта, если ставит под угрозу его запуск или привносит в систему нестабильность, то он неприемлем. Есть три области программной инженерии, в которых может накапливаться технический долг: на уровне модели предметной области, на уровне программной архитектуры, на уровне программного кода. Каждый из этих уровней несет в себе потенциальную возможность накопления технического долга, и каждую из них нужно контролировать. Наиболее трудоемок и затратен рефакторинг на первом и втором уровнях. Здесь в первую очередь нужно сокращать затраты (до подтверждения бизнес-модели), однако это не всегда возможно. Исключение составляют случаи поиска продукта/услуги, т. е. те случаи, когда проработка проекта, его уточнение происходит в процессе разработки
Ключевые слова
технический долг, программный проект, разработка программных систем, программная архитектура, рефакторинг, стартап