Skicka det eller dö (med eller utan kvalitet, dock?)

En av idéerna som fängslar mig är "ship it or die"-mentaliteten. När det gäller vad det heter finns det variationer av det, men tanken bakom frasen är enkel:

Om du har en idé, få den från idé till produkt så snabbt som möjligt.

Visst, idén att komma till konceptet för en produkt kan också kallas "koncept till kontanter", men det finns aldrig en garanti för att du kommer att generera pengar, eller hur? Det finns dock en garanti för att du kan få det till en påtaglig produkt.

Och i mjukvaruutvecklingskretsar finns det alltid mycket som en person kan argumentera för eller emot idén. De två för- och nackdelarna som jag tänker på omedelbart är:

1. Pro. Att få något gjort snabbt som fungerar och som [potentiellt] genererar intäkter.
2. Con. Svag arkitektur, underhåll, skalbarhet, testbarhet och så vidare.

Kort sagt, det kan finnas en avvägning mellan hur snabbt du kan få fartyget något för en marknad och arkitekturen bakom projektet. Ibland finns det, ibland finns det inte. Generellt sett tror jag dock att det är säkert att anta det förra.

Dessutom kan vissa se det förra som den enkla vägen ut, vissa kan se det senare som en övning i YAGNI eller, ännu enklare, att problemet kan åtgärdas när det dyker upp.

Men vad har detta med någonting att göra just nu?

Skicka det eller dö?

Hela anledningen till att jag lägger ner tid på att skriva om det här är att det är något som jag, och jag misstänker andra inom vårt område, tänker på åtminstone lite. Allt detta är bra när man pratar om det i abstrakt bemärkelse, men låt mig försöka knyta det till något lite mer realistiskt.

Det var en gång…

För några år sedan bestod front-end-utveckling av att linda in innehåll i inline- eller blocknivåelement och styla dem med grundläggande CSS?

Vi hade avancerade verktyg för att arbeta med vår backend-kod, men gränssnittet var relativt enkelt bortsett från kanske kodningsstandarderna som tillämpades av företaget eller teamet som vi arbetade med.

Men då…

Våra enheter har utvecklats (vilket jag anser är bra och till och med naturligt inom tekniken). Tillsammans med nämnda framsteg har vi nu byggverktyg specifikt för front-end-utveckling som är lika avancerade i vissa avseenden som de som vi använder för backend-programvara.

Visst, vi har några som är "full stack-utvecklare", men jag är glad att erkänna att jag är mycket mer bekväm med att arbeta på serversidan än front-end. Om jag jobbar på fronten tenderar jag att hålla mig till de verktyg som jag är bekant med och försöka hålla mig inom skyddsräckena som definieras av körfältet där jag kör.

Det hjälper till att hålla utvecklingen fokuserad, snabb och konsekvent över projekt.

Okej, så vad är poängen?

I och för sig kan det här avsnittet bli ett långt inlägg, men jag är inte intresserad av att gå så långt. Istället ska jag ta en bit av hur frontend-utveckling fungerar just nu och se om jag inte kan använda den för att klargöra min poäng.

Blir Sassy

Ta till exempel vad CSS har blivit. Vi har språk ovanpå språk (som Sass som ligger ovanpå, eller lägger till, grundläggande CSS).

Och vi har processorer som kompilerar, minifierar, luddar och hindrar oss från att se vårt arbete innan vissa fel och varningar åtgärdas för kvalitetens skull. (Jag anser inte att detta är en dålig sak, men det visar den växande nivån av komplexitet – eller kanske mognad – hos våra front-end-verktyg).

Front-end-utveckling är alldeles för lätt, låt oss göra det mer komplext så att vi kan känna oss smartare bland de av våra kamrater som tydligen har att göra med mer "kritiska" aspekter av verksamheten. Kom ihåg att detta är en tävling.

Den här artikeln har en humoristisk syn på det hela.

En rimlig grad av kvalitet

För att vara tydlig säger jag inte att detta är en dålig sak, men jag säger att saker som en gång förvisades till serversidan eller till kompilerade språk nu sträcker sig genom hela utvecklingsstacken för en webbapplikation.

För att vara så kristallklar som möjligt: ​​jag är helt för kvalitet. Att frakta saker utan någon grad av det kan ses som en övning i ansvarslöshet.

Men jag tror också att det finns en balans att hitta mellan att skriva den mest optimala, funktionella och presterande koden som är möjlig under begränsningar av tid och budget.

Jag tror inte, hur mycket vi än försöker tvinga på oss det, att vi lever i en utvecklarutopi där vi kan optimera, bygga och implementera orörda system i varje enskilt projekt.

Det verkar dock som att vi har försökt vårt bästa för att skapa det, eller hur?

Men vid något tillfälle, är det inte värt att fråga om alla verktyg som vi skapar och alla saker som vi lägger till i våra projekt tar bort just det som fick oss in i branschen från början? Visst, för vissa av oss är detta troligen annorlunda. Är det rättvist att fråga att det att ha en idé, att skriva kod för att förverkliga den och att se den lösa ett problem är det som förde oss in i fållan?

Vid det här laget har vi dock introducerat så många verktyg att det är en skrämmande uppgift att få igång en utvecklingsmiljö för en webbapplikation som körs från databasen upp till webbläsaren.

Så många saker måste hända innan vi faktiskt är redo att börja skriva kod att det kan bli tråkigt och till och med lite utmattande bara att ta de första stegen för att göra det.

En personlig, slutgiltig åsikt

Jag strävar efter att genomdriva starka objektorienterade metoder och verktyg i många av de projekt jag arbetar med med mitt team och som jag skickar till andra eftersom jag av erfarenhet vet att tiden, pengarna och data som kan gå förlorade för något är t adresserad från alla håll.

Detta är inte att säga att frakt något snabbt förnekar något av det. Men processen och organisationen av koden bakom ett projekt är något som jag har väldigt svårt att ignorera så mycket att det känns nästan förlamande att skicka något som inte har testats och granskats i högsta möjliga grad (och även då finns det problem).

Å andra sidan, men det finns en del av mig som vill experimentera med en idé eller två bakom "ship it or die"-mentaliteten, bara se hur snabbt något kan byggas, fraktas och generera alla typer av intäkter oavsett hur orörda det är. kodbasen är.

Och det kanske jag ska prova med några kommande projekt.