Технический долг — это самое популярное слово в наши дни. Люди говорят: «Мы быстро продвигаем наш MVP, минимизируя технический долг!». Они упоминают технический долг, чтобы показаться крутыми или что-то в этом роде.
Я просто смеюсь, потому что все, в конечном счете, является техническим долгом.
Вся моя карьера — это технический долг, или код, который стал устаревшим.
Если вы еще не верите, что вся ваша карьера тоже будет техническим долгом, то после прочтения этой статьи вы поверите в это. Я расскажу вам о том, как все изменилось за 20 лет моей карьеры.
Сначала был 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 — все это давно забытые технологии. Как сказал бы в те времена Strong Bad, «delorted!».
Старые языки: Perl, Delphi, Fortran, FoxPro, ColdFusion
Есть много языков программирования, которые вышли из употребления за последние 20 с лишним лет, помимо Visual Basic 6. Скорее всего, если вы создали что-то на одном из этих языков, люди пытаются понять, как это переписать, потому что трудно найти программистов на эти языки: Perl, Delphi, Fortran, FoxPro, ColdFusion.
Существуют ли еще приложения на этих языках? Да. Можете ли вы нанять людей для этого? Со сложностями. В большинстве случаев компании должны модернизировать и отправить на пенсию старые приложения.
В начале 2000-х годов люди думали, что Adobe ColdFusion — это горячая штучка. Помните ли вы пять минут ее славы?
Ruby on Rails находится под угрозой включения в этот список. Он вышел из моды, и найти разработчиков для него очень сложно. То, что когда-то делало его уникальным, теперь доступно на других языках.
Языки программирования приходят и уходят. Разработчики не хотят изучая навыки, которые не пользуются спросом. Это всегда баланс спроса и предложения! Разработчики быстро спрыгивают с корабля и всегда хотят видеть в своем резюме «горячую новинку».
Что случилось с ActiveX, Java Applets, Flash и Silverlight?
Некоторые из первых приложений, которые я создал, использовали элементы управления ActiveX в Internet Explorer 6. В то время они были нужны для печати и других очень небезопасных вещей. PDF-файлы тогда были не так распространены, и печать из браузера была кошмаром.
Java Applets также были “большой вещью” в свое время. Они были медленными, а установка правильной версии Java на компьютер всегда была нелегким делом. Я никогда не забуду кошмар, связанный с сетевыми брандмауэрами, которые требовали установки Java-апплетов. Я не скучаю по этим кошмарам, и, к счастью, все прошло.
Конечно, мы все помним Macromedia/Adobe Flash! В какой-то момент он был любимым ребенком всего Интернета. Существовало бесконечное количество Flash-игр, и множество программ было создано на Flash с помощью ActionScript. Продукт под названием CheerpX теперь позволяет запускать старые Flash-приложения с помощью WebAssembly.
Компания Microsoft выпустила конкурента Flash под названием Silverlight. На самом деле это был довольно фантастический фреймворк для разработчиков на C#. Моя компания создала несколько действительно удивительных вещей с помощью Silverlight.
Как мы все знаем, Apple покончила с Flash и Silverlight, отказавшись от их поддержки в своих браузерах.
Вот скриншот финансового калькулятора, который мы создали с помощью Silverlight в компании VinSolutions более 10 лет назад. Сейчас Silverlight уже давно не поддерживается, и они переписали его на JavaScript, но он не так крут, как старая версия!
Мое первое мобильное приложение
Я создал первое мобильное приложение в 2004 году. Трудно вспомнить, но iPhone и Android тогда еще не существовало. Я написал приложение для КПК Compaq для инвентаризации для автодилеров. Оно было написано на C# для .NET Compact Framework для работы на Windows CE.
У этого КПК была 1-мегапиксельная камера. Фотографии всегда получались ужасными, хотя если на улице было облачно, блики пропадали. Боже, как изменились технологии! Это приложение давно отправилось на свалку, но в 2005 году оно было передовым.
Лучше быть быстрым (Swift)
Swift — еще один прекрасный пример того, как быстро меняются инструменты разработки. Как только Apple выпустила Swift, стало трудно оправдать написание кода на Objective-C. Я уверен, что есть некоторые случаи использования, когда он все еще необходим. Но Swift значительно проще в разработке и является большим эволюционным шагом вперед.
Я бы утверждал, что любые приложения, написанные на Objective-C, сейчас, скорее всего, являются техническим долгом.
WebForms
После того, как я занимался безумными скриптами для создания веб-приложений, я был рад использовать новые веб-формы ASP.NET. Их элементы управления на стороне сервера значительно упростили разработку. Их целью было сделать создание веб-приложений таким же простым, как в Visual Basic 6. В основном это удалось! Вы могли создавать многократно используемые компоненты пользовательского интерфейса на стороне сервера для отображения в браузере. Точно так же, как мы это делаем сегодня на 100% JavaScript.
WebForms не был идеальным, но это было значительное обновление. Он отлично работал, пока не появился Ruby on Rails и не популяризировал MVC (Model-View-Controller) фреймворки для разработки веб-приложений.
MVC быстро обесценил все приложения с веб-формами, которые мы когда-либо создавали. Все, что связано с веб-формами, определенно является техническим долгом (хотя та же идея возвращается с Blazor).
MVC — король! (на некоторое время)
Не успели вы оглянуться, как каждый язык программирования поддерживал MVC-фреймворки. Мы переключились на то, чтобы делать все новое в ASP.NET MVC. Он был везде, включая Django, Laravel, Symfony, Spring и т.д.
Перенесемся в сегодняшний день, и MVC уже вышел из моды. Теперь все делается на React, Angular, Vue и других фреймворках.
До них у нас были другие Javascript-фреймворки. В Stackify мы использовали Knockout, довольно популярный front-end фреймворк.
Помните ли вы какие-нибудь из этих фреймворков? Knockout, Ember, Aurelia, Meteor, Backbone, Handlebars.
Если вы использовали какой-либо из них, могу поспорить, что весь этот код сейчас считается техническим долгом и вышел из употребления. Первое поколение фронтенд-фреймворков проиграло React и Angular.
Angular JS
В 2015 году Angular был создан компанией Google и ворвался на сцену. Он быстро стал самым популярным фронтенд-фреймворком.
Затем, в 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.
В какой-то момент они внесли существенные изменения в его работу, которые не были полностью обратно совместимы. Мы очень активно использовали старую версию, и вся работа по улучшениям превратилась в огромный технический долг и проект обновления.
Мы продолжали пинать его снова и снова и в конце концов оказались далеко позади. Это еще один пример реальных проектов с техническим долгом, от которых могут страдать компании.
Open source альтернатива отменила мой код
В Stackify мы создали собственные библиотеки трассировки/профилирования для 6 языков программирования. Это невероятный объем работы.
Теперь появился OpenTelemetry и сделал всю эту работу бесполезной.
Зачем заниматься собственными разработками, если можно использовать промышленный стандарт с открытым исходным кодом? Stackify постепенно работает над устранением профайлера .NET, который я помогал создавать.
Весь код гниет или заменяется
Со временем вы можете увидеть, как почти все, что вы создаете, выбрасывается и заменяется по разным причинам, или основывается на старой технологии.
Несколько приложений, которые я создал в начале своей карьеры, были закрыты, потому что компании были приобретены и решили использовать совершенно другие технологии.
Большинство программного обеспечения имеет ограниченный срок службы, который короче, чем вы думаете. Весь код в конечном итоге становится техническим долгом, который все хотят переписать на более современный лад, или же потребности бизнеса кардинально меняются.
Конечно, в корпоративном мире больше шансов иметь внутренние приложения, которые, кажется, останутся навсегда. Например, железная дорога или крупный банк используют одно и то же программное обеспечение на базе мэйнфрейма в течение 40 лет.
Я предсказываю, что WebAssembly в конечном итоге изменит сегодняшнюю фронтенд-разработку, и возникнет совершенно новый мир.
Реальность технического долга
Люди всегда беспокоятся о минимизации технического долга при создании новых проектов. Я понимаю это. Существует баланс между тем, чтобы заставить вещи работать, и тем, чтобы сделать их идеальными.
Однако ничто не является техническим долгом только потому, что оно не идеально. Не существует такой вещи, как совершенство. Со временем то, что было идеальным сегодня, не будет идеальным в будущем. Научитесь жить с несовершенством.
Другая сторона технического долга — это то, как все медленно сгнивает со временем. Либо возникают серьезные проблемы с обновлением до последних версий, либо технология в конечном итоге выходит из употребления из-за появления новых способов делать вещи. Удачи в найме людей на старый технологический стек.
Все в конечном итоге превращается в технический долг, или проекты сворачиваются. Если вам повезет, ваш код просуществует достаточно долго, чтобы стать техническим долгом для кого-то другого.
Дайте достаточно времени и весь ваш код будет удален.