Hoe van goed naar geweldig te gaan

Dit is een inleiding tot een meerdelige serie, waar we onderzoeken hoe we front-end ontwikkelingsprocessen efficiënter en schaalbaarder kunnen maken - om sneller een beter product te maken.

Het bouwen van een geweldig product is vaak geen solo-onderneming. De meest uitgebreide opstellingen zouden multiteams van creatief, marketing, product en technologie omvatten. Zelfs als u een bedrijf van één bent, moet u communiceren met uw gebruikers om hun feedback te verzamelen over wat voor hen werkt. Dit iteratieve raamwerk van het cyclische ontwerpproces om de kwaliteit en functie te helpen verbeteren, wordt meestal de Agile Iteration Workflow genoemd.

Hoe sneller je kunt itereren, hoe beter je product zou worden.

Bij StashAway toen het front-end team voor het eerst begon met het bouwen van het webgebaseerde product, waren we op een versnelde tijdlijn om te lanceren en waren onze productontwikkelings- en beheerprocessen minder streng. Nu het product volwassener wordt en er meer functies worden onderzocht en toegevoegd, willen we ons proces voor het bouwen van een betere en meer schaalbare front-end-architectuur voor het product verbeteren en aanscherpen. Onze huidige opzet zou ons niet toelaten om effectief te schalen in termen van aanbod van functies en landuitbreidingen.

Om een ​​geweldig product te maken, moeten we de iteratieworkflow perfectioneren. Daarover bestaat veel literatuur over productbeheer, en dat is niet het bereik van deze reeks artikelen. Wat we willen onderzoeken, is hoe we sneller kunnen zijn met iteraties in de prototyping- en bouwfase, en daarvoor moeten we de interne ontwikkelings- en goedkeuringsprocessen van ons team formaliseren, zodat we efficiënter kunnen samenwerken met onze creatieve en productteams . We denken dat we dat kunnen bereiken door gebruik te maken van een continue integratie en leveringsstroom in combinatie met de bredere product iteratieworkflow zoals eerder uiteengezet.

Uiteindelijk willen we het declaratieve programmeerparadigma benaderen dat aangeeft wat we in onze applicaties willen doen, in plaats van het hoe te dwingen. Om dat te doen, moeten we de basis leggen voor het creëren van onze bouwstenen.

We beginnen met het uitbreiden van onze scheiding van punten van zorg met UI en applicatielogica, zodat de ontwikkeling van UI-componenten een afzonderlijke activiteit wordt. Het zal zijn eigen centrale opslagplaats hebben, samen met gemeenschappelijke hulpprogramma's, een eigen pakket van eenheden, acceptatie- en regressietests. Onze UI-componenten zullen nu herbruikbaar, composeerbaar en themabel zijn, voor variaties van websites en web-apps. In combinatie met Storybook kunnen we een interactieve patroonbibliotheek maken.

We hebben het vertrouwen dat onze UI-componenten er precies zo uit zullen zien en zich zullen gedragen zoals het hoort, zodat we ons kunnen concentreren op de leuke en belangrijke dingen - de applicaties en hoe ze zich moeten gedragen. We kunnen hetzelfde proces met onze UI-componenten toepassen op onze applicatiespecifieke projecten, met meer specifieke testpakketten om de dekking te maximaliseren. Alleen met deze testpakketten kunnen we het vertrouwen van ontwikkelaars in het pushen en implementeren van code vergroten en in ruil daarvoor de iteratiesnelheid verhogen.

Met deze centrale repository van samen te stellen componenten kunnen we prototypen en ideeën voor gang-gebruikers testen en zelfs nieuwe functies in een hoger tempo leveren.

Software testniveaus

Je hebt gemerkt dat we de boodschap hebben gehamerd dat testen belangrijk is. Softwaretests zijn een uitgebreid onderwerp in softwareontwikkeling, maar laten we ons concentreren op de vier testniveaus die integraal deel uitmaken van de soepele werking van een continu leveringsproces: eenheid, integratie, systeem en acceptatie.

We gebruiken unit-tests om afzonderlijke componenten, de kleinste testbare units, in een software te valideren. In ons geval zijn dat meestal de UI-componenten of hulpprogramma's voor hulpprogramma's. Integratietests vinden plaats wanneer de afzonderlijke componenten als een groep worden getest. Dit kan bijvoorbeeld een functie zoals een rekenmachine zijn, waarbij u knoppen en een weergavescherm hebt en ervoor zorgen dat het juiste nummer wordt weergegeven als reactie op een knopdruk. Voor API kan een eindpunt een database-verbinding maken om een ​​set gegevens op te halen.

Unit- en integratietests verwijderen meestal de meest opvallende bugs voordat we beginnen met de implementatie. Het bespaart tijd voor interne en externe testers, die het voltooide en geïntegreerde systeem evalueren op naleving van functies en zakelijke vereisten - domeinen van systeem- en acceptatietests. Zodra de software de vier testniveaus heeft doorstaan, kunnen we deze inzetten voor productie.

Dit is een voorproefje van hoe we van plan zijn om de processen van ons front-end team efficiënter te maken. We zullen in verdere berichten over implementaties in latere berichten over front-end ontwikkeling bij StashAway ingaan. Blijf kijken!

We zijn constant op zoek naar geweldig technisch talent om ons team te versterken - bezoek onze website voor meer informatie en voel je vrij om contact met ons op te nemen!