### Тестирование и сбои программного обеспечения
Удивительно, но разработчики действительно тестируют свое программное обеспечение. Несмотря на многочисленные сбои в этом году, средний разработчик тратит 42% своего рабочего времени на обслуживание кода. Тогда почему же происходят сбои?
В 2024 году были существенные сбои, которые затронули доставку фастфуда, работу WhatsApp и Instagram, привели к проблемам в аэропорту Хитроу и остановили поставки свежих продуктов на границе после Брексита.
### Причины сбоев
Эти сбои произошли не из-за отсутствия тестирования со стороны разработчиков. Они появились из-за чрезмерной сложности конфигурации программного обеспечения. Вносятся многочисленные изменения продуктами различными людьми и по разным причинам, что делает кодовую базу трудной для понимания.
Многие компании тестируют код в рамках архитектуры ПО, которую уже никто не понимает. Это похоже на огромную башню из Дженги, при добавлении нового элемента которой она может обрушиться. Никто не хочет прикасаться к этому, и почти никто не помнит, как всё было построено. И вот вдруг кто-то решает: «продукту нужна искусственный интеллект.»
### Вечное противостояние в разработке ПО
В этой ситуации мы сталкиваемся с извечной проблемой программной инженерии: инновации против обслуживания, которая постепенно разрушает сами основы программного обеспечения по всему миру.
### Почему программы изнашиваются?
Наш софт со временем подвержен эрозии, будто горные породы. В этом виноват «ад зависимостей» – когда новый код добавляется к уже существующему, влияя на другие части продукта. Это зачастую происходит под давлением руководства, стремящегося опередить конкурентов, или разработчиков, пытающихся оптимизировать рабочие процессы.
Когда разработчику поручают добавить новую функцию, она увеличивает кодовую базу. Для ускорения работы добавляется кратчайший путь, увеличивающий сложность. Руководство требует расширения продукта, и оказывается, что предыдущий кратчайший путь несовместим с обновлением. Происходят поломки, разработчик начинает исправления, и это продолжается по кругу.
### Человеческая цена изношенности софта
Если более 40% времени уходит на поддержание кода, это не добавляет ценности продукту. Учитывая встречи, комментарии и обратную связь, времени на инновации остаётся меньше половины недели.
Для менеджера по разработке это катастрофа: только половина времени команды тратится на развитие. Для разработчиков это приводит к отсутствию удовлетворения от работы, постоянные поломки кода и последующие скандалы в прессе бьют по моральному духу.
Далее происходит текучка кадров, новичков сложно интегрировать в проект, что затягивает сроки вывода продукта на рынок и вызывает недовольство всех участников процесса. Старые ошибки возвращаются, уходят опытные сотрудники, и каждая следующая итерация становится всё сложнее.
### Исправление концепции «shift left»
Много говорилось о концепции «shift left» – переносе тестирования на более ранние этапы разработки, но не все компании её правильно применяют. Решение проблемы состоит в том, чтобы не просто добавлять время на тестирование в расписание разработчиков. Иногда нанимаются внешние тестеры, но это лишь временное дорогостоящее решение.
Позднее исправление бывает гораздо дороже. Самое дешевое решение – правильная архитектура на этапе проектирования. Интегрируйте проверку качества на самом начальном этапе разработки, не после написания кода. Это особенно важно при построении жизнеспособного бизнеса, привлекающего клиентов. Плохая архитектура может привести к катастрофическим последствиям: увеличению сроков разработки, затратам, выгоранию команды.
### Достижение качества кода
Для качественного кода нужна многоуровневая проверка: статический анализ кода, функциональные тесты, проверка зависимостей и взаимодействия компонентов. Нужно понимать, как строится и взаимосвязан код. Если это невозможно сделать сразу, внедряйте методы поэтапно.
Разные роли в разработке имеют разные стимулы. Разработчики могут сопротивляться статическому анализу кода, воспринимая его как дополнительную работу. Важно рано определить, чья это ответственность.
С учётом учащающихся сбоев и ошибок, необходимо понимать, как была построена «башня из Дженги». С небольшим контролем это возможно изменить, иначе система рано или поздно рухнет.
Источник: TechRadar
