🥇Infrastruktur als Code: Wéi iwwerwanne ech Probleemer mat XP

Moien, Habr! Virdrun hunn ech iwwer Liewen an der Infrastruktur als Code Paradigma beschwéiert an näischt ugebueden fir déi aktuell Situatioun ze léisen. Haut sinn ech zréck fir Iech ze soen wat Approchen a Praktiken Iech hëllefen aus dem Ofgrond vun der Verzweiflung ze flüchten an d'Situatioun an déi richteg Richtung ze steieren.

Am fréieren Artikel "Infrastruktur als Code: éischt Bekannten" Ech hunn meng Impressioune vun dësem Gebitt gedeelt, probéiert iwwer déi aktuell Situatioun an dësem Beräich ze reflektéieren, a souguer virgeschloen datt Standardpraktiken, déi all Entwéckler bekannt sinn, hëllefe kënnen. Et kéint schéngen datt et vill Reklamatiounen iwwer d'Liewen goufen, awer et goufe keng Propositioune fir e Wee aus der aktueller Situatioun.

Wien mir sinn, wou mir sinn a wéi eng Problemer mir hunn

Mir sinn am Moment am Sre Onboarding Team, dat aus sechs Programméierer an dräi Infrastrukturingenieuren besteet. Mir probéieren all Infrastruktur als Code (IaC) ze schreiwen. Mir maachen dëst well mir am Fong wësse wéi Code schreiwen an eng Geschicht hunn fir "iwwerduerchschnëttlech" Entwéckler ze sinn.

Mir hunn eng Rei vu Virdeeler: e gewëssenen Hannergrond, Wëssen iwwer Praktiken, d'Fäegkeet fir Code ze schreiwen, e Wonsch nei Saachen ze léieren.
An et gëtt e Schiefdeel, deen och e Minus ass: Mangel u Wëssen iwwer Infrastruktur Hardware.

Den Technologiestack dee mir an eisem IaC benotzen.

Terraform fir Ressourcen ze kreéieren.
Packer fir d'Zesummestellung vu Biller. Dëst ass Windows, CentOS 7 Biller.
Jsonnet fir e mächtege Bau an drone.io ze maachen, wéi och fir Packer json an eis Terraform Moduler ze generéieren.
Azur.
Ansibel wann Dir Biller virbereet.
Python fir Hëllefsservicer a Bestëmmungsskripter.
An all dëst am VSCode mat Plugins gedeelt tëscht Teammemberen.

Conclusioun aus mengem leschten Artikel war esou: Ech hu probéiert (virun allem a mir selwer) Optimismus z'investéieren, ech wollt soen datt mir déi Approche a Praktiken probéieren, déi eis bekannt sinn, fir mat de Schwieregkeeten a Komplexitéiten ze këmmeren déi an dësem Beräich existéieren.

Mir kämpfen de Moment mat de folgenden IaC Themen:

Imperfektioun vun Tools a Mëttele fir Code Entwécklung.
Lues Deployment. Infrastruktur ass Deel vun der realer Welt, an et ka lues sinn.
Mangel u Approche a Praktiken.
Mir sinn nei a wëssen net vill.

Extrem Programméierung (XP) zur Rettung

All Entwéckler sinn vertraut mat Extreme Programming (XP) an d'Praktiken déi hannendrun stinn. Vill vun eis hu mat dëser Approche geschafft, an et ass erfollegräich. Also firwat net d'Prinzipien a Praktiken benotzen déi do festgeluecht sinn fir Infrastruktur Erausfuerderungen ze iwwerwannen? Mir hunn decidéiert dës Approche ze huelen a kucken wat geschitt.

Iwwerpréift d'Uwendbarkeet vun der XP Approche fir Är IndustrieHei ass eng Beschreiwung vun der Ëmwelt fir déi XP gutt gëeegent ass, a wéi et mat eis ass:

1. Dynamesch änneren Software Ufuerderunge. Et war eis kloer wat d'Ennziel war. Awer d'Detailer kënne variéieren. Mir selwer entscheeden wou mir Taxi brauchen, sou datt d'Ufuerderunge periodesch änneren (haaptsächlech vun eis selwer). Wa mir d'SRE-Team huelen, déi d'Automatisatioun selwer mécht, a selwer d'Ufuerderungen an den Ëmfang vun der Aarbecht limitéiert, da passt dëse Punkt gutt.

2. Risiken verursaacht duerch fixen Zäitprojeten déi nei Technologie benotzen. Mir kënne Risiken begéinen wann Dir e puer Saachen benotzt déi eis onbekannt sinn. An dëst ass 100% eise Fall. Eise ganze Projet war d'Benotzung vun Technologien déi mir net ganz vertraut waren. Am Allgemengen ass dëst e konstante Problem, well ... Et gi vill nei Technologien déi ëmmer am Infrastruktursektor entstinn.

3,4. Klengt, co-lokaliséiert erweidert Entwécklungsteam. Déi automatiséiert Technologie déi Dir benotzt erlaabt Eenheeten a funktionell Tester. Dës zwee Punkte passen eis net ganz. Éischtens si mir keng koordinéiert Equipe, an zweetens sinn et néng vun eis, déi als eng grouss Equipe ugesi kënne ginn. Obwuel, no e puer Definitioune vun engem "grouss" Equipe, vill ass 14+ Leit.

Loosst eis e puer XP Praktiken kucken a wéi se d'Geschwindegkeet an d'Qualitéit vum Feedback beaflossen.

XP Feedback Loop Prinzip

A mengem Verständnis ass de Feedback d'Äntwert op d'Fro, maachen ech dat richtegt, gi mir dohinner? XP huet e gëttlecht Schema fir dëst: eng Zäitfeedback-Loop. Déi interessant Saach ass datt wat méi niddereg mir sinn, dest méi séier kënne mir den OS kréien fir déi néideg Froen ze beäntweren.

Dëst ass en zimlech interessant Thema fir ze diskutéieren, datt an eiser IT Industrie et méiglech ass séier en OS ze kréien. Stellt Iech vir wéi schmerzhaft et ass e Projet fir sechs Méint ze maachen an eréischt dann erauszefannen datt et am Ufank e Feeler war. Dëst geschitt am Design an an all Konstruktioun vu komplexe Systemer.

An eisem Fall vun IaC, Feedback hëlleft eis. Ech maachen direkt eng kleng Upassung un d'Diagramm hei uewen: de Verëffentlechungsplang huet kee monatlecht Zyklus, awer geschitt e puer Mol am Dag. Et ginn e puer Praktiken, déi un dësem OS Zyklus verbonne sinn, op déi mir méi detailléiert kucken.

Wichteg: Feedback kann eng Léisung fir all uewe genannte Problemer sinn. Kombinéiert mat XP Praktiken, kann et Iech aus dem Ofgrond vun der Verzweiflung zéien.

Wéi Dir Iech aus dem Ofgrond vun der Verzweiflung zitt: dräi Praktiken

Tester

Tester ginn zweemol an der XP Feedback Loop ernimmt. Et ass net nëmmen esou. Si sinn extrem wichteg fir déi ganz Extreme Programméierungstechnik.

Et gëtt ugeholl datt Dir Eenheets- an Akzeptanztests hutt. E puer ginn Iech Feedback an e puer Minutten, anerer an e puer Deeg, sou datt se méi laang daueren fir ze schreiwen a manner dacks iwwerpréift ginn.

Et gëtt eng klassesch Testpyramid, déi weist datt et méi Tester sollte ginn.

Wéi gëllt dëse Kader fir eis an engem IaC-Projet? Eigentlech ... guer net.

Eenheetstester, trotz der Tatsaach, datt et vill solle sinn, kënnen net ze vill sinn. Oder si testen eppes ganz indirekt. Tatsächlech kënne mir soen datt mir se guer net schreiwen. Awer hei sinn e puer Uwendungen fir sou Tester déi mir konnten maachen:
1. Jsonnet Code testen. Dëst, zum Beispill, ass eis Drone Assemblée Pipeline, déi zimlech komplizéiert ass. Den jsonnet Code ass gutt vun Tester ofgedeckt.
  Mir benotzen dëst Eenheet Test Kader fir Jsonnet.
2. Tester fir Skripte déi ausgefouert ginn wann d'Ressource ufänkt. Skripte ginn am Python geschriwwen, an dofir kënnen Tester drop geschriwwe ginn.
Et ass potenziell méiglech d'Konfiguratioun an Tester ze kontrolléieren, awer mir maachen dat net. Et ass och méiglech d'Konfiguratiounsregele fir d'Konfiguratioun vun de Ressourcen ze konfiguréieren flint. Wéi och ëmmer, d'Schecken do sinn einfach ze Basis fir Terraform, awer vill Testskripte gi fir AWS geschriwwen. A mir sinn op Azure, sou datt dëst erëm net gëlt.
Komponentintegratiounstester: et hänkt dovun of wéi Dir se klasséiert a wou Dir se setzt. Mä si schaffen am Fong.
Dëst ass wéi Integratiounstester ausgesinn.

Dëst ass e Beispill wann Dir Biller am Drone CI bauen. Fir se z'erreechen, musst Dir 30 Minutte waarden bis de Packer Bild geformt gëtt, da waart nach 15 Minutten bis se passéieren. Awer si existéieren!
Bild Verifikatioun Algorithmus
1. Packer muss éischt d'Bild komplett virbereeden.
2. Nieft dem Test gëtt et eng Terraform mat engem lokale Staat, dee mir benotze fir dëst Bild z'installéieren.
3. Beim Ausklappen gëtt e klenge Modul, deen an der Géigend läit, benotzt fir et méi einfach mat dem Bild ze schaffen.
4. Wann de VM aus dem Bild ofgesat ass, kënnen d'Schecken ufänken. Prinzipiell gi Kontrollen mam Auto duerchgefouert. Et kontrolléiert wéi d'Skripte beim Startup geschafft hunn a wéi d'Dämone funktionnéieren. Fir dëst ze maachen, iwwer ssh oder winrm aloggen mir op déi nei opgehuewe Maschinn a kontrolléieren de Konfiguratiounsstatus oder ob d'Servicer op sinn.
D'Situatioun ass ähnlech mat Integratiounstester a Moduler fir Terraform. Hei ass eng kuerz Tabell déi d'Features vun esou Tester erkläert.

Feedback op der Pipeline ass ongeféier 40 Minutten. Alles geschitt fir eng ganz laang Zäit. Et kann fir Regressioun benotzt ginn, awer fir nei Entwécklung ass et allgemeng onrealistesch. Wann Dir ganz, ganz bereet sidd fir dëst, preparéiert Lafen Scripten, da kënnt Dir et op 10 Minutten reduzéieren. Awer dëst sinn nach ëmmer net Eenheetstester, déi 5 Stécker a 100 Sekonnen maachen.

D'Feele vu Eenheetstester beim Montage vun Biller oder Terraform Moduler encouragéiert d'Verréckelung vun der Aarbecht op getrennte Servicer, déi einfach iwwer REST oder op Python Scripte kënne lafen.

Zum Beispill musse mir sécher sinn datt wann déi virtuell Maschinn ufänkt, se sech am Service registréiert Skala FT, a wann déi virtuell Maschinn zerstéiert gouf, huet se selwer geläscht.

Well mir ScaleFT als Service hunn, si mir gezwongen mat der API ze schaffen. Do war e Wrapper geschriwwen, deen Dir konnt zéien a soen: "Gitt eran a läscht dat an dat." Et späichert all déi néideg Astellungen an Zougang.

Mir kënne schonn normal Tester dofir schreiwen, well et net anescht ass wéi gewéinlech Software: eng Aart Apiha gëtt gespott, Dir zitt et a kuckt wat geschitt.

Resultater vun den Tester: Eenheetsprüfung, déi den OS an enger Minutt sollt ginn, gëtt et net. An Typen vun Tester méi héich an der Pyramid sinn effektiv, awer decken nëmmen en Deel vun de Probleemer.

Pair programméiere

Tester sinn natierlech gutt. Dir kënnt vill vun hinnen schreiwen, si kënne vu verschiddenen Typen sinn. Si wäerten op hiren Niveauen schaffen an eis Feedback ginn. Awer de Problem mat schlechten Eenheetstester, déi de schnellsten OS ginn, bleift. Zur selwechter Zäit wëll ech nach ëmmer e schnelle OS dat einfach an agreabel ass fir mat ze schaffen. Net ze ernimmen d'Qualitéit vun der doraus resultéierend Léisung. Glécklecherweis ginn et Techniken déi nach méi séier Feedback kënne bidden wéi Eenheetstester. Dëst ass Pair Programméierung.

Wann Dir Code schreift, wëllt Dir sou séier wéi méiglech Feedback iwwer seng Qualitéit kréien. Jo, Dir kënnt alles an enger Feature-Branche schreiwen (fir näischt fir iergendeen ze briechen), eng Pull-Ufro am Github maachen, et un een deem seng Meenung Gewiicht huet a waart op eng Äntwert.

Awer Dir kënnt laang waarden. D'Leit sinn all beschäftegt, an d'Äntwert, och wann et eng ass, ass vläicht net vun der héchster Qualitéit. Ugeholl datt d'Äntwert direkt koum, de Rezensor huet direkt d'ganz Iddi verstanen, awer d'Äntwert kënnt nach spéit, no der Tatsaach. Ech wënschen et war fréier. Dëst ass wat d'Paarprogramméierung zielt - direkt, am Schreiwen.

Drënner sinn d'Paarprogramméierungsstiler an hir Uwendung beim Schaffen un IaC:

1. Klassesch, Erlieft + Erlieft, Verréckelung vun Timer. Zwou Rollen - Chauffer an Navigator. Zwee Leit. Si schaffen um selwechte Code a wiesselen Rollen no enger bestëmmter virbestëmmter Zäit.

Loosst eis d'Kompatibilitéit vun eise Probleemer mam Stil betruechten:

Problem: Imperfektioun vun Tools an Tools fir Code Entwécklung.
Negativ Impakt: Et dauert méi laang fir sech z'entwéckelen, mir bremsen, den Tempo/Rhythmus vun der Aarbecht verléiert.
Wéi mir kämpfen: Mir benotzen en anert Tooling, eng gemeinsam IDE a léieren och Ofkiirzungen.
Problem: Lues Deployment.
Negativ Impakt: vergréissert d'Zäit déi et hëlt fir en Aarbechtsstéck Code ze kreéieren. Mir langweilen eis beim Waarden, eis Hänn riichten aus fir soss eppes ze maachen wärend mir waarden.
Wéi mir kämpfen: mir hunn et net iwwerwonne.
Problem: Mangel u Approchen a Praktiken.
Negativ Impakt: et gëtt kee Wëssen iwwer wéi et gutt ass a wéi et schlecht ass. Verlängert den Empfang vu Feedback.
Wéi mir kämpfen: géigesäitege Meenungsaustausch a Praktiken a Koppelaarbecht léist de Problem bal.

Den Haaptproblem mam Gebrauch vun dësem Stil am IaC ass den ongläiche Tempo vun der Aarbecht. An der traditioneller Softwareentwécklung hutt Dir eng ganz eenheetlech Bewegung. Dir kënnt fënnef Minutten verbréngen a schreiwen N. Verbréngt 10 Minutten a schreift 2N, 15 Minutten - 3N. Hei kënnt Dir fënnef Minutten verbréngen an N schreiwen, an dann nach eng 30 Minutten verbréngen an en Zéngtel vun N schreiwen. Hei wësst Dir näischt, Dir sidd fest, domm. D'Enquête brauch Zäit an distractéiert vun der programméiere selwer.

Fazit: a senger reiner Form ass et fir eis net gëeegent.

2. Ping-Pong. Dës Approche beinhalt eng Persoun déi den Test schreift an eng aner d'Ëmsetzung dofir. Wann Dir d'Tatsaach berücksichtegt datt alles mat Eenheetstester komplizéiert ass, an Dir musst en Integratiounstest schreiwen deen eng laang Zäit brauch fir ze programméieren, geet all d'Liichtegkeet vum Ping-Pong ewech.

Ech ka soen datt mir probéiert hunn d'Verantwortung ze trennen fir en Testskript ze designen an de Code dofir ëmzesetzen. Ee Participant koum mam Skript, an dësem Deel vun der Aarbecht war hie verantwortlech, hien hat dat lescht Wuert. An déi aner war responsabel fir d'Ëmsetzung. Et huet gutt geklappt. D'Qualitéit vum Skript mat dëser Approche erhéicht.

Fazit: leider, den Tempo vun der Aarbecht erlaabt net d'Benotzung vu Ping-Pong als Pair Programméierungspraxis am IaC.

3.Strong Style. Schwéier Praxis. D'Iddi ass datt ee Participant den Direktivnavigator gëtt, an deen zweeten d'Roll vum Ausféierungsfuerer iwwerhëlt. An dësem Fall läit d'Recht fir Entscheedungen ze treffen exklusiv vum Navigator. De Chauffer dréckt nëmmen a kann beaflossen wat mat engem Wuert geschitt. D'Rollen änneren net fir eng laang Zäit.

Gutt fir ze léieren, awer erfuerdert staark mëll Fäegkeeten. Dëst ass wou mir gefall sinn. D'Technik war schwéier. An et geet net emol ëm Infrastrukturen.

Fazit: et kann potenziell benotzt ginn, mir ginn net op ze probéieren.

4. Mobbing, swarming an all bekannt, awer net opgezielt Stiler Mir betruechten et net, well Mir hunn et net probéiert an et ass onméiglech doriwwer am Kontext vun eiser Aarbecht ze schwätzen.

Allgemeng Resultater iwwer d'Benotzung vu Pairprogramméierung:

Mir hunn en ongläiche Tempo vun der Aarbecht, wat konfus ass.

Mir sinn an net genuch gutt Soft Fäegkeeten gerannt. An de Fachberäich hëlleft net fir dës Mängel vun eis ze iwwerwannen.

Laang Tester a Probleemer mat Tools maachen gepaart Entwécklung schwéier.

5. Trotzdem gouf et Erfolleger. Mir sinn mat eiser eegener Method "Konvergenz - Divergenz" erauskomm. Ech wäert kuerz beschreiwen wéi et funktionnéiert.

Mir hunn permanent Partner fir e puer Deeg (manner wéi eng Woch). Mir maachen eng Aufgab zesummen. Mir sëtzen eng Zäitchen zesummen: deen een schreift, deen aneren sëtzt a kuckt d'Supportteam. Da verspree mir eng Zäitchen, jidderee mécht e puer onofhängeg Saachen, da komme mir erëm zesummen, synchroniséiere ganz séier, maachen eppes zesummen an verspreet dann erëm.

Planung a Kommunikatioun

De leschte Block vu Praktiken duerch déi OS Probleemer geléist ginn ass d'Organisatioun vun der Aarbecht mat den Aufgaben selwer. Dëst beinhalt och den Erfarungsaustausch, deen ausserhalb vun der Pairaarbecht ass. Loosst eis dräi Praktiken kucken:

1. Ziler duerch d'Zil Bam. Mir hunn d'Gesamtmanagement vum Projet organiséiert duerch e Bam deen endlos an d'Zukunft geet. Technesch gëtt den Tracking am Miro gemaach. Et gëtt eng Aufgab - et ass en Zwëschenziel. Vun et ginn entweder méi kleng Ziler oder Gruppen vun Aufgaben. D'Aufgabe selwer kommen vun hinnen. All Aufgaben ginn op dësem Board erstallt an ënnerhalen.

Dëse Schema liwwert och Feedback, wat eemol am Dag geschitt wann mir bei Rallyen synchroniséieren. E gemeinsame Plang viru jidderengem ze hunn, awer strukturéiert a komplett oppen, erlaabt jidderee sech bewosst ze sinn wat geschitt a wéi wäit mir fortgeschratt sinn.

Virdeeler vun visueller Visioun vun Aufgaben:

Kausalitéit. All Aufgab féiert zu engem globale Zil. Aufgaben ginn a méi kleng Ziler gruppéiert. D'Infrastruktur Domain selwer ass zimlech technesch. Et ass net ëmmer direkt kloer wéi eng spezifesch Impakt, zum Beispill, e Runbook ze schreiwen iwwer d'Migratioun op eng aner nginx op d'Geschäft huet. D'Zilkaart an der Géigend ze hunn mécht et méi kloer.

Kausalitéit ass eng wichteg Eegeschafte vu Probleemer. Et beäntwert direkt d'Fro: "Maachen ech déi richteg Saach?"
Parallelismus. Et sinn néng vun eis, an et ass einfach kierperlech onméiglech jiddereen op eng Aufgab ze geheien. Aufgaben aus engem Beräich kënnen och net ëmmer duergoen. Mir si gezwongen, d'Aarbecht tëscht klengen Aarbechtsgruppen parallel ze maachen. Zur selwechter Zäit sëtzen d'Gruppen eng Zäit laang op hir Aufgab, si kënne vun engem aneren verstäerkt ginn. Heiansdo falen d'Leit vun dësem Aarbechtsgrupp ewech. Een geet an d'Vakanz, een mécht e Bericht fir den DevOps Conf, een schreift en Artikel iwwer Habr. Wësse wat Ziler an Aufgaben parallel gemaach kënne ginn ass ganz wichteg.

2. Ersatz Presentateur vun Moien Reuniounen. Bei Stand-ups hu mir dëse Problem - d'Leit maachen vill Aufgaben parallel. Heiansdo sinn Aufgaben locker verbonnen an et gëtt kee Verständnis vu wien wat mécht. An d'Meenung vun engem aneren Teammember ass ganz wichteg. Dëst ass zousätzlech Informatioun déi de Verlaf vun der Léisung vum Problem änneren kann. Natierlech gëtt et normalerweis een bei Iech, awer Rotschléi an Tipps sinn ëmmer nëtzlech.

Fir dës Situatioun ze verbesseren, hu mir d'Technik "Changing the Leading Stand-Up" benotzt. Elo ginn se no enger bestëmmter Lëscht rotéiert, an dat huet säin Effekt. Wann et Ären Tour ass, sidd Dir gezwongen ze dauchen an ze verstoen wat lass ass fir eng gutt Scrum Versammlung ze maachen.

3. Intern Demo. Hëllef bei der Léisung vun engem Problem vu Pairprogramméierung, Visualiséierung um Problembaum an Hëllef bei Scrumversammlungen moies si gutt, awer net ideal. Als Koppel sidd Dir nëmmen duerch Äert Wëssen limitéiert. Den Taskbaum hëlleft global ze verstoen wien wat mécht. An de Presentateur an d'Kollegen op der Moienversammlung dauchen net déif an Är Problemer. Si kënne sécherlech eppes verpassen.

D'Léisung gouf fonnt fir d'Aarbecht mateneen ze demonstréieren an duerno ze diskutéieren. Mir treffen eis eemol d'Woch fir eng Stonn a weisen Detailer vu Léisunge fir Aufgaben déi mir an der leschter Woch gemaach hunn.

Wärend der Demonstratioun ass et néideg d'Detailer vun der Aufgab z'entdecken a sécher ze sinn, seng Operatioun ze demonstréieren.

De Bericht kann mat enger Checklëscht duerchgefouert ginn.1. Gitt an de Kontext. Wou ass d'Aufgab hierkënnt, firwat war se iwwerhaapt néideg?

2. Wéi war de Problem virdrun geléist? Zum Beispill war massive Mausklick erfuerderlech, oder et war onméiglech guer näischt ze maachen.

3. Wéi mir et verbesseren. Zum Beispill: "Kuckt, elo gëtt et Scriptosik, hei ass de Readme."

4. Weist wéi et funktionnéiert. Et ass ubruecht e puer Benotzer Szenario direkt ëmzesetzen. Ech wëll X, ech maachen Y, ech gesinn Y (oder Z). Zum Beispill deployéieren ech NGINX, fëmmen d'URL, a kréien 200 OK. Wann d'Aktioun laang ass, preparéiert se am Viraus fir datt Dir se spéider weist. Et ass unzeroden et net ze vill eng Stonn virun der Demo ze briechen, wann et fragil ass.

5. Erkläert wéi erfollegräich de Problem geléist gouf, wéi eng Schwieregkeeten bleiwen, wat net fäerdeg ass, wéi eng Verbesserungen an Zukunft méiglech sinn. Zum Beispill, elo CLI, da gëtt et voll Automatisatioun am CI.

Et ass ubruecht fir all Spriecher et op 5-10 Minutten ze halen. Wann Är Ried selbstverständlech wichteg ass a méi laang dauert, koordinéiert dëst am Viraus am sre-Ofhuelen Kanal.

Nom Face-to-Face Deel gëtt et ëmmer eng Diskussioun am Fuedem. Hei erschéngt de Feedback, dee mir brauchen iwwer eis Aufgaben.

Als Resultat gëtt eng Ëmfro gemaach fir d'Nëtzlechkeet vun deem wat geschitt ass ze bestëmmen. Dëst ass Feedback iwwert d'Essenz vun der Ried an d'Wichtegkeet vun der Aufgab.

Laang Conclusiounen a wat d'nächst

Et kann schéngen datt den Toun vum Artikel e bësse pessimistesch ass. Dëst ass falsch. Zwee méi niddereg Niveaue vu Feedback, nämlech Tester a Pairprogramméierung, funktionnéieren. Net sou perfekt wéi an der traditioneller Entwécklung, awer et gëtt e positiven Effekt dovun.

Tester, an hirer aktueller Form, bidden nëmmen deelweis Code Ofdeckung. Vill Konfiguratiounsfunktiounen sinn net getest. Hiren Afloss op déi tatsächlech Aarbecht beim Schreiwen vum Code ass niddereg. Wéi och ëmmer, et gëtt en Effekt vun Integratiounstester, a si erlaben Iech ouni Angscht Refactoring ze maachen. Dëst ass eng grouss Leeschtung. Och mat der Verréckelung vum Fokus op d'Entwécklung an héije Sproochen (mir hunn Python, gitt), geet de Problem fort. An Dir braucht net vill Schecken fir de "Kleim"; eng allgemeng Integratiounscheck ass genuch.

Schaffen a Koppelen hänkt méi vu spezifesche Leit of. Do ass den Taskfaktor an eis mëll Fäegkeeten. Bei munchen klappt et ganz gutt, bei aneren klappt et méi schlecht. Et ginn definitiv Virdeeler vun dëser. Et ass kloer datt och wann d'Regele vun der Pairaarbecht net genuch beobachtet ginn, ass d'Tatsaach datt d'Aufgaben zesummen e positiven Effekt op d'Qualitéit vum Resultat hunn. Perséinlech fannen ech a Koppele schaffen méi einfach a méi agreabel.

Méi héich Weeër fir d'OS ze beaflossen - Planung an Aarbecht mat Aufgaben präzis Effekter produzéieren: héichwäerteg Wëssenaustausch a verbessert Entwécklungsqualitéit.