{"id":247685,"date":"2023-03-02T06:48:00","date_gmt":"2023-03-02T03:48:00","guid":{"rendered":"https:\/\/inform.click\/kuidas-hinnata-hallata-ja-valtida-tehnilisi-volgu\/"},"modified":"2023-03-02T07:05:00","modified_gmt":"2023-03-02T04:05:00","slug":"kuidas-hinnata-hallata-ja-valtida-tehnilisi-volgu","status":"publish","type":"post","link":"https:\/\/inform.click\/et\/kuidas-hinnata-hallata-ja-valtida-tehnilisi-volgu\/","title":{"rendered":"Kuidas hinnata, hallata ja v\u00e4ltida tehnilisi v\u00f5lgu"},"content":{"rendered":"

\n Kui tehniline v\u00f5lg k\u00f5lab nagu rahanduse k\u00e4siraamatust eemaldatud, on see sellep\u00e4rast, et see termin on seotud rahandusega. Tehniline v\u00f5lg on selle tegelikus t\u00e4henduses aga seotud programmeerimisega. See on idee, et tarkvaraprojekti arendamise k\u00e4igus j\u00e4etakse teatud vajalikud sammud vahele v\u00f5i lihtsalt loobutakse t\u00e4htaegadest kinnipidamise nimel.\n<\/p>\n

\n T\u00e4iusliku rakenduse v\u00f5i tarkvara v\u00e4ljat\u00f6\u00f6tamiseks on arendajatel sageli ajapuudus \u2013 t\u00e4pselt nagu igal juhuslikul inimesel, kes teeb mis tahes suvalist \u00fclesannet. Seega on tavaliselt m\u00f5istlik leida mingi kompromiss t\u00e4iusliku koodiga t\u00e4iusliku toote tarnimise ja aja maksimeerimise vahel.\n<\/p>\n

\n K\u00fcsimus on siis: kas nendel kompromissidel on piir? Kas sellest kompromissist v\u00f5ib tuleneda kahju? L\u00f5puks, kas arendajal on pikas perspektiivis t\u00f5esti parem? Selles tehnilisi v\u00f5lgu k\u00e4sitlevas artiklis p\u00fc\u00fcan vastata k\u00f5igile neile k\u00fcsimustele.\n<\/p>\n

\n Mis on tehniline v\u00f5lg?
\n<\/h5>\n

\n Tehnilise v\u00f5la m\u00e4\u00e4ratlemisel peame viitama mehele, keda peetakse selle termini loojaks: Ward Cunningham. Cunninghami s\u00f5nul viitab tehniline v\u00f5lg t\u00e4iendavale arendust\u00f6\u00f6le, mis peab minema koodi programmeerimiseks, et korvata selle programmeerimisest tulenevat puuduj\u00e4\u00e4ki l\u00fchikese aja jooksul.\n<\/p>\n

\n Asja graafilisemaks muutmiseks kujutage ette, et teie \u00fclesandeks on koristada r\u00e4pane tuba ja j\u00e4\u00e4te tundi hiljaks. Et tagada juhendite t\u00e4itmine ja ka \u00f5igel ajal klassi j\u00f5udmine, teete kiire koristust\u00f6\u00f6, p\u00fchkides suurema osa prahist diivani alla. Selle tagaj\u00e4rjeks on see, et l\u00f5puks peate v\u00f5tma aega jama sorteerimiseks. Tarkvaraarenduse puhul, kui j\u00e4tate vajalikud sammud vahele ja j\u00e4rgite lihtsamat teed \u201emitte nii puhaste” koodidega, muutub tulevikus koodi puhastamine raskemaks. Tarkvaraprojekti doominom\u00e4ngus esineb mitu etappi ja mida kauem te olemasolevat probleemi ignoreerite, seda kauem kulub selle lahendamiseks.\n<\/p>\n

\n Tehniliste v\u00f5lgade liigid\n<\/p>\n

\n Tehnilisi v\u00f5lgu on erinevat t\u00fc\u00fcpi, sealhulgas:\n<\/p>\n

\n Planeeritud tehnilised v\u00f5lad
\n<\/h5>\n

\n See juhtub olukordades, kus organisatsioonid otsustavad teadlikult tehnilistesse v\u00f5lgadesse minna. See, nagu varem arutatud, on tavaliselt m\u00e4\u00e4ratud t\u00e4htaegade \u00fcletamine ja konkreetse eesm\u00e4rgi saavutamine. Planeeritud tehniliste v\u00f5lgnevuste tegemisel peab organisatsioon selgeks tegema, millest ollakse valmis loobuma ja millest mitte. Peate pidama t\u00e4pset arvestust, pidades meeles, et l\u00f5puks peate tagastama ja parandama alguses vahele j\u00e4\u00e4nud vead.\n<\/p>\n

\n Tahtmatud tehnilised v\u00f5lad
\n<\/h5>\n

\n Seda t\u00fc\u00fcpi tehniline v\u00f5lg on otsene vastand esimesele. See tekib siis, kui organisatsioon ei n\u00e4e ette ega plaani tehnilist v\u00f5lga. Selle p\u00f5hjuseks on tavaliselt organisatsiooni erinevate \u00fcksuste vahelise suhtluse katkemine v\u00f5i \u00fcksustevahelised halvad t\u00f6\u00f6tavad.\n<\/p>\n

\n V\u00e4ltimatud tehnilised v\u00f5lad
\n<\/h5>\n

\n See on selline tehniline v\u00f5lg, mida \u00fckski organisatsioonipoolne tegevus poleks saanud \u00e4ra hoida. N\u00e4iteks tehnoloogias kogetud kiirete muutuste t\u00f5ttu on m\u00f5istlik, et m\u00f5ned varem kirjutatud koodid ei vasta praegustele prognoositud standarditele.\n<\/p>\n

\n Samuti v\u00f5ib selline tehniline v\u00f5lg tekkida siis, kui muudatusi taotletakse siis, kui koodi juba kirjutatakse. Kui tarkvara kujundamise poole peal tehakse teatud muudatusi, v\u00f5ib see d\u00fcnaamikat segada, muutes vana koodi aegunuks v\u00f5i tarbetuks.\n<\/p>\n

\n Tehniliste v\u00f5lgade p\u00f5hjused
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n M\u00f5ningaid tehniliste v\u00f5lgade p\u00f5hjuseid on eespool k\u00e4sitletud, kuid ma valin need \u00fcksteise j\u00e4rel v\u00e4lja, et need oleksid selgemad.\n<\/p>\n

\n Kiirustage
\n<\/h5>\n

\n Tehniliste v\u00f5lgade k\u00f5ige sagedasem p\u00f5hjus on kiirustamine. Arendajatel on sageli ranged t\u00e4htajad, millest m\u00f5ned sisaldavad ka teatud tarkvara k\u00e4ivitamise t\u00e4htaegu. Sageli on sellistes olukordades arusaadav (ja ootusp\u00e4rane), et arendajal v\u00f5ib tekkida tehnilisi v\u00f5lgu. Seda t\u00fc\u00fcpi tehniline v\u00f5lg on sageli tahtlik ja v\u00f5ib p\u00f5hjustada probleeme, mis v\u00f5ivad ulatuda koodis esinevatest vigadest v\u00f5i spagettide koodidest.\n<\/p>\n

\n Eba\u00f5ige\/viga
\n<\/h5>\n

\n M\u00f5nikord kirjutavad programmeerijad lihtsalt halbu koode, mis l\u00f5puks p\u00f5hjustavad tehnilisi v\u00f5lgu. Olenemata sellest, kas vigane kood on kodeerija vea t\u00f5ttu olemas v\u00f5i mitte, on t\u00f5siasi, et vead p\u00f5hjustavad tehnilisi v\u00f5lgu ja kuna need ei ole skaleeritavad, tuleb need l\u00f5puks parandada.\n<\/p>\n

\n V\u00e4hene teadlikkus m\u00f5judest
\n<\/h5>\n

\n M\u00f5nikord tekivad tehnilised v\u00f5lad seet\u00f5ttu, et kodeerija ei m\u00f5ista ega tunnista, kui kahjulikud on tehnilised v\u00f5lad pikemas perspektiivis. See v\u00f5ib tuleneda \u00f5igustatud teadmatusest programmeerimise ajal otseteede kasutamise kahjulike m\u00f5jude kohta v\u00f5i v\u00f5ib olla tagaj\u00e4rgede tahtlik eiramine.\n<\/p>\n

\n Kavatsus
\n<\/h5>\n

\n Tehnilised v\u00f5lad v\u00f5ivad tekkida tahtlikult kodeerija v\u00f5i organisatsiooni tahtliku tegevuse t\u00f5ttu.\n<\/p>\n

\n Modulaarsuse puudumine
\n<\/h5>\n

\n See tekib peamiselt seet\u00f5ttu, et \u00fcks kood v\u00f5ib korraga teenindada erinevat \u00e4riloogikat. Selline olukord muudab tarkvara k\u00e4sitsemise palju raskemaks. Iga koodiga, mille arendaja kirjutab, on suurem t\u00f5en\u00e4osus, et nad kogevad modulaarsusega probleeme.\n<\/p>\n

\n Tehnilise v\u00f5la hindamine
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n Tehnilisi v\u00f5lgu ei tohiks kunagi k\u00e4sitsi arvutada, sest see oleks \u00fcsna vaevarikas. See t\u00e4hendaks praeguste ja v\u00f5imalike tulevaste probleemide kindlaksm\u00e4\u00e4ramiseks koodi k\u00e4sitsi sisestamist. Peale selle, kui aega raiskab manuaalne protsess, on v\u00f5imalik, et koodid on k\u00e4sitsi protsessi l\u00f5pus oma kuju muutnud.\n<\/p>\n

\n \u00dcks viis hindamise l\u00e4biviimiseks on staatilise anal\u00fc\u00fcsi l\u00e4biviimine, kasutades m\u00f5nda seda toetavat t\u00f6\u00f6riista. M\u00f5ned t\u00f6\u00f6riistad, mida saab kasutada, on Coverity, SonarQube, Check Style ja Closure Compiler.\n<\/p>\n

\n \u00dcldiselt on tehniliste v\u00f5lgade arvutamiseks kaks v\u00f5imalust. Esimesel l\u00e4henemisel v\u00f5ib selle saada tehnilise v\u00f5la suhte arvutamisel koodisuhte j\u00e4rgi. Siin kasutatakse tehnilise v\u00f5la parandamiseks kuluva aja m\u00e4\u00e4ramiseks esialgset hinnangut v\u00f5i rakenduse arendamiseks vajalikku \u00fcldist aega.\n<\/p>\n

\n Teise l\u00e4henemisviisi korral saate otse kasutada erinevate t\u00f6\u00f6riistade (nt SonarQube) antud hinnanguid. See kombineeritakse tehniliste v\u00f5lgade nimekirjade ja nende viitekoodidega. T\u00f6\u00f6riistade abil saate t\u00e4pse hinnangu selle parandamiseks kuluva aja pikkuse kohta.\n<\/p>\n

\n Tehnilise v\u00f5la hindamine annab teile aimu, mitu p\u00e4eva kulub tehnilise v\u00f5la parandamiseks. Mida rohkem on v\u00f5lgu, seda kauem v\u00f5tab teil selle parandamine aega.\n<\/p>\n

\n Tehniliste v\u00f5lgade lahendamine
\n<\/h3>\n

\n Mis saab siis, kui on tekkinud tehnilised v\u00f5lad ja te ei tea, mida teha? Tehniliste v\u00f5lgade haldamiseks saate astuda teatud samme.\n<\/p>\n

\n Esiteks peaksite tunnistama tehniliste v\u00f5lgade olemasolu ja edastama sama oma meeskonnale. Suhtlemisel peaksite olema selge, mis juhtus ja mida tuleb selle parandamiseks ette v\u00f5tta. Peaksite veenduma, et teavitaksite selgelt vajadusest esimesel v\u00f5imalusel tehnilise v\u00f5la eest hoolitseda.\n<\/p>\n

\n P\u00e4rast oma meeskonna teavitamist tehnilistest v\u00f5lgadest on teil kolm v\u00f5imalust. Esimesel juhul v\u00f5ite otsustada j\u00e4tkata s\u00fcsteemiga, nagu see on. Selle stsenaariumi korral kasutatakse rakendust sellisel kujul, nagu see on.\n<\/p>\n

\n Teise v\u00f5imalusena v\u00f5ite otsustada rakenduse \u00fcmber kujundada. Refactoring tehakse eesm\u00e4rgiga v\u00e4hendada rakenduse keerukust ja puhastada rakenduse struktuuri. Refaktoreerimisega tarkvara k\u00e4itumist ei muudeta; ainus m\u00f5jutatud osa on sisemine struktuur.\n<\/p>\n

\n L\u00f5puks, kui kaks \u00fclalkirjeldatud v\u00f5imalust ei t\u00f6\u00f6ta, peate koodi t\u00e4ielikult asendama. Selle \u00fcheks probleemiks on see, et see v\u00f5ib kaasa tuua uusi tehnilisi v\u00f5lgu, kuid see v\u00f5ib olla pikemas perspektiivis parem kompromiss.\n<\/p>\n

\n Tehniliste v\u00f5lgade v\u00e4ltimine tulevikus
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n See on muidugi m\u00f5ttetu, et tehniliste v\u00f5lgade v\u00e4ltimine on kindlasti targem, kui p\u00fc\u00fcda neid tekkides parandada. Lisaks sellele, et see s\u00e4\u00e4stab teie aega ja stressi, tagab see ka selle, et tehniliste v\u00f5lgade algusest peale tekkinud j\u00e4\u00e4ktagaj\u00e4rjed puuduvad.\n<\/p>\n

\n V\u00f5ib v\u00e4ita, et tehnilised v\u00f5lad pole iseenesest halvad. Need on \u00fcldiselt problemaatilised, kuna need on v\u00f5lad, mis tuleb tagasi maksta, ja inimesed ei ole k\u00f5ige vastutustundlikumad liigid maa peal. N\u00f5rgema valiku j\u00e4rjekindel valimine n\u00f5rgendab \u00fcldiselt teie tarkvara tugevust ja muudab funktsioonide hilisema t\u00e4iustamise raskemaks. Kokkuv\u00f5ttes on tehniliste v\u00f5lgade v\u00e4ltimine iga\u00fche jaoks parim valik.\n<\/p>\n

\n Niisiis, kuidas v\u00e4ltida tehniliste v\u00f5lgade tekkimist:\n<\/p>\n

\n Looge projekti mahaj\u00e4\u00e4mus\n<\/p>\n

\n M\u00f5te on siin hoida k\u00f5iki protsessiga kursis ja viia nad kiirusega vastavusse mis tahes \u00fclesande t\u00e4itmisega. Mahaj\u00e4\u00e4mise loomine v\u00f5imaldab k\u00f5igil n\u00e4ha tegemata j\u00e4etud \u00fclesandeid ja nende saavutamiseks vajalikke teid.\n<\/p>\n

\n Eelista kvaliteeti kiirusele\n<\/p>\n

\n Kui olete ise programmeerija, peate \u00f5ppima kvaliteetse t\u00f6\u00f6 tegemist eelistama suurele t\u00f6\u00f6le. Veenduge, et teie koodid on puhtad ja teie rakendused v\u00f5i muu tarkvara on t\u00e4iuslikult v\u00e4lja t\u00f6\u00f6tatud. M\u00f5istke, et kiusatus kasutada otseteid ei ole seda v\u00e4\u00e4rt, sest l\u00f5puks peate ikkagi t\u00e4itma \u00fclesandeid, millest loobusite.\n<\/p>\n

\n Kui juhite meeskonda, peate neid samu v\u00e4\u00e4rtusi meeskonnaliikmetele edastama. Liikmeid tuleks \u00f5petada looma tulemusele orienteeritud lahendusi ja v\u00e4ltima otseteid.\n<\/p>\n

\n Looge teadlikkus\n<\/p>\n

\n \u00dcldjuhul v\u00f5ivad p\u00f5hjalikud teadmised selle kohta, mis on tehniline v\u00f5lg ja kuidas seda v\u00e4ltida, olla kasulikud nende tekkimise ennetamisel. Kui varustate oma arendajaid vajalike teadmistega, v\u00e4ldivad nad paremini tehniliste v\u00f5lgade l\u00f5kse.\n<\/p>\n

\n Tutvustage h\u00e4id kodeerimistavasid\n<\/p>\n

\n M\u00f5ned kodeerimistavad muudavad tehnilistesse v\u00f5lgadesse sattumise t\u00f5en\u00e4olisemaks. Seega oleks tore v\u00e4ltida tihedat sidumist, kasutada abstraktsiooni ja refaktoreerimist.\n<\/p>\n

\n Tutvustage uuendatud tehnoloogiat\n<\/p>\n

\n Tehnoloogia korrap\u00e4rane uuendamine v\u00f5ib olla suurep\u00e4rane vahend tehniliste v\u00f5lgade ennetamiseks. V\u00e4rskendamisel peate veenduma, et kasutatav on uusim raamistik, andmebaasid ja rakendustarkvara.\n<\/p>\n

\n J\u00e4reldus
\n<\/h5>\n

\n Tehnilised v\u00f5lad on valdaval enamusel juhtudel v\u00e4ltimatud seni, kuni j\u00e4tkate programmide arendamist ja koodide kirjutamist. Nende esinemise t\u00f5en\u00e4osust saab aga oluliselt v\u00e4hendada, kui j\u00e4rgida \u00fclaltoodud samme. Samuti ei ole tehniliste v\u00f5lgade tekkimisel igasugune lootus kadunud. J\u00e4\u00e4 rahulikuks, ole enesekindel, k\u00e4itu vastavalt.\n<\/p>\n<\/p>\n

\n : instantshift.com<\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Kui tehniline v\u00f5lg k\u00f5lab nagu rahanduse k\u00e4siraamatust eemaldatud, on see sellep\u00e4rast, et see termin on seotud rahandusega. Tehniline v\u00f5lg on selle tegelikus t\u00e4henduses aga seotud programmeerimisega. See on idee, et tarkvaraprojekti arendamise k\u00e4igus j\u00e4etakse teatud vajalikud sammud vahele v\u00f5i lihtsalt loobutakse t\u00e4htaegadest kinnipidamise nimel. T\u00e4iusliku rakenduse v\u00f5i tarkvara v\u00e4ljat\u00f6\u00f6tamiseks on arendajatel sageli ajapuudus \u2013 t\u00e4pselt nagu igal juhuslikul inimesel, kes teeb mis tahes suvalist \u00fclesannet. Seega on tavaliselt m\u00f5ttekas omada mingisugust\u2026<\/p>\n","protected":false},"author":1,"featured_media":209172,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_wp_rev_ctl_limit":""},"categories":[208,260,91,52],"tags":[],"class_list":["post-247685","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-kodeerimine","category-psuhholoogia","category-seo-ja-turundus","category-web-ja-wordpress"],"_links":{"self":[{"href":"https:\/\/inform.click\/et\/wp-json\/wp\/v2\/posts\/247685","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/inform.click\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/inform.click\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/inform.click\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/inform.click\/et\/wp-json\/wp\/v2\/comments?post=247685"}],"version-history":[{"count":0,"href":"https:\/\/inform.click\/et\/wp-json\/wp\/v2\/posts\/247685\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/inform.click\/et\/wp-json\/wp\/v2\/media\/209172"}],"wp:attachment":[{"href":"https:\/\/inform.click\/et\/wp-json\/wp\/v2\/media?parent=247685"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/inform.click\/et\/wp-json\/wp\/v2\/categories?post=247685"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/inform.click\/et\/wp-json\/wp\/v2\/tags?post=247685"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}