Kodi që konsumon më pak: A po bëhet efikasiteti energjetik standard i ri i software-it?

Për shumë vite, cilësia e software-it është matur kryesisht përmes funksionalitetit, sigurisë, shpejtësisë dhe qëndrueshmërisë. Një aplikacion konsiderohej i mirë nëse realizonte saktë detyrën, përgjigjej shpejt dhe mund të përballonte rritjen e numrit të përdoruesve.

Por çdo veprim që kryen një sistem digjital kërkon burime. Procesori ekzekuton udhëzime, memoria ruan të dhëna, serverët përpunojnë kërkesa dhe rrjeti transporton informacion. Sa më shumë burime të përdorë një aplikacion, aq më e madhe mund të jetë infrastruktura dhe energjia e nevojshme për funksionimin e tij.

Kjo po sjell një kriter të ri në zhvillimin e software-it: efikasitetin energjetik.

Një studim i zhvilluar nga GitHub dhe Yale Program on Climate Change Communication me 1,039 përdorues të GitHub tregoi se 80% e të anketuarve ishin të interesuar për mjete që i ndihmojnë të shkruajnë kod me efikasitet më të lartë energjetik. Në të njëjtën kohë, 78% kërkonin praktika më të mira për reduktimin e ndikimit mjedisor të software-it, ndërsa 74% ishin të interesuar për mënyra konkrete të matjes së këtij ndikimi.

Këto rezultate tregojnë se interesi ekziston. Sfida është kthimi i tij në një pjesë të matshme dhe të përsëritshme të procesit të zhvillimit.

Efikasiteti i software-it fillon nga përdorimi i burimeve

Software-i nuk konsumon energji në mënyrë të drejtpërdrejtë si një pajisje fizike. Ai përcakton se sa punë duhet të kryejë infrastruktura ku ekzekutohet.

Një algoritëm që përsërit të njëjtën llogaritje disa herë përdor më shumë kapacitet procesimi. Një aplikacion që merr më shumë të dhëna sesa i nevojiten rrit përdorimin e databazës dhe të rrjetit. Një faqe që ngarkon imazhe, video ose komponentë të panevojshëm kërkon më shumë transferim të dhënash dhe më shumë punë nga pajisja e përdoruesit.

Në sisteme të vogla, këto ndryshime mund të duken të parëndësishme. Por kur një aplikacion përdoret nga mijëra ose miliona persona, edhe një operacion i vogël dhe joefikas mund të përsëritet në një shkallë shumë të madhe.

Për këtë arsye, software-i me efikasitet energjetik nuk fillon vetëm te qendrat e të dhënave apo burimi i energjisë. Ai fillon edhe te vendimet që merren gjatë projektimit dhe shkrimit të kodit.

Kodi më i shpejtë nuk është automatikisht më i qëndrueshëm

Shpejtësia dhe efikasiteti energjetik shpesh lidhen me njëra-tjetrën, por nuk janë e njëjta gjë.

Një funksion që përfundon më shpejt mund të përdorë më pak kohë procesori. Megjithatë, një zgjidhje më e shpejtë mund të kërkojë më shumë memorie, më shumë pajisje ose përpunim paralel më intensiv. Në këtë rast, koha e ekzekutimit ulet, por përdorimi i përgjithshëm i burimeve mund të mos reduktohet.

Edhe infrastruktura ku ekzekutohet software-i ndikon në rezultat. E njëjta ngarkesë mund të ketë karakteristika të ndryshme energjetike në varësi të hardware-it, vendndodhjes së qendrës së të dhënave, kohës së ekzekutimit dhe burimit të energjisë.

Prandaj, një përmirësim nuk duhet të cilësohet automatikisht si më ekologjik vetëm sepse kodi është më i shpejtë. Pretendimi duhet të mbështetet me matje që lidhen me ndryshimin konkret.

Kjo është arsyeja pse zhvillimi i software-it me efikasitet energjetik kërkon jo vetëm optimizim, por edhe prova.

Matja duhet të bëhet pjesë e procesit të zhvillimit

Një ekip software nuk mund të përmirësojë në mënyrë të besueshme atë që nuk është në gjendje ta masë.

Përpara një optimizimi duhet të përcaktohet gjendja fillestare. Kjo mund të përfshijë kohën e ekzekutimit, përdorimin e procesorit, konsumin e memories, numrin e kërkesave drejt databazës ose sasinë e të dhënave që transferohen në rrjet.

Pas ndryshimit, të njëjtat matje duhet të përsëriten në kushte të krahasueshme. Në këtë mënyrë, ekipi mund të kuptojë nëse optimizimi prodhoi një përmirësim real dhe çfarë kompromisesh solli.

Për shembull, zëvendësimi i një kërkimi joefikas me një strukturë më të përshtatshme të të dhënave mund të reduktojë kohën e procesimit. Por nëse zgjidhja e re përdor më shumë memorie, ky ndryshim duhet të dokumentohet dhe të vlerësohet.

Një pull request i orientuar drejt efikasitetit duhet të tregojë se çfarë problemi u identifikua, cilat metrika u përdorën, cili ishte rezultati fillestar dhe çfarë ndryshoi pas ndërhyrjes.

Kështu, efikasiteti nuk mbetet një deklaratë e përgjithshme. Ai bëhet një rezultat teknik që mund të kontrollohet.

Joefikasiteti mund të fshihet në disa pjesë të sistemit

Konsumi i panevojshëm i burimeve nuk shkaktohet vetëm nga algoritmet komplekse. Ai mund të shfaqet në të gjithë arkitekturën e një aplikacioni.

Në kod, problemet mund të lidhen me llogaritje të përsëritura, cikle joefikase, krijim të panevojshëm objektesh ose procese që mund të ruheshin për t’u ripërdorur.

Në shtresën e të dhënave, aplikacioni mund të marrë më shumë informacion sesa i nevojitet, të kryejë kërkesa të pakufizuara ose të kontaktojë databazën disa herë për të dhëna që mund të merreshin së bashku.

Në komunikimin përmes rrjetit, joefikasiteti mund të vijë nga kërkesa të dyfishta, kontrolli i vazhdueshëm për ndryshime, mungesa e kompresimit ose transferimi i skedarëve më të mëdhenj nga sa kërkon përdoruesi.

Edhe frontend-i mund të përdorë burime pa nevojë përmes renderimeve të përsëritura, ngarkimit paraprak të elementeve që nuk shfaqen në ekran ose përdorimit të formateve të rënda mediatike.

Kjo do të thotë se efikasiteti energjetik nuk është përgjegjësi e një komponenti të vetëm. Ai duhet të vlerësohet në të gjithë rrjedhën e sistemit.

Infrastruktura cloud nuk e zgjidh automatikisht problemin

Kalimi në cloud mund t’i ndihmojë organizatat të përdorin infrastrukturë më fleksibile dhe të përshtatin kapacitetin sipas ngarkesës. Megjithatë, cloud-i nuk e bën automatikisht një aplikacion efikas.

Nëse një shërbim kryen llogaritje të panevojshme, ruan të dhëna që nuk përdoren ose mban aktive burime pa ngarkesë, problemi vazhdon të ekzistojë. Ai thjesht zhvendoset nga infrastruktura lokale te infrastruktura e ofruesit cloud.

Arkitektura duhet të projektohet në mënyrë që burimet të aktivizohen kur nevojiten dhe të reduktohen kur nuk përdoren. Proceset periodike duhet të ekzekutohen me frekuencën e duhur, ndërsa mjediset e testimit nuk duhet të qëndrojnë aktive pa arsye.

Efikasiteti mund të ulë njëkohësisht përdorimin e infrastrukturës, vonesën e sistemit dhe kostot operative. Për këtë arsye, Green Software nuk duhet parë vetëm si një nismë mjedisore. Ai mund të jetë edhe një praktikë e mirë ekonomike dhe arkitekturore.

Edhe procesi i zhvillimit përdor energji

Vëmendja zakonisht përqendrohet te aplikacioni përfundimtar, por edhe procesi i ndërtimit dhe shpërndarjes së tij përdor burime.

Çdo build, test automatik, skanim sigurie dhe proces deploy kërkon fuqi kompjuterike. Nëse një ndryshim i vogël aktivizon vazhdimisht të gjithë paketën e testeve ose nëse disa pipeline kryejnë të njëjtën punë, ekipi mund të jetë duke përdorur më shumë burime sesa nevojiten.

Përmirësimi i proceseve CI/CD mund të përfshijë ruajtjen e rezultateve të ndërmjetme, ekzekutimin vetëm të testeve që lidhen me ndryshimin, eliminimin e punëve të dyfishta dhe çaktivizimin e proceseve që nuk prodhojnë më vlerë.

Kjo nuk do të thotë të reduktohen kontrollet që garantojnë cilësinë dhe sigurinë. Objektivi është që të njëjtat garanci të arrihen me më pak punë të panevojshme.

AI mund të kërkojë joefikasitetin, por nuk duhet të marrë vendimin përfundimtar

Në repository të mëdha, identifikimi manual i të gjitha mundësive për optimizim mund të kërkojë shumë kohë. Agjentët e AI-së mund të përdoren për të analizuar kodin, të dhënat, komunikimin në rrjet dhe frontend-in, duke evidentuar operacione që mund të optimizohen.

GitHub ka publikuar një proces eksperimental që kërkon mundësi për përmirësimin e efikasitetit, ekzekuton testet dhe mund të përgatisë draft pull requests të shoqëruara me matje dhe kompromiset e mundshme. Por ndryshimet nuk bashkohen automatikisht me kodin kryesor; ato u paraqiten mirëmbajtësve për kontroll.

Kjo ndarje është e rëndësishme. AI mund të identifikojë një pjesë kodi që duket joefikase, por nuk e njeh gjithmonë të gjithë kontekstin e biznesit ose arsyen arkitekturore që qëndron pas saj.

Një optimizim mund të përmirësojë performancën dhe njëkohësisht ta bëjë kodin më të ndërlikuar. Mund të reduktojë përdorimin e procesorit, por të rrisë konsumin e memories. Mund të funksionojë mirë në test, por të ketë sjellje tjetër me ngarkesën reale.

Për këtë arsye, çdo rekomandim i AI-së duhet të trajtohet si një hipotezë që duhet testuar, jo si një vendim që duhet zbatuar automatikisht.

Efikasiteti duhet të bëhet kriter arkitekturor

Vendimet me ndikimin më të madh zakonisht merren përpara se të shkruhet pjesa më e madhe e kodit.

Mënyra si ndahen shërbimet, ku ruhen të dhënat, si komunikojnë komponentët dhe cilat procese ekzekutohen në kohë reale përcaktojnë sasinë e burimeve që sistemi do të kërkojë gjatë gjithë ciklit të tij të jetës.

Nëse efikasiteti merret në konsideratë vetëm pas përfundimit të produktit, hapësira për ndryshim mund të jetë e kufizuar. Ndërhyrjet e mëvonshme mund të kërkojnë rishkrim të komponentëve ose ndryshim të arkitekturës.

Për këtë arsye, kërkesat për software me efikasitet energjetik duhet të përfshihen në specifikime, në kriteret e pranimit dhe në vendimet arkitekturore. Ekipi duhet të përcaktojë cilat burime janë të rëndësishme për t’u matur dhe çfarë niveli përdorimi konsiderohet i pranueshëm.

Efikasiteti bëhet kështu pjesë e mënyrës si projektohet sistemi, jo një optimizim që shtohet në fund.

Software-i efikas kërkon prova, jo vetëm deklarata

Për Soft&Solution Group, efikasiteti energjetik i software-it duhet të trajtohet si një problem inxhinierik që kërkon të dhëna të verifikueshme.

Nuk mjafton që një ekip ta përshkruajë një aplikacion si të qëndrueshëm ose ekologjik. Duhet të jetë e qartë se çfarë është matur, çfarë është përmirësuar dhe cilat kufizime ka vlerësimi.

Siç shprehet Ermal Beqiri, themelues i Soft&Solution Group:

“Software-i efikas nuk ndërtohet vetëm duke shkruar kod më të shpejtë. Ai kërkon të kuptojmë se ku përdoren burimet, të masim ndikimin e çdo ndryshimi dhe të zgjedhim arkitekturën që realizon të njëjtin objektiv me më pak punë të panevojshme. Vetëm atëherë efikasiteti energjetik bëhet një standard real inxhinierik.”

Zhvillimi i software-it po hyn në një fazë ku funksionaliteti dhe performanca nuk janë më kriteret e vetme. Ekipet po fillojnë të vlerësojnë edhe sa burime kërkon një sistem për të realizuar funksionin e tij.

Kjo nuk do të thotë se çdo aplikacion duhet të optimizohet deri në nivelin më të vogël teknik. Do të thotë se përdorimi i panevojshëm i procesorit, memories, rrjetit dhe infrastrukturës duhet të bëhet i dukshëm dhe i matshëm.

Nëse matja e efikasitetit integrohet në testim, code review dhe vendimet arkitekturore, konsumi i burimeve mund të trajtohet si çdo tregues tjetër i cilësisë.

Software-i me efikasitet energjetik nuk është thjesht software që konsumon më pak. Është software që e realizon qëllimin e tij duke përdorur burimet në mënyrë më të kujdesshme, të matshme dhe të arsyetuar.