Добавление функций в программный продукт всегда вызывает дополнительные изменения в проекте, а эти изменения не всегда очевидны. Влияние расширения функциональности на различные аспекты разработки зависит и от того, когда изменения поступили, и от того, каков их объём, и от их связанности с другими функциями программного продукта.
То есть сложность разработки комплексного продукта с множеством функций выше, нежели сложность реализации эти функций изолированно. Усложнение проявляется сильнее, если функции тесно взаимосвязаны между собой: реализация 2х функций по отдельности может занимать не так уж и много времени, а вот на работы по обеспечению их взаимодействия может уходить в разы больше ресурсов. А сложность, в свою очередь, влияет на стоимость и сроки разработки.
Не существует сложных программных систем, вовсе не содержащих ошибок. И зависимость от функциональности тут прямая — чем больше реализовано возможностей в продукте и чем более сложной является бизнес‑логика, тем больше количество ошибок и тем выше вероятность сбоев. Ошибки в ПО, разумеется, выявляются и исправляются, но часто это происходит уже после выпуска программного продукта. Особенно часто остаются скрытыми ошибки, связанные с интеграцией нескольких компонентов между собой — количество комбинаций граничных условий для проверки всех возможных вариантов взаимодействия может превышать все разумные пределы.
Высокий темп внесения изменений всегда приводит к снижению стабильности программной системы. Любая добавленная функциональность требует тестирования и «обкатки» для выявления и исправления ошибок, а это немало времени, которого часто просто нет. Также стоит отметить тот факт, что затраты на тестирование и отладку не только временные, но и финансовые. Любой релиз — это всегда затраты времени и денег на его подготовку, тестирование и запуск. Таким образом, если продукт должен очень динамично обновляться, то надо предусмотреть и затраты на этот процесс.
Если программный продукт изначально разрабатывался под одни задачи, а потом было принято решение серьёзно изменить или усложнить бизнес‑логику, то заложенная изначально архитектура может уже не подходить под новые непредвиденные задачи и переделки потребуют уже реализованные компоненты. В этом случае бюджет и сроки проекта по разработке возрастают опять же нелинейно относительно сложности задачи.
Тематические статьи
Самый простой ответ на этот вопрос: прямо пропорционально. На разработку действительно хорошего проекта требуется много времени и денег, а плохой проект можно и «на коленке» за пару часов собрать. При профессиональном менеджменте результат проекта гарантированно лучше, чем в случае, когда менеджмента нет или он неэффективный. Но есть нюансы и влияние этих факторов достаточно нелинейно.
В этой статье будут затронуты некоторые особенности разработки и поддержки ПО, которые основываются на экономических критериях оценки целесообразности.
SOLID это аббревиатура пяти основных принципов проектирования в объектно-ориентированном программировании, предложенных Робертом Мартином:
Принцип заключается в том, что возможности, которые не описаны в требованиях к системе, просто не должны реализовываться. YAGNI основан на идее, что большинство «гипотетических» возможностей, которые кажутся полезными на этапе проектирования, никогда не будут востребованы. Реализуя их заранее, разработчики тратят время, усложняют код и повышают риск ошибок.
KISS — это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности. Большая часть программных систем необосновано перегружена практически ненужными функциями, что ухудшает удобство их использование конечными пользователями, а также усложняет их поддержку и развитие разработчиками. Следование принципу KISS позволяет разрабатывать решения, которые не обладают этими недостатками: они просты в использовании и в сопровождении.
Следование принципу DRY позволяет добиться высокой сопровождаемости программного продукта: внесение изменений и тестирование значительно упрощаются. Если код не дублируется, то для изменения логики достаточно внесения исправлений всего в одном месте. Также значительно проще тестировать одну (пусть и более сложную) функцию, а не набор из десятков однотипных. При следовании DRY упрощается и повторное использование функций, вынесенных из сложных алгоритмов, что позволяет сократить время разработки и тестирования новой функциональности.
Альтернативное название статьи: «Ищем в стоге сена отсутствующую там иголку». Невозможно сделать разработку сайта одновременно и быстрой, и дешевой, и индивидуальной, и качественной.
Рефакторинг или реорганизация кода — процесс изменения внутренней структуры программного продукта, не затрагивающий её внешнего поведения и имеющий целью облегчение понимания программного кода и, пусть и не всегда, оптимизацию производительности. В основе рефакторинга лежит последовательность небольших преобразований программного кода, сохраняющих его поведение. Вся последовательность этих изменений поизводится для улучшения сопровождаемости кодовой базы. Обычно рефакторинг производится под контролем прохождения автоматизированных тестов.
Используемые технологии
Наши услуги
РазработкаРазрабатываем сложные веб‑приложения и сайты. Создаём как отдельные инструменты для бизнеса, так и полноценные цифровые системы по индивидуальным требованиям.
ЦифровизацияФормализуем и автоматизируем бизнес‑процессы, осуществляем системную интеграцию, разрабатываем и внедряем цифровые решения, повышающие эффективность бизнеса.
Поддержка проектов и DevOpsОсуществляем комплексную поддержку ИТ‑проектов для обеспечения высокой работоспособности и улучшения продуктовых метрик.
Техническая поддержкаОбеспечиваем быструю и бесперебойную работу сайтов и веб‑приложений.
Информационная безопасностьУ нас богатый опыт в защите интернет-проектов от угроз в сфере информационной безопасности. Выстраиваем процессы ИБ и обеспечиваем полноценную защиту информационных систем от взломов и атак.
