Programavimas

7 pagrindinės judrių kūrėjų kodavimo praktikos

Vikrus programinės įrangos kūrimas nėra susijęs tik su judriais principais ir praktika. Kad sėkmingai išleistų programinę įrangą, kuri teigiamai veikia galutinius vartotojus, sprendžia technines skolas ir patikimai diegia, kūrėjų komanda taip pat turi atsižvelgti į savo judrumą skatinančią kodavimo praktiką ir architektūros standartus.

Technologijų organizacijoms kyla dar svarbesnis dėmesys. Kad ir kaip sunku kurti programinę įrangą, dar sunkiau reguliariai diegti patobulinimus ir atnaujinimus ilgesnį laiką. „Devops CI / CD“ ir „IAC“ (infrastruktūra kaip kodas) praktika iš dalies sprendžia vieną svarbų veiksnį, nes automatika leidžia patikimai ir pakartotinai diegti programas. Pridėkite nuolatinį bandymą, o kūrimo komandos gali patvirtinti, kad kodo pakeitimai neturi įtakos esamoms funkcijoms.

Tačiau senėjant programoms, originalūs kūrėjai pereina prie kitų projektų, o kartais ir kitų kompanijų. Kai prie komandos prisijungia nauji kūrėjai, jie turi išmokti programinės įrangos architektūrą ir suprasti kodą, kad galėtų patikimai ir efektyviai jį pakeisti.

Be to, kūrėjai, kuriantys programas, dažnai nori kurti naujas. Gali atrodyti jauku ir saugu prisirišti prie jūsų sukurtų programų, tačiau pririšti prie savo kodo nėra naudinga jūsų karjerai ar organizacijai.

Geriausias būdas pereiti prie naujų ir įdomių programinės įrangos kūrimo iniciatyvų yra tai, kad jūsų architektūra, programa ir kodas būtų lengvai palaikomi kitų kūrėjų. Judrios komandos ir kūrėjai turi sukurti ir įgyvendinti kodavimo praktiką, palaikančią nuolatinį programinės įrangos kūrimą.

1. Neišradinėkite dviračio iš naujo

Pirmoji kodavimo taisyklė: nekoduokite to, ko nereikia koduoti! Kaip?

  • Apsvarstykite galimybę užduoti klausimus apie reikalavimus. Kodėl funkcija yra svarbi? Kam naudinga? Tiksliau, ištirkite nekodavimo galimybes, kad išspręstumėte problemą. Kartais geriausias sprendimas nėra jokio sprendimo.
  • Ar kažkas jūsų organizacijoje jau užkodavo panašų sprendimą? Galbūt yra mikropaslauga, kurią reikia tiesiog patobulinti, arba programinės įrangos biblioteka, kurią reikia šiek tiek atnaujinti? Prieš koduodami ką nors naujo, būtinai peržiūrėkite savo organizacijos kodų bazę.
  • Ar yra trečiųjų šalių sprendimų, įskaitant prieinamus „SaaS“ įrankius ar atvirojo kodo parinktis, kurie atitinka minimalius reikalavimus?
  • Ar ieškojote atvirų kodavimo saugyklų, tokių kaip „GitHub“, kur rasite kodo pavyzdžių ir fragmentų, atitinkančių jūsų organizacijos atitikties reikalavimus?

2. Apsvarstykite žemo kodo kūrimo galimybes

Jei jums reikia koduoti sprendimą, galbūt alternatyvios mažo kodo platformos gali padėti efektyviau plėtoti galimybes, palyginti su kodavimu tokiomis kūrimo kalbomis kaip „Java“, .Net, PHP ir „JavaScript“.

Mažo kodo platformos, tokios kaip „Caspio“, „Quick Base“, „Appian“, „OutSystems“ ir „Vantiq“, teikia įrankius, skirtus kurti programas su mažu kodu ir kartais net be kodavimo. Kiekviena platforma specializuojasi skirtingose ​​galimybėse ir todėl yra tinkama konkrečiai programų klasei. Pavyzdžiui, „Caspio“ leidžia lengvai įterpti formas ir darbo eigą į svetaines. „Quick Base“ turi patikimas darbo eigos ir automatizavimo galimybes, o „Vantiq“ įvykių valdoma architektūra tinka daiktų internetui ir kitoms realaus laiko duomenų programoms.

Kartais reikia koduoti, tačiau kūrėjai taip pat turėtų išmanyti vieną ar daugiau mažo kodo kūrimo variantų ir atsižvelgti į juos tinkamiems naudojimo atvejams.

3. Automatizuokite testavimą

Be to, kad parašytumėte reikalavimus atitinkantį kodą, vienas iš svarbiausių dalykų, kuriuos turi atlikti kūrėjai, yra jį išbandyti. Testais pagrįstos kūrimo praktikos ir automatizuoti bandymo įrankiai subrendo, o kūrimo komandos turėtų apimti vieneto, regresijos, našumo ir saugumo testus kaip savo judriojo įvertinimo dalį.

Be testų, leidžiančių patvirtinti versijas ir išleidimus, šie testai taip pat padeda padaryti kodą labiau palaikomą. Testai yra dokumentai ir nustato sutartį, kaip turėtų elgtis kodas. Kai nauji kūrėjai prisijungia prie komandų ir netyčia įgyvendina blogus pakeitimus, nuolatinis testavimas sustabdo kūrimą ir pateikia prasmingą atsiliepimą kūrėjui, kad būtų galima greitai išspręsti problemą.

4. Išveskite visus konfigūracijos parametrus

Kūrėjai neturėtų būti pateisinami, kad kode visuomet būtų sunku įvesti sistemos lygio nustatymus, vartotojo vardus ir slaptažodžius ar kitą konfigūracijos informaciją. Mačiau, kaip kūrėjai kuria nuorodas kurdami prototipus, kurie patenka į gamybos aplinką. Šiandienos architektūroje to niekada nereikėtų daryti. Tvirtas kodavimas nėra techninė skola, bet tingus, neatsakingas kodavimas, galintis sukelti reikšmingų padarinių. Jei kodas atsitiktinai tampa prieinamas, jis sukuria saugos pažeidžiamumą, jei galiniai taškai ar prieigos kredencialai yra atskleisti.

Žengiant dar vieną žingsnį, kai dirbama su senu kodu, bet kokių griežtai užkoduotų konfigūracijų ir parametrų sprendimas turėtų būti neaptariamas techninės skolos prioritetas.

5. Laikykitės pavadinimo tvarkos ir įtraukite komentarus, kad kodas būtų įskaitomas

Kartą dirbau su nepaprastai talentingu kūrėju, kuris gerai nemokėjo anglų kalbos ir nebuvo geriausias mašininke. Jis akimirksniu objektus pavadinimais pavadino a, b, ir c ir tada sukurkite vietinius kintamuosius, pavadintus zz, yy, xx. Jis įsipareigojo tai išvalyti prieš išleidimą, tačiau retai kada sekė.

Jums nereikėtų turėti poros ar minios programavimo, kad suprastumėte, jog tai yra siaubinga praktika.

Komandos turėtų laikytis pavadinimų suteikimo tvarkos, pvz., „Google“ „JavaScript“ stiliaus vadovo ir „Java“ stiliaus vadovo, ir įsipareigoti komentuoti kodą bent jau moduliniu lygiu, o idealiu atveju - klasės lygiu. Be to, organizacijos turėtų apsvarstyti galimybę naudoti statinio kodo analizės įrankius, kurie teikia grįžtamąjį ryšį kūrėjams, kai kodą reikia pertvarkyti dėl struktūros ir įskaitomumo veiksnių.

6. Dažnai tikrinkite kodą į versijų valdymą

Jei kasdien ar dažniau netikrinate kodo, kaip valdyti versiją, tai gali sukelti konfliktų ir kitų blokų, darančių įtaką komandai. Dėl vienos nedidelės klaidos judrios komandos gali praleisti savo sprinto įsipareigojimus arba sukurti papildomą darbą, kad išspręstų priklausomybes.

Komandos turėtų susitarti dėl kodų, kurie nėra paruošti gamybai, tikrinimo tvarkos. Įprasti metodai apima funkcijų vėliavas ir „Git“ šakojimą.

7. Venkite užkoduoti herojiškumą ir sudėtingumą

Daugelis mano pažįstamų kūrėjų tapo profesionaliais programinės įrangos inžinieriais, nes jiems patinka spręsti kodavimo uždavinius. Kodavimas yra menas, mokslas ir amatas, o geresni kūrėjai siekia susimąstyti skatinančių kodavimo užduočių ir elegantiškų įgyvendinimų.

Išskyrus pilką liniją tarp iššūkių keliančių verslo ir techninių uždavinių ir kodavimo herojiškumo, kurie kitiems kūrėjams palieka sunkiai suprantamą ir sudėtingai prižiūrimą kodą.

Tiems iš mūsų, kurie kurį laiką kodavo, mes prisimename „Perl“ vienos linijos patogumą arba naudodami įdėtus šablonus C ++. Kartais yra rimtų priežasčių naudoti šiuos metodus, tačiau jei nauja kūrėjų grupė nesupranta šių metodų, sudėtingiau pakeisti kodą. Kartais paprastesnės, bet ne tokios elegantiškos kodavimo praktikos yra geresnės.

Lankstaus programinės įrangos kūrimo judrumas

Ritualai, įterpti į nesąžiningą ir judrų vystymąsi, įskaitant įsipareigojimus, pasirengimą, sprinto apžvalgas ir retrospektyvas, dabar yra patikrinta praktika, leidžianti bendradarbiauti komandoje ir skatinti sėkmingą įgyvendinimą. Tačiau norėdami parodyti judrumą ilgą laiką, kūrėjai turi prisiimti atsakomybę ir kodavimo praktiką, kuri leidžia palaikyti ir išplėsti savo kuriamą kodą.

Kūrėjų grupės turi kritiškai vertinti savo kodavimo praktiką. Tai ne tik pakankamai gera demonstruoti ir išleisti šiandien; taip pat labai svarbu leisti kitiems lengvai prižiūrėti programą ir kodą.

$config[zx-auto] not found$config[zx-overlay] not found