Технический долг во встраиваемом ПО (firmware) – тихий убийца. Никто специально не пишет плохой код. Все начинают с чистой архитектурой и благими намерениями. Но под давлением сроков и задач код потихоньку превращается в лапшу, с которой становится невозможно работать. И, что важнее всего, это не проблема программистов, а проблема лидерства и менеджмента.
Как появляется этот долг?
Представьте себе идеальный многослойный пирог: драйверы, логика приложения, работа с железом. Всё разделено.
Но вот начинается аврал:
- Нарушение границ: Драйвер датчика, которому нужно быстро передать данные, начинает обращаться напрямую к приложению, минуя все промежуточные слои. Кажется, мелочь? Один раз можно.
- Глобальные переменные как клей: Чтобы связать то, что не должно быть связано, инженеры начинают использовать глобальные переменные. Это как если бы в доме снесли все перегородки и поставили одну общую дверь между спальней и кухней – вроде ходить удобно, но жить невозможно. Каждый глобал – это скрытая зависимость, о которой все забывают.
- Маскировка: один инженер гордился, что не пишет глобалов. Но вместо них у него были "классы-боги" (god classes), которые знали всё обо всех. По сути, те же глобалы, но в другой упаковке.
5 признаков того, что ваш код – уже "зомби"
Как понять, что вы тонете, ещё до того, как вода попала в легкие?
- Скорость упала до нуля. Раньше фичу делали за день, теперь за неделю. Код настолько запутан, что любое изменение тянет за собой правки в пяти других модулях.
- Поиск багов – это квест. Ошибка в модуле связи вызывает глюк в датчике температуры. Чтобы понять, где собака зарыта, нужно знать, как устроена вся система целиком. Границы между модулями стерлись.
- Жизнь в режиме "пожарной команды". Постоянные авралы, работа по выходным, срочные патчи. Вы не управляете разработкой, разработка управляет вами.
- Метрики кода кричат. Если вы отслеживаете объектно-ориентированные метрики (связанность, связность, цикломатическая сложность), их тренд будет неумолимо ползти в красную зону.
- Новички учатся полгода. Если опытному инженеру нужно 3 месяца, чтобы просто начать править код, дело не в сложности предметной области, а в том, что код – это свалка. Непонятно, где что лежит и как оно работает.
Почему на это забивают? (Честный ответ)
Потому что в бизнесе правят бал фичи.
Никому нет дела до того, что вы снизили цикломатическую сложность. Продуктового менеджера не волнует рефакторинг. За это не дают премий и не повышают. Бизнес говорит: "Мы видим, что вы много работаете, молодцы", но не видит связи между чистым кодом и деньгами.
Ирония: Команды, которые тушат пожары по выходным, – это те же команды, у которых "нет времени" на рефакторинг и код-ревью, которые бы эти пожары предотвратили.
Исследования и факты
Есть данные (Boehm, IBM и др.), что поддержка "грязного" кода обходится в 2-4 раза дороже, чем чистого. А во встраиваемых системах, где продукт живет 10-15 лет, это катастрофа.
Кстати, исследования спецслужб (NSA) и IBM показывают, что большинство ошибок сидят в малом количестве модулей. Их называют "фермами ошибок" (bug farms). Иногда проще выкинуть такой модуль и переписать, чем пытаться его лечить.
Что делать? 3 простых шага на этой неделе
Вот пошаговая стратегия:
Шаг 1. Сделайте долг видимым (Включите свет в темной комнате)
Нельзя управлять тем, чего не видишь. Чувство, что "код стал грязным", не работает. Нужны цифры.
Начните гонять статический анализатор кода в вашей CI/CD системе. Пусть он считает:
- Связанность (coupling).
- Связность (cohesion).
- Цикломатическую сложность.
Смотрите, в каких модулях эти цифры зашкаливают. Сравните это с тем, где чаще всего падают баги. Это и есть ваши самые больные места.
2. Введите "легкие" код-ревью (Спасите код за 15 минут)
Не надо устраивать многочасовые заседания. Достаточно одного проверяющего и 15 минут времени. Главное – задавать правильные вопросы:
- Не ломает ли этот код архитектурные границы?
- Не появилась ли тут новая глобальная переменная?
- Не привязали ли мы сейчас то, что должно быть независимым?
Если ответ "да" на любой из вопросов, у вас начинается диалог. Это важнее любой автоматической проверки.
3. Почините одну границу (Не пытайтесь объять необъятное)
Обычно команды смотрят на руины архитектуры и думают: "Это невозможно исправить". И не делают ничего.
Не надо чинить всё. Почините одну стену.
Найдите самое больное место. Например, кусок кода, где приложение напрямую дергает драйвер. Отгородите их обратно. Сделайте интерфейс. Это займет несколько часов, а не недель.
Если граница продержится несколько спринтов – беритесь за следующую. Через полгода у вас снова появится архитектура.
Главный вывод
Технический долг – это не инженерная проблема, а проблема руководства.
Инженеры копят долг, потому что менеджеры ставят сроки, не закладывая время на качество.
Менеджеры наследуют долг, потому что им не показали метрики.
Мысленный эксперимент напоследок:
- Сколько времени займет добавление новой функции в ваш код?
- А сколько времени должно занимать?
Разница между этими цифрами – и есть ваш технический долг. Выраженный в самом главном ресурсе – времени.
Ссылка на первоисточник: https://www.designnews.com/embedded-systems/technical-debt-is-eating-your-firmware-alive-3-steps-to-fight-back
Вас также могут заинтересовать: