Технический долг — один из самых популярных сегодня терминов. Люди говорят: «Мы быстро развиваем свой MVP, минимизируя технический долг!» Они говорят о техническом долге, чтобы звучать круто или выделиться.

А я просто смеюсь, ведь всё рано или поздно превращается в технический долг.

Вся моя карьера теперь стала техническим долгом или кодом, который перестали поддерживать.

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

▍ Сначала это был Basic…

Я начал свою карьеру как разработчик на Visual Basic 6. С 1999 по 2003 год я создал множество разных приложений. Думаю, можно с уверенностью сказать, что всё, написанное на Visual Basic 6, по современным стандартам стало техническим долгом или уже давно было заменено. Да здравствует «on error resume next!»

Долгое время я занимался разработкой классических active server pages (ASP). Немного я побыл специалистом по разработке веб-сайтов, работавших в Internet Explorer 6 и Netscape Navigator. И в моём резюме эта информация больше не имеет никакого веса!

Visual Basic, ASP, IE6 и Netscape — это уже давно забытые технологии.

▍ Старые языки: Perl, Delphi, Fortran, FoxPro, ColdFusion

Кроме Visual Basic 6, есть множество языков программирования, которые за двадцать с лишним лет впали в немилость. Есть большая вероятность того, что если вы писали на одном из этих языков, то кто-то уже пытается разобраться, как переписать этот код, потому что для этих языков сложно найти программистов: Perl, Delphi, Fortran, FoxPro, ColdFusion.

Существуют ли всё ещё на них приложения? Да. Можно ли нанять людей, чтобы разрабатывать их? Это сложно. В большинстве случаев, такие компании вынуждены модернизироваться и избавляться от старых приложений.

В начале 2000-х люди думали, что Adobe ColdFusion находится на пике популярности. Помните его небольшой скачок к звёздному статусу?

Ruby on Rails находится в опасности попадания в этот список. Он утерял популярность и для него сложно найти разработчиков. То, что когда-то сделало его уникальным, теперь есть в других языках.

Языки программирования приходят и уходят. Разработчики не хотят осваивать навыки, не имеющие спроса. Вопрос всегда заключается в равновесии спроса и предложения!

Разработчики быстро бегут с тонущего корабля и всегда стремятся указать в своём резюме новую популярную технологию.

▍ Что произошло с ActiveX, апплетами Java, Flash и Silverlight?

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

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

И, разумеется, все мы помним Macromedia/Adobe Flash! Когда-то он был любимцем всего Интернета. Появлялись бесчисленные игры на Flash, множество ПО создавалось во Flash на ActionScript. Сегодня продукт под названием CheerpX позволяет запускать старые Flash-приложения при помощи WebAssembly.

Microsoft выпустила конкурента Flash под названием Silverlight. На самом деле, это потрясающий фреймворк для разработчиков на C#. Моя компания разработала несколько удивительных продуктов на основе Silverlight.

Но как мы все знаем, Apple покончила с Flash и Silverlight, отказавшись от их поддержки в своих браузерах.

Вот скриншот финансового калькулятора, который мы разрабатывали на Silverlight в VinSolutions более десяти лет назад. Silverlight уже давно в прошлом, и компания переписала весь код на JavaScript, но он по-прежнему такой же крутой, как и старая версия!

▍ Моё первое мобильное приложение

В 2004 году я создал мобильное приложение. Это время уже вспоминается с трудом, тогда ещё не существовало ни iPhone, ни Android. Я разработал приложение для инвентаризации автосалонов под КПК Compaq. Оно было написано на C# для .NET Compact Framework для работы в Windows CE.

У этого КПК была камера на один мегапиксель. При облачной погоде, когда не было сильного блеска, фотографии даже получались умеренно ужасными. Как же изменились технологии! В 2005 году это приложение было на передовом рубеже технологий, а теперь давно уже покоится на кладбище.

▍ Лучше перейти на Swift

Swift — ещё один превосходный пример того, как быстро меняются инструменты разработки. После выпуска компанией Apple языка Swift стало сложно найти причины дальше писать на Objective C. Я уверен, что есть случаи, когда он по-прежнему нужен. Но на Swift гораздо проще вести разработку и он стал серьёзным эволюционным шагом вперёд.

Я бы сказал, что все написанные на Objective C приложения, скорее всего, стали теперь техническим долгом.

▍ WebForms

После написания безумных встроенных скриптов для сборки веб-приложений я с радостью начал использовать новые веб-формы ASP.NET. Их управление на стороне сервера существенно облегчило разработку. Их задача заключалась в том, чтобы максимально упростить разработку веб-приложений на Visual Basic 6. И по большей части это удалось! Можно было создавать многократно используемые компоненты UI на стороне браузера для рендеринга в браузере. Точно так же, как мы это сегодня делаем на стопроцентном JavaScript.

WebForms не были идеальными, но стали существенным улучшением. Они отлично развивались, пока не появился Ruby on Rails и не популяризировал фреймворки MVC (Model-View-Controller) для разработки веб-приложений.

MVC быстро превратили все разработанные нами на WebForms приложения в устаревший код. С уверенностью можно сказать, что всё, написанное на WebForms, превратилось в технический долг. (Однако та же идея возвращается к нам в виде Blazor ^[1].)

▍ MVC — чемпион! (на какое-то время)

И прежде чем мы успели спохватиться, каждый язык программирования начал поддерживать фреймворки MVC. Мы начали писать всё новое на ASP.NET MVC. Он был везде, в том числе в Django, Laravel, Symfony, Spring и так далее.

Перенесёмся в настоящее: с тех пор MVC вышел из моды. Сегодня всё пишется на React, Angular, Vue и других фреймворках.

А до них у нас были другие Javascript-фреймворки. Наша компания Stackify использовала достаточно популярный фронтенд-фреймворк Knockout.

Помните ли вы хотя бы один из этих фреймворков? Knockout, Ember, Aurelia, Meteor, Backbone, Handlebars…

Если вы работали с какими-то из них, то могу поспорить, что теперь этот код считается техническим долгом и попал в немилость. Первое поколение фронтенд-фреймворков проиграло React и Angular.

▍ Angular JS

В 2015 году на сцену ворвался созданный Google фреймворк Angular. Он быстро стал самым популярным фронтенд-фреймворком.

В 2016 году произошёл крупный апгрейд Angular, который утерял обратную совместимость.

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

▍ Старые грязные SOAP и WCF

До того, как REST API и JSON стали стандартами де-факто, одной из альтернатив был SOAP ^[2] (simple object access protocol). Он упрощал вызов веб-сервисов и автоматически кодогенерировал прокси-классы для корректного вызова сервисов. В основном он использовался Windows Communication Framework (WCF) поверх XML.

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

О SOAP и WCF я совершенно не грущу. Microsoft решила больше не поддерживать WCF в .NET Core. Теперь предпочтительны технологии наподобие REST, gRPC и GraphQL. Однако проект сообщества создал CoreWCF ^[3], чтобы обеспечить его работу.

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

▍ Основные версии языков

Ещё одна распространённая проблема заключается в изменениях основных версий языков, будь то Ruby, PHP, .NET или другие. Обычно они требуют больших изменений в коде или даже его переписывания.

Когда вышел .NET Core, он стал более новой, легковесной и быстрой версией .NET, спроектированной для работы в Linux. Простой код на C# портировался на него довольно легко, но в реальных приложениях никто не использует только простой код.

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

Такие апгрейды основных версий со временем становятся большими проектами по устранению технического долга.

▍ Привязка к старой внешней зависимости

Одна из самых больших трудностей нашей компании Stackify заключалась в том, что мы оказались привязаны к старой версии Elasticsearch.

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

Нам постоянно приходилось идти против течения, и в результате мы остались далеко позади. Это ещё один пример того, как реальные проекты с техническим долгом могут наносить огромный ущерб компаниям.

▍ Из-за опенсорсной альтернативы мой код перестал быть актуальным

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

Что ж, теперь появилась OpenTelemetry ^[4], сделав всю нашу работу бесполезной.

Зачем поддерживать собственную библиотеку, если можно воспользоваться опенсорсным продуктом, ставшим стандартом отрасли? Наша компания постепенно работает над тем, чтобы прекратить поддержку профилировщика .NET, в разработке которого я участвовал.

▍ Весь код устаревает или оказывается заменённым

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

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

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

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

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

▍ Реальность технического долга

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

Однако ничто не является техническим долгом только потому, что оно неидеально. Нет ничего идеального. Со временем то, что было идеально сегодня, перестанет им быть в будущем. Учитесь соглашаться на нечто меньше, чем идеал.

Другая сторона технического долга заключается в том, что теперь всё постепенно портится со временем. Или ПО имеет существенные проблемы с апгрейдом до последних версий языка, или технология теряет популярность, потому что появились новые способы реализации. Удачи вам с наймом людей под старые технологические стеки.

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

По прошествии достаточного количества времени весь ваш код будет удалён.

^[5]

Автор:
ru_vds

Источник ^[6]