Когда я думаю о техническом долге, я до сих пор вспоминаю первое созданное мной приложение, которое заставило меня осознать последствия неподходящей архитектуры. Это произошло еще в конце 1990-х годов, когда я только начинал работать консультантом.  Клиент запросил использование платформы   для создания системы закупок для своих клиентов. Используя клиент Lotus Notes и специальное приложение, конечные пользователи могли делать запросы, которые отслеживались приложением и выполнялись командой владельца продукта. Теоретически это была действительно классная идея, особенно учитывая, что веб-приложения не были распространены, и все использовали Lotus Notes ежедневно. Lotus Notes  Основная проблема заключается в том, что данные были очень реляционными по своей конструкции, а Lotus Notes не был реляционной базой данных. Конструкция решения требовала управления схемой в каждом документе Lotus Notes и опиралась на ряд полей с несколькими значениями для моделирования отношений между атрибутами данных. Это был беспорядок.  Если бы была рекомендована более совершенная платформа, в приложении Lotus Notes не потребовалось бы много логики. Исходный код было сложно поддерживать. Улучшения структуры данных привели к серьезному рефакторингу базового кода, не говоря уже о запуске серверных заданий для преобразования существующих данных. Не заставляйте меня рассказывать о создании отчета.  С самого начала своей карьеры я сосредоточился на предоставлении решения, которое хотел клиент, а не на попытках предложить лучшее решение. Это, безусловно, был урок, который я усвоил в начале своей карьеры, но за годы, прошедшие после этого проекта, я пришел к выводу, что последствием архитектурного технического долга является печальная реальность, с которой мы все сталкиваемся.  Давайте немного подробнее рассмотрим концепцию архитектурных и технологических долгов на макроуровне.  Архитектурный технический долг (ATD)  Библиотека архитектурно-технического долга (ATD) Университета Карнеги-Меллон дает следующее   ATD: определение  Архитектурный технический долг — это подход к проектированию или строительству, который целесообразен в краткосрочной перспективе, но создает технический контекст, в котором одна и та же работа требует архитектурной переделки и требует больше затрат на ее выполнение в будущем, чем ее выполнение сейчас (включая увеличение затрат с течением времени). .  В документе «Краткий ответ: как управлять техническим долгом архитектуры» (опубликовано 22 сентября 2023 г.) Gartner Group определяет ATD следующим образом:  Технический долг архитектуры — это тот тип технического долга, который вызван архитектурным дрейфом, неоптимальными архитектурными решениями, нарушениями определенной целевой архитектуры продукта и устоявшихся передовых отраслевых архитектурных практик, а также компромиссами в архитектуре, направленными на более быструю доставку программного обеспечения.  В обоих случаях выгоды, которые часто приносят краткосрочное празднование, могут быть встречены долгосрочными проблемами. Это похоже на мой пример Lotus Notes, упомянутый во введении.  Ситуация еще больше усложняется тем, что по сравнению с другими аспектами разработки программного обеспечения отсутствуют инструменты, помогающие выявлять и управлять техническим долгом для архитектуры программного обеспечения: Для обеспечения качества кода, наблюдаемости и SCA существуют проверенные инструменты, такие как Sonarqube, Datadog, New Relic, GitHub и Snyk. Однако сегмент архитектуры программного обеспечения отстает и не имеет проверенных решений.  Это прискорбно, учитывая тот факт, что ATD неизменно является самым крупным и наиболее разрушительным типом технического долга, как указано в документе «   », исследование 2015 года, опубликованное Карнеги-Меллоном. Измерить? Управляй этим? Игнорируй это? Специалисты по программному обеспечению и технический долг  На следующей иллюстрации резюмируется рисунок 4 из этого отчета, и делается вывод о том, что неправильный выбор архитектуры был явным лидером в источниках технического долга.  Если не принять меры, ATD может продолжать расти с возрастающей скоростью, как показано на этой простой иллюстрации:  Без смягчения последствий долг архитектуры в конечном итоге достигнет критической точки для измеряемого базового решения.  Управление АТД  Прежде чем мы сможем справиться с АТД, мы должны сначала понять проблему.   однажды мудро сказал: «Есть только один способ съесть слона: по кусочку». Десмонд Туту  Подход со сдвигом влево охватывает концепцию перемещения данного аспекта ближе к началу, чем к концу жизненного цикла. Эта концепция приобрела популярность благодаря сдвигу влево для тестирования, когда фаза тестирования была перенесена в часть процесса разработки, а не в отдельное событие, которое должно быть завершено после завершения разработки.  Shift-left можно реализовать двумя разными способами при управлении ATD:  Сдвиг-влево для устойчивости — выявление источников, влияющих на устойчивость, а затем их исправление до того, как они проявятся в производительности.  Сдвиг-влево для безопасности — обнаружение и устранение проблем безопасности в ходе жизненного цикла разработки.  Точно так же, как сдвиг влево при тестировании, приоритетное внимание к устойчивости и безопасности на этапе разработки снизит вероятность неожиданных инцидентов.  Архитектурная наблюдательность  Архитектурная наблюдаемость дает инженерным командам возможность постепенно устранять архитектурные отклонения в своих сервисах на макроуровне. Фактически, в начале этого года газета Wall Street Journal сообщила, что стоимость устранения технического долга составила 1,52 триллиона долларов США в   «Невидимая проблема стоимостью 1,52 триллиона долларов: неуклюжее старое программное обеспечение». статье  Чтобы добиться успеха, инженерное лидерство должно полностью соответствовать следующим организационным целям:  Устойчивость — быстрое восстановление после неожиданных инцидентов.  Масштабируемость — масштабирование в соответствии с требованиями клиентов.  Velocity — предоставление функций и улучшений в соответствии с ожиданиями продукта.  Пригодность для облака — преобразование устаревших решений в эффективные предложения облачных услуг.  Недавно я обнаружил платформу   для наблюдения за архитектурой, управляемую искусственным интеллектом, которая ориентирована на следующие результаты: vFunction    реальную архитектуру решений посредством статического и динамического анализа. Откройте для себя    дрейф архитектуры с помощью просмотра в реальном времени того, как развиваются сервисы. Предотвратите  Повышайте   приложений за счет устранения ненужных зависимостей и улучшений между доменами приложений и связанными с ними ресурсами. отказоустойчивость  Управляйте техническим долгом и   с помощью наблюдения на основе искусственного интеллекта. погашайте его  Кроме того, платформа vFunction обеспечивает дополнительное преимущество, предоставляя путь миграции для перехода от монолитных решений к облачным решениям. Как только команды модернизируют свои платформы, они смогут постоянно наблюдать за их постоянным дрейфом. Если у компаний уже есть микросервисы, они могут использовать vFunction для обнаружения сложности в распределенных приложениях и устранения зависимостей, влияющих на отказоустойчивость и масштабируемость. В любом случае, после реализации, команды инженеров смогут смягчить ATD задолго до того, как будет достигнута критическая точка. На приведенном выше рисунке команды разработчиков могут уменьшить технический долг в рамках каждого выпуска благодаря реализации платформы vFunction и лежащему в ее основе подходу «сдвиг влево».  Заключение  Мои читатели, возможно, помнят, что я сосредоточился на следующей формулировке миссии, которая, по моему мнению, может быть применима к любому ИТ-специалисту:  «Сосредоточьте свое время на предоставлении функций/функций, которые увеличивают ценность вашей интеллектуальной собственности. Используйте платформы, продукты и услуги для всего остального». - Дж. Вестер  Платформа vFunction соответствует моему заявлению о миссии, помогая инженерным группам использовать подход, основанный на сдвиге влево, к отказоустойчивости и безопасности своих сервисов на макроуровне. Это важное различие, поскольку без таких инструментов команды, скорее всего, будут смягчать последствия на микроуровне, решая технологический долг, который на самом деле не имеет значения с организационной точки зрения.  Когда я вспоминаю то приложение, которое заставило меня осознать проблемы, связанные с техническим долгом, я не могу не думать о том, что это решение принесло больше проблем, чем принесло пользы, с каждой введенной функцией. Конечно, использование сдвига влево только для обеспечения устойчивости помогло бы выявить проблемы с базовой архитектурой в тот момент, когда затраты на рассмотрение альтернатив были бы осуществимы.  Если вам интересно узнать больше о решении vFunction, вы можете прочитать о них больше   . здесь  Хорошего дня!

This story contains new, firsthand information uncovered by the writer.

2022 - HackerNoon Contributor of the Year - Cloud Computing

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Javascript

2022 - HackerNoon Contributor of the Year - Salesforce

2022 - Hackernoons Tech Storyteller of the Year

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

Этот звук создан на языке оригинала истории!

Слишком долго; Читать

Make resilience your competitive advantage

Управление долгом за архитектурные технологии

About Author

КОММЕНТАРИИ

БИРКИ

ЭТА СТАТЬЯ БЫЛА ПРЕДСТАВЛЕНА В

Related Stories

Модель Bitcoin UTXO, обеспечивающая работу уникальной экосистемы

Краткое введение в теорию мозга Больцмана

Рост криптовалют: создание эффективных образов пользователей

Нажмите, чтобы заработать: Telegram может привлечь следующие 10 миллиардов пользователей криптовалюты до Соланы

Модель Bitcoin UTXO, обеспечивающая работу уникальной экосистемы

Краткое введение в теорию мозга Больцмана

Рост криптовалют: создание эффективных образов пользователей

Нажмите, чтобы заработать: Telegram может привлечь следующие 10 миллиардов пользователей криптовалюты до Соланы

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps