Накопление технического долга является фактором затрат в продвинутых проектах. Вот несколько советов, как их уменьшить
Введение
Технический долг — это метафора, обычно используемая в компьютерных науках для обозначения возможных последствий плохой технической реализации программного обеспечения.
Что касается плохого дизайна программного обеспечения, влияние накопленного технического долга такое же, как описывает Мартин Фаулер в Гипотезе выносливости дизайна.
Если говорить короткими предложениями, то в результате увеличивается время реализации новой функциональности. И становится сложнее добавить функциональность. Последствия — больше усилий, больше затрат, повышенная нестабильность системы, больше сбоев, больше ошибок, сложность и т. д.
Советы по минимизации и сокращению технического долга
Рефакторинг
Самое главное для сокращения технического долга — это регулярный рефакторинг вашего программного обеспечения.
Грубо говоря, процесс разработки программного обеспечения состоит из двух этапов:
1. выполнение требований и запуск программного обеспечения
2. оптимизация и очистка кода.
Во многих проектах сроки укладываются с выполнением пункта 1. Для пункта 2 оптимизация и чистка кода часто времени нет. В результате через несколько лет программные системы этих проектов трудно поддерживать.
В современных Scrum-проектах проблема заключается в том, что Scrum Master часто сосредотачивается на предоставлении новых функций.
Если ваш скрам-мастер считает сокращение технического долга и/или время рефакторинга техническими вещами, не имеющими отношения к владельцам продукта, то у вас действительно проблемы.
То же самое происходит, когда ваш владелец продукта думает, что это технические вещи, и не заинтересован в результатах рефакторинга.
Одна из возможностей состоит в измерении улучшений рефакторинга. Это может заключаться в уменьшении количества строк кода, улучшении времени отклика вашего приложения, меньшем количестве ошибок и меньшем количестве совещаний по эскалации.
Кроме того, это может привести к снижению затрат на инфраструктуру. В конце концов, большинство оптимизаций должны измеряться деньгами.
Для рефакторинга вы также можете использовать инструменты, которые показывают возможные области улучшения. Одним из возможных инструментов для демонстрации возможностей улучшения является SonarQube.
Использование программных инструментов анализа
На сегодняшний день существует множество инструментов для анализа качества кода. Одна из хороших возможностей — включить эти инструменты в конвейер доставки и позволить ему работать при каждом изменении.
Расширенный уровень заключается в том, что инструменты используются вашими разработчиками на их локальных рабочих станциях, а проверки выполняются при каждом сохранении изменений. Причина в том, что чем раньше будет замечена проблема качества, тем дешевле ее исправить.
Существуют различные области для сканирования инструментами:
Анализ кода
Линтинг важен для уменьшения количества ошибок и улучшения общего качества вашего кода. Использование инструментов lint может помочь вам ускорить разработку и снизить затраты за счет создания чистого кода. Если код чистый, риск ошибок снижается.
Также доступны линтеры кода для файлов Dockerfile, файлов конфигурации и т. д.
Сканеры качества
SonarQube — это один из вариантов, и вы также можете добавить его в свой конвейер. SonarQube также поддерживается такими инструментами интеграции, как GitLab.
https://docs.sonarqube.org/latest/analysis/gitlab-integration/
Сканеры безопасности
Рекомендуется проверить используемые вами пакеты и зависимости. Часто версии необходимо заменить обновлениями, чтобы исправить вновь обнаруженные проблемы безопасности. Доступны различные инструменты, такие как Mend, ранее WhiteSource, Fortify или Snyk управления безопасностью с открытым исходным кодом.
Есть много других сканеров. Может быть, вы знаете лучше.
Сканеры аудита
Некоторые платформы предлагают функции для проверки качества вашего кода на основе конкретного языка. Например, аудит npm для Node.js или инструменты Java, такие как JArchitect. Также для Python доступны несколько инструментов статического анализа кода.
Внутренний/внешний аудит
Полезный способ доказать качество вашей программной системы — попросить других высказать свое мнение и высказать свое мнение. Обмен и общение ведут к обучению и совершенствованию.
Один из простых способов — проверка кода. Проблема с проверками кода коллегами часто заключается в нехватке времени и понимания того, как сделать эффективную проверку кода. Новичкам может быть полезен список важных моментов, на которые следует обратить внимание.
Вы можете добавить в свою команду одного продвинутого разработчика с основной функцией делать обзоры. Это может улучшить качество.
Вы можете попросить другую команду сделать обзор, если вы работаете в компании с большим количеством команд и разработчиков. В некоторых крупных компаниях есть специализированные группы для проверки и аудита.
Внешний аудит может быть чрезвычайно поучительным, если он того стоит для вашего руководства. Обычно команде внешнего аудита требуется поддержка членов вашей команды разработчиков.
Процесс заключается в том, что они объясняют систему и предоставляют код. Аудиторская специализированная компания часто имеет более развитое программное обеспечение для анализа. Кроме того, есть интервью с членами команды разработчиков.
Результатом является отчет о состоянии качества вашей программной системы и области улучшения, а также представление результатов команде разработчиков со списком советов по улучшению.
Использование шаблонов
Использование шаблонов программного обеспечения обычно снижает технический долг.
Например, использование паттерна Модель-представление-презентатор (MVP). Этот шаблон отличается модульностью, тестируемостью, а также чистой и удобной кодовой базой.
Существует множество чистых шаблонов кода. Вот несколько идей:
Если вы хотите больше, вы можете ознакомиться с принципами SOLID для чистого кода.
Руководство для разработчиков
Как вы могли видеть из предыдущей главы, количество паттернов и принципов огромно. Для команды разработчиков практически невозможно самостоятельно сосредоточиться на наиболее подходящих шаблонах и принципах для разработки и улучшения конкретной программной системы.
Команде разработчиков может быть предоставлена помощь с индивидуальными рекомендациями для конкретного проекта разработки.
Руководство разработчика должно быть максимально кратким и сосредоточено на основных аспектах. Это могут быть принципы и шаблоны, актуальные для конкретного проекта, например:
- соглашения о коде, соглашения об именах
- разработка через тестирование и как обрабатывать исключения
- язык для комментариев, классов и т. д.
- правила для стандартных сообщений фиксации
- сканеры качества кода для ваших программных систем и их конфигурации
- использование парного программирования
- и многое другое
Если вы хотите получить некоторые идеи о том, что может быть частью руководства для разработчиков, вы можете найти некоторые подсказки здесь:
Принципы и правила архитектуры программного обеспечения
Использование принципов архитектуры может помочь уменьшить технический долг, поскольку дает командам разработчиков общие правила и рекомендации по использованию ИТ-ресурсов с точки зрения высокого уровня.
Одним из примеров принципа архитектуры программного обеспечения является первый принцип API, в результате которого одна программная система может быть более легко интегрирована в другие программные системы. Результат — гибкость. Технический эффект заключается в том, что дизайн должен быть адаптирован для предоставления API.
Другой принцип заключается в уменьшении сложности. Сложность можно найти в дизайне программного обеспечения, обеспечении функциональности и используемой инфраструктуре. Сложность также можно уменьшить за счет чистого кода. Рефакторинг для уменьшения сложности приводит к более простому запуску системы в производственной среде с меньшим количеством проблем.
Это не конец советов по сокращению технического долга, а конец этой статьи. Пожалуйста, дайте мне знать, если я что-то пропустил, и поделитесь своим опытом.
