Влияние добавление функционала на проекты по разработке программного обеспечения

Добавление функций в программный продукт всегда вызывает дополнительные изменения в проекте, а эти изменения не всегда очевидны. Влияние расширения функционала на различные аспекты разработки зависит и от того, когда изменения поступили, и от того, каков их объём, и от их связанности с другими функциями программного продукта.

Сложность разработки при увеличении числа функциональных возможностей возрастает нелинейно

То есть сложность разработки комплексного продукта с множеством функций выше, нежели сложность реализации эти функций изолированно. Усложнение проявляется сильнее, если функции тесно взаимосвязаны между собой: реализация 2х функций по отдельности может занимать не так уж и много времени, а вот на работы по обеспечению их взаимодействия может уходить в разы больше ресурсов. А сложность, в свою очередь, влияет на стоимость и сроки разработки.

Большее количество функций порождает большее количество ошибок

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

Динамичное и интенсивное добавление функций приводит к снижению надёжности системы

Высокий темп внесения изменений всегда приводит к снижению стабильности программной системы. Любой добавленный функционал требует тестирования и «обкатки» для выявления и исправления ошибок, а это немало времени, которого часто просто нет. Также стоит отметить тот факт, что затраты на тестирование и отладку не только временные, но и финансовые. Любой релиз — это всегда затраты времени и денег на его подготовку, тестирование и запуск. Таким образом, если продукт должен очень динамично обновляться, то надо предусмотреть и затраты на этот процесс.

Архитектура программных продуктов не всегда выдерживает кардинальные изменения

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

Тематические статьи

Как зависит качество разработанного сайта от количества выделенных ресурсов и менеджмента проекта?

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

экономика
веб-разработка
управление проектами
управление продуктами
Статья опубликована в 2014 году

Использование экономических критериев в веб‑разработке для оценки целесообразности реализации

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

управление продуктами
управление проектами
веб-разработка
Статья опубликована в 2014 году

SOLID — принципы объектно‑ориентированного программирования

SOLID это аббревиатура пяти основных принципов проектирования в объектно‑ориентированном программировании, предложенных Робертом Мартином:

  • Single responsibility — принцип единственной ответственности
  • Open-closed — принцип открытости / закрытости
  • Liskov substitution — принцип подстановки Барбары Лисков
  • Interface segregation — принцип разделения интерфейса
  • Dependency inversion — принцип инверсии зависимостей
веб-разработка
методологии разработки
бэкенд
Статья опубликована в 2019 и обновлена в 2023 году

Принцип программирования YAGNI — «Вам это не понадобится»

Принцип заключается в том, что возможности, которые не описаны в требованиях к системе, просто не должны реализовываться.

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

методологии разработки
веб-разработка
бэкенд
фронтенд
Статья опубликована в 2019 и обновлена в 2023 году

Принцип программирования KISS — делайте вещи проще

KISS — это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности.

Большая часть программных систем необосновано перегружена практически ненужными функциями, что ухудшает удобство их использование конечными пользователями, а также усложняет их поддержку и развитие разработчиками. Следование принципу KISS позволяет разрабатывать решения, которые не обладают этими недостатками: они просты в использовании и в сопровождении.

методологии разработки
фронтенд
бэкенд
веб-разработка
Статья опубликована в 2019 и обновлена в 2023 году

Принцип программирования DRY — don’t repeat yourself / не повторяйте себя

Следование принципу DRY позволяет добиться высокой сопровождаемости программного продукта: внесение изменений и тестирование значительно упрощаются.

Если код не дублируется, то для изменения логики достаточно внесения исправлений всего в одном месте. Также значительно проще тестировать одну (пусть и более сложную) функцию, а не набор из десятков однотипных. При следовании DRY упрощается и повторное использование функций, вынесенных из сложных алгоритмов, что позволяет сократить время разработки и тестирования новой функциональности.

веб-разработка
бэкенд
фронтенд
методологии разработки
Статья опубликована в 2018 и обновлена в 2023 году

​Создание сайта быстро, дешево, индивидуально и качественно

Альтернативное название статьи: «Ищем в стоге сена отсутствующую там иголку».

экономика
веб-разработка
управление продуктами
управление проектами
Статья опубликована в 2014 году

Иллюзорные гарантии в разработке и продвижении сайтов

​Давайте рассмотрим «иллюзорные» гарантии, которые вроде как присутствуют в том или ином виде, но на самом деле их нет.

управление проектами
SEO
интернет-маркетинг
Статья опубликована в 2014 году

Рефакторинг — это неизбежный процесс

Рефакторинг или реорганизация кода — процесс изменения внутренней структуры программного продукта, не затрагивающий её внешнего поведения и имеющий целью облегчение понимания программного кода и, пусть и не всегда, оптимизацию производительности.

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

методологии разработки
веб-разработка
Статья опубликована в 2019 году

Используемые технологии

Наши услуги