Резултатът от двадесет години работа – технически дълг и неподдържан код

Резултатът от двадесет години работа – технически дълг и неподдържан код

Техническият дълг е един от най-популярните термини днес. Хората казват: „Бързо развиваме нашия 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 възможно най-лесно. И в по-голямата си част те успяха! Беше възможно да се създават компоненти на потребителския интерфейс за многократна употреба от страната на браузъра за визуализиране в браузъра. Точно както правим днес със 100% 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 г. на сцената се появи фреймуъркът Angular на Google. Той бързо се превърна в най-популярния фронтенд фреймуърк.

През 2016 г. бе направен голям ъпгрейд на Angular, при който бе загубена обратната съвместимост.

Знаете ли какво означава това? Всичко, което е написано на оригиналната версия, вече се е превърнало в технически дълг. В нашата компания имам проекти върху старата версия на Angular, които са се превърнали в голям технически дълг, изискващ надграждане.

Старите мръсни SOAP и WCF

Преди приложният програмен интерфейс REST и JSON да се превърнат във фактически стандарти, една от алтернативите беше SOAP (прост протокол за достъп до обектите). Той опростяваше извикването на уеб услугите и автоматично генерираше прокси класове за правилното извикване на услугите. В основата си той използваше 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 постепенно ще завладее целия съвременен свят на front-end разработката, а светът на софтуера ще стане съвсем различен.

Реалността на техническия дълг

При разработването на нови проекти хората винаги се интересуват от минимизирането на техническия дълг. И аз разбирам това. Съществува баланс между една работеща програма и желанието за нейното подобряване.

Нищо обаче не е технически дълг само защото не е идеално. Нищо не е идеално. С течение на времето това, което е било перфектно днес, ще престане да бъде такова в бъдеще. Научете се да се задоволявате с нещо по-малко от идеалното.

Другата страна на техническия дълг е, че нещата постепенно се влошават с течение на времето. Или софтуерът има значителни проблеми с надграждането до най-новите версии на езика, или технологията губи популярност, защото са се появили нови начини за реализация. Желая ви късмет при търсенето и назначаването на хора за работа със старите технологични стекове.

В крайна сметка всичко се превръща в технически дълг или проектите вървят към своя упадък. Ако имате наистина голям късмет, кодът ви ще оцелее достатъчно дълго, за да се превърне в технически дълг за някой друг.

След като измине достатъчно много време, целият ви код ще бъде изтрит.

Според класическото определение техническият дълг е концепция в програмирането, която отразява допълнителната разработка, която възниква, когато се използва лесен за изпълнение код в краткосрочен план, вместо да се прилага най-доброто цялостно решение.