[Перевод] Итоги двадцати лет работы — технический долг и неподдерживаемый код
Технический долг — один из самых популярных сегодня терминов. Люди говорят: «Мы быстро развиваем свой 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.)
▍ 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 (simple object access protocol). Он упрощал вызов веб-сервисов и автоматически кодогенерировал прокси-классы для корректного вызова сервисов. В основном он использовался Windows Communication Framework (WCF) поверх XML.
Он работал потрясающе… до определённого момента. Одна из самых трудных проблем в моей карьере заключалась в том, чтобы понять, как использовать сертификаты безопасности между моей компанией и другим поставщиком по WCF и SOAP. SOAP и WCF давали большие обещания, но со временем их поддержка превращалась в кошмар.
О SOAP и WCF я совершенно не грущу. Microsoft решила больше не поддерживать WCF в .NET Core. Теперь предпочтительны технологии наподобие REST, gRPC и GraphQL. Однако проект сообщества создал CoreWCF, чтобы обеспечить его работу.
Со временем типы технологий для вызова веб-сервисов изменились. Старые способы по-прежнему работают, однако большинство разработчиков, скорее всего, предпочтёт отправить их на пенсию.
▍ Основные версии языков
Ещё одна распространённая проблема заключается в изменениях основных версий языков, будь то Ruby, PHP, .NET или другие. Обычно они требуют больших изменений в коде или даже его переписывания.
Когда вышел .NET Core, он стал более новой, легковесной и быстрой версией .NET, спроектированной для работы в Linux. Простой код на C# портировался на него довольно легко, но в реальных приложениях никто не использует только простой код.
Однако в сложных корпоративных приложениях при движении по пути апгрейда возникает множество потенциальных проблем. Это становится крупным техническим долгом, который необходимо устранить. В противном случае вы окажетесь привязанными к древней версии языка.
Такие апгрейды основных версий со временем становятся большими проектами по устранению технического долга.
▍ Привязка к старой внешней зависимости
Одна из самых больших трудностей нашей компании Stackify заключалась в том, что мы оказались привязаны к старой версии Elasticsearch.
В какой-то момент разработчики этой системы внесли существенные изменения в способ её работы, которые были не полностью обратно совместимы. Мы активно использовали эту систему, и вся работа по апгрейду превратилась в крупномасштабный проект по устранению технического долга.
Нам постоянно приходилось идти против течения, и в результате мы остались далеко позади. Это ещё один пример того, как реальные проекты с техническим долгом могут наносить огромный ущерб компаниям.
▍ Из-за опенсорсной альтернативы мой код перестал быть актуальным
Наша компания создавала собственные библиотеки трассировки/профилирования для шести языков программирования. Для их реализации приходилось выполнять невероятный объём работы.
Что ж, теперь появилась OpenTelemetry, сделав всю нашу работу бесполезной.
Зачем поддерживать собственную библиотеку, если можно воспользоваться опенсорсным продуктом, ставшим стандартом отрасли? Наша компания постепенно работает над тем, чтобы прекратить поддержку профилировщика .NET, в разработке которого я участвовал.
▍ Весь код устаревает или оказывается заменённым
С течением времени вы видите, как почти всё созданное вами умирает и заменяется по различным причинам. В противном случае ваша работа будет основана на устаревшей технологии.
Множество приложений, которые я создал на ранних этапах моей карьеры, было убито, потому что разрабатывавшие их компании кто-то купил или они решили использовать совершенно другую технологию.
Срок жизни большинства ПО ограничен, и он гораздо меньше, чем вы предполагаете. Весь код постепенно становится техническим долгом, который все хотят переписать более современным образом. Или же существенно меняются потребности бизнеса.
Разумеется, в корпоративном мире выше вероятность того, что какие-то внутренние приложения будут использоваться практически бесконечно. Управляющая железными дорогами компания или банк по сорок лет используют одно и то же ПО, работающее на мейнфреймах.
Я предположу, что WebAssembly постепенно захватит весь современный мир фронтенд-разработки, и мир ПО эволюционным образом превратится в совершенно иной.
▍ Реальность технического долга
При разработке новых проектов людей всегда волнует минимизация технического долга. И я это понимаю. Есть баланс между работающей программой и стремлением к её совершенствованию.
Однако ничто не является техническим долгом только потому, что оно неидеально. Нет ничего идеального. Со временем то, что было идеально сегодня, перестанет им быть в будущем. Учитесь соглашаться на нечто меньше, чем идеал.
Другая сторона технического долга заключается в том, что теперь всё постепенно портится со временем. Или ПО имеет существенные проблемы с апгрейдом до последних версий языка, или технология теряет популярность, потому что появились новые способы реализации. Удачи вам с наймом людей под старые технологические стеки.
Всё со временем превращается в технический долг или проекты клонятся к своему закату. Если вам сильно повезёт, то ваш код выживает достаточно долго, чтобы стать техническим долгом кого-то другого.
По прошествии достаточного количества времени весь ваш код будет удалён.
Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх
