Оригиналът е на Matt Watson Даниел Десподов преди 55 секунди

Оригиналът е на Matt Watson

Даниел Десподов преди 55 секунди 1 Сподели

Най-четени

ХардуерДаниел Маринов - 18:37 | 28.05.2023

Бритиш Телеком разгласи най-лошата позиция за слагане на рутерa вкъщи

IT НовиниДаниел Десподов - 8:06 | 29.05.2023

Колко радиоактивно е било тялото на Мария Кюри?

IT НовиниДаниел Десподов - 10:09 | 27.05.2023

Хакнаха логаритъма за активиране на Windows XP и в този момент операционната система може да бъде задействана офлайн, без интернет

Даниел Десподовhttps://www.kaldata.com/Новинар. Увличам се от модерни технологии, осведомителна сигурност, спорт, просвета и изкуствен интелект.

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

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

През 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 създаването, а светът на софтуера ще стане напълно друг.

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

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

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

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

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

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

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