Inxhinieri softuerikeMenaxhimi i projektitkodi i pastëri shkathët
Shpejtësia e zhvillimit kundrejt mirëmbajtjes së kodit
Në botën e teknologjisë me ritme të shpejta, ekipet shpesh përballen me një tërheqje midis 'Shpejtësisë së Zhvillimit' - nxitjes për të dërguar veçori shpejt - dhe 'Mirëmbajtjes së Kodit' - praktikës së shkrimit të kodit të pastër dhe të shkallëzuar që është i lehtë për t'u përditësuar. Ndërsa shpejtësia fiton pjesën e tregut sot, mirëmbajtja siguron që produkti të mos shembet nën peshën e tij nesër.
Theksa
Shpejtësia ju blen kohë në treg, por mirëmbajtja ju blen jetëgjatësi.
Shpejtësia e pakontrolluar çon në 'Kodin e trashëgimisë' që përfundimisht bëhet i pamundur për t'u modifikuar.
Mirëmbajtja është një investim që jep interes 'negativ' në kohën e zhvillimit më vonë.
Ekipet më të suksesshme gjejnë një 'Steady State' që balancon të dy faktorët.
Çfarë është Shpejtësia e zhvillimit?
Shpejtësia me të cilën një ekip mund të kalojë nga një koncept në një veçori të drejtpërdrejtë, funksionale në prodhim.
Shpesh i jep përparësi veçorive të 'Produktit minimal të zbatueshëm' (MVP) për të mbledhur reagime të menjëhershme të përdoruesve.
Mund të përfshijë përdorimin e shkurtoreve, vlerave të koduara ose anashkalimin e paketave gjithëpërfshirëse të testimit.
Thelbësore për startup-et që duhet të provojnë një model biznesi përpara se të mbarojnë kapitali.
Mbështetet shumë në prototipin e shpejtë dhe integrimet e gatshme të palëve të treta.
Mund të çojë në 'Borxh Teknik', i cili vepron si interes financiar në kodin e shkruar keq.
Çfarë është Mirëmbajtja e kodit?
Lehtësia me të cilën softueri mund të kuptohet, korrigjohet dhe përmirësohet gjatë gjithë ciklit të tij jetësor.
Thekson parimet e pastra të kodit, arkitekturën modulare dhe konventat e qëndrueshme të emërtimit.
Kërkon dokumentacion gjithëpërfshirës dhe mbulim të lartë të automatizuar të testit për të parandaluar regresionet.
Redukton 'kohën e hyrjes' për zhvilluesit e rinj që i bashkohen një projekti afatgjatë.
Ul koston totale të pronësisë duke i bërë rregullimet e ardhshme të gabimeve dukshëm më të shpejta.
Siguron që sistemi të mund të shkallëzohet për të trajtuar më shumë përdorues pa kërkuar një rishkrim total.
Tabela Krahasuese
Veçori
Shpejtësia e zhvillimit
Mirëmbajtja e kodit
Objektivi kryesor
Koha në treg
Stabiliteti afatgjatë
Kompleksiteti i kodit
I lartë (rreziku i kodit të spagetit)
E ulët (e strukturuar dhe modulare)
Profili i kostos
E ulët përpara, e lartë më vonë
Lart përpara, e ulët më vonë
Rigoroziteti i testimit
Minimale/Manuale
E gjerë/e automatizuar
Dokumentacioni
E rrallë ose inekzistente
Gjithëpërfshirëse dhe e qartë
Faktori i rrezikut
Brishtësia e sistemit
Dritaret e humbura të tregut
Përshkrim i Detajuar i Krahasimit
Ndikimi i borxhit teknik
Përqendrimi thjesht në shpejtësi krijon borxh teknik, të cilat janë rregullimet "të shpejta dhe të pista" që duhet të adresohen më vonë. Nëse një ekip lëviz shumë shpejt për një kohë të gjatë, borxhi grumbullohet derisa çdo veçori e re të marrë dhjetë herë më shumë kohë për t'u ndërtuar sepse kodi themelor është shumë i brishtë. Mirëmbajtja kërkon ta paguajë këtë borxh paraprakisht përmes dizajnit të kujdesshëm.
Shkallëzueshmëria dhe evolucioni
Një sistem i ndërtuar për shpejtësi shpesh godet një 'tavan' ku nuk mund të trajtojë më shumë të dhëna ose përdorues pa u përplasur. Kodi i mirëmbajtshëm është ndërtuar me shtresa abstraksioni që lejojnë zhvilluesit të ndërrojnë komponentët ose të përmirësojnë infrastrukturën me fërkime minimale. Ky modularitet është ai që ndan një prototip nga një aplikacion profesional i ndërmarrjes.
Morali dhe qarkullimi i zhvilluesit
Puna në një mjedis me shpejtësi të lartë dhe mirëmbajtje të ulët shpesh çon në djegie të zhvilluesve për shkak të 'zjarrit' të vazhdueshëm të insekteve. Anasjelltas, bazat e kodit të mirëmbajtshme nxisin një ndjenjë krenarie dhe i lejojnë zhvilluesit të përqendrohen në ndërtimin e gjërave të reja në vend që të rregullojnë të njëjtën logjikë të prishur. Një bazë kodi e pastër është një nga mjetet më të mira për të mbajtur talentin më të mirë inxhinierik.
Vlera e biznesit me kalimin e kohës
Vlera e biznesit e shpejtësisë është e ngarkuar përpara; ju ndihmon të fitoni garën. Megjithatë, vlera e biznesit e mirëmbajtjes është eksponenciale; Siguron që ju të qëndroni në garë. Shumica e kompanive të suksesshme përfundimisht kalojnë nga një mentalitet 'lëviz shpejt' në një fazë 'rritjeje të qëndrueshme' për të mbrojtur asetet e tyre kryesore.
Përparësi dhe Disavantazhe
Shpejtësia e zhvillimit
Përparësi
+Hyrja më e shpejtë në treg
+Kosto fillestare më e ulët
+Reagime të menjëhershme
+Shkathtësi e lartë
Disavantazhe
−Sistemi i brishtë
−Rregullime të shtrenjta në të ardhmen
−E vështirë për t'u shkallëzuar
−Djegia e lartë e zhvilluesve
Mirëmbajtja e kodit
Përparësi
+Lehtë për t'u shkallëzuar
+Më pak gabime në prodhim
+Hyrje më e shpejtë
+Performancë e qëndrueshme
Disavantazhe
−Nisja fillestare më e ngadaltë
−Kosto më e lartë fillestare
−Rreziku inxhinierik i tepërt
−Reagime të vonuara
Idenë të gabuara të zakonshme
Miti
Shkrimi i kodit të mirëmbajtshëm zgjat gjithmonë dy herë më shumë.
Realiteti
Ndërsa duhet më shumë mendim fillimisht, zhvilluesit me përvojë shpesh shkruajnë kod të mirëmbajtshëm me një ritëm të ngjashëm me kodin 'i çrregullt' sepse përdorin modele të vendosura që parandalojnë gabimet logjike rrethore.
Miti
Borxhi teknik është gjithmonë një gjë e keqe.
Realiteti
Borxhi teknik mund të jetë një mjet strategjik. Ashtu si një kredi biznesi, ju lejon të 'blini' praninë në treg tani për sa kohë që keni një plan të qartë për ta shlyer atë përpara se interesi të shkatërrojë projektin.
Miti
Kodi i mirëmbajtshëm do të thotë 'Pa gabime'.
Realiteti
Gabimet janë të pashmangshme në çdo sistem. Megjithatë, kodi i mirëmbajtshëm i bën ato gabime shumë më të lehta për t'u gjetur, izoluar dhe rregulluar pa prishur tre veçori të tjera të palidhura në proces.
Miti
Ju thjesht mund të 'pastroni kodin' më vonë kur projekti të jetë i suksesshëm.
Realiteti
Në realitet, pasi një projekt është i suksesshëm, presioni për të dërguar veçori zakonisht rritet. Është shumë e rrallë që një ekip të marrë një 'pauzë' mjaftueshëm për të rregulluar rrëmujë arkitekturore të rrënjosura thellë.
Pyetjet më të Përshkruara
Cili është 'raporti i artë' midis shpejtësisë dhe mirëmbajtjes?
Nuk ka përqindje fikse, por një standard i përbashkët i industrisë është rregulli 80/20. Shpenzoni 80 për qind të përpjekjeve tuaja për ofrimin e veçorive dhe 20 për qind për 'rifaktorizimin' ose pagesën e borxhit teknik për të mbajtur bazën e kodit të shëndetshme.
Si mund t'ua shpjegoj nevojën për mirëmbajtje palëve të interesuara jo-teknike?
Përdorni analogjinë e 'Mirëmbajtjes së makinës'. Ju mund të drejtoni një makinë me 100 mph pa ndryshuar kurrë vajin për të kursyer kohë, por përfundimisht, motori do të kapet dhe ju do të ngecni në anë të rrugës ndërsa konkurrentët tuaj ju kalojnë pranë.
A mund të ndihmojnë mjetet e automatizuara me mirëmbajtjen?
Po, mjete si Linters, Analiza Statike dhe SonarQube mund të shënojnë automatikisht kodin e çrregullt ose kompleksitetin e lartë. Megjithatë, këto mjete nuk mund të rregullojnë një arkitekturë thelbësisht të prishur; Kjo ende kërkon dizajn dhe largpamësi njerëzore.
A favorizon zhvillimi Agile shpejtësinë mbi mirëmbajtjen?
Agile shpesh keqinterpretohet si 'lëviz shpejt dhe thyen gjërat', por Agile Manifesto në fakt thekson 'përsosmërinë teknike'. True Agile kërkon mirëmbajtje në mënyrë që ekipi të vazhdojë t'i përgjigjet ndryshimeve në çdo sprint.
Kur është në rregull të injorohet plotësisht mirëmbajtja?
Është e pranueshme për 'Throwaway Prototypes' - kod i shkruar posaçërisht për të testuar një koncept vizual ose një rrjedhë të vetme logjike që ju 100 për qind keni ndërmend ta fshini dhe rishkruani nga e para pasi koncepti të provohet.
Si përshtatet 'Dokumentacioni' në këtë krahasim?
Dokumentacioni është një shtyllë e mirëmbajtjes. Pa të, qëllimi i kodit humbet kur autori origjinal largohet, duke e kthyer në mënyrë efektive kodin 'Speedy' në një kuti të zezë që askush nuk guxon ta prekë.
Cilat janë shenjat e para që shpejtësia po vret projektin tim?
Kërkoni për 'Regression Bugs' (rregullimi i një gjëje thyen një tjetër) dhe një 'Velocity Drop'. Nëse ekipi juaj po punon më shumë, por po përfundon më pak detyra çdo muaj, borxhi teknik ka të ngjarë të bllokojë tubacionin tuaj të zhvillimit.
A është 'Over-Engineering' një rrezik i mirëmbajtjes?
Absolutisht. Zhvilluesit mund të kalojnë javë të tëra duke ndërtuar një sistem 'krejtësisht të shkallëzuar' për një produkt që mund të mos ketë kurrë më shumë se dhjetë përdorues. Qëllimi është mirëmbajtja 'Just-in-Time' - duke ndërtuar për shkallën që prisni në 6-12 muajt e ardhshëm.
Verdikt
Zgjidhni shpejtësinë e zhvillimit për prototipet e fazës së hershme, afate të ngushta ose kur vërtetoni një hipotezë krejt të re tregu. Investoni në mirëmbajtjen e kodit për produktet kryesore të biznesit, sistemet financiare ose çdo aplikacion që synon të jetojë dhe të rritet për më shumë se gjashtë muaj.