Saada või sure (kvaliteediga või ilma?)

Üks ideedest, mis mind intrigeerib, on "laevake või sure" mentaliteet. Seoses sellega, kuidas seda nimetatakse, on selle variatsioone, kuid fraasi idee on lihtne:

Kui teil on idee, viige see kontseptsioonist tooteni nii kiiresti kui võimalik.

Muidugi võib idee jõuda toote kontseptsioonini nimetada ka "kontseptsiooniks sularahaks", kuid kunagi pole garantiid, et teenite raha, eks? Siiski on garantii, et saate sellest käegakatsutava toote.

Ja tarkvaraarenduse ringkondades on alati palju, mida inimene saab idee poolt või vastu vaielda. Minu peast tulevad kohe meelde kaks poolt- ja vastuargumenti:

1. Pro. Tehke kiiresti midagi, mis toimib ja mis [potentsiaalselt] teenib tulu.
2. Con. Nõrk arhitektuur, hooldus, mastaapsus, testitavus jne.

Lühidalt öeldes võib tekkida kompromiss selle vahel, kui kiiresti saate midagi turult tarnida, ja projekti taga oleva arhitektuuri vahel. Mõnikord on, mõnikord ei ole. Üldiselt arvan siiski, et on ohutu eeldada esimest.

Lisaks võivad mõned näha esimest kui lihtsat väljapääsu, mõned võivad näha teist YAGNI harjutusena või veelgi lihtsamalt, et probleemiga saab tegeleda alati, kui see esile kerkib.

Aga mis sellel hetkel pistmist on?

Saada või sure?

Põhjus, miks ma sellest kirjutamisele aega kulutan, on see, et see on midagi, millele mina ja ma kahtlustan, et ka teised meie valdkonna esindajad mõtleme sellele vähemalt natuke. Kõik see on abstraktses tähenduses rääkides hea, kuid proovin siduda selle millegi veidi realistlikumaga.

Üks kord…

Mõned aastad tagasi seisnes esiotsa arendus sisu mähkimises sees- või plokitaseme elementides ja nende kujundamises põhilise CSS-iga?

Meil olid täiustatud tööriistad oma taustakoodiga töötamiseks, kuid esiosa oli suhteliselt lihtne, kui kõrvale jätta võib-olla ettevõtte või meeskonna poolt, kellega koos töötasime, kehtestatud kodeerimisstandardid.

Kuid siis…

Meie seadmed arenesid (mida ma pean teadmiseks heaks ja tehnikas isegi loomulikuks asjaks). Lisaks nimetatud edusammudele on meil nüüd spetsiaalselt esiotsa arendamiseks mõeldud tööriistad, mis on mõnes mõttes sama arenenud kui need, mida kasutame taustatarkvara jaoks.

Muidugi on meil mõned, kes on "täispinu arendajad", kuid mul on hea meel tunnistada, et mul on palju mugavam töötada serveri poolel kui esiotsaga. Kui töötan esiotsa kallal, jään tavaliselt tuttavate tööriistade juurde ja püüan jääda piiresse, mis on määratud sõidurajaga.

See aitab hoida arendust keskendununa, kiirena ja järjepidevana kõigis projektides.

Olgu, mis mõte sellel on?

Iseenesest võiks see rubriik olla pikk postitus, aga ma ei ole huvitatud nii kaugele minemast. Selle asemel võtan ühe lõigu sellest, kuidas esiotsa arendus praegu töötab, ja vaatan, kas ma ei saa seda kasutada oma mõtte selgeks tegemiseks.

Sassy saamine

Võtame näiteks selle, mis CSS-ist on saanud. Meil on keeled lisaks keeltele (nt Sass, mis asub põhi-CSS-i peal või täiendab seda).

Ja meil on protsessorid, mis kompileerivad, minimeerivad, lindavad ja ei lase meil oma tööd näha enne, kui teatud vead ja hoiatused on kvaliteedi huvides parandatud. (Ma ei pea seda halvaks, kuid see näitab meie esiotsa tööriistade kasvavat keerukuse taset või võib-olla küpsust).

Esiotsa arendamine on liiga lihtne, muutkem see keerulisemaks, et saaksime tunda end targemana nende eakaaslaste seas, kes ilmselt tegelevad ettevõtte "kriitilisemate" aspektidega. Pidage meeles, et see on võistlus.

Selles artiklis on kogu asjast humoorikas vaade.

Mõistlik kvaliteet

Et olla selge, ma ei väida, et see on halb, kuid ma ütlen, et asjad, mis kunagi taanduti serveri poolele või kompileeritud keeltele, ulatuvad nüüd läbi kogu veebirakenduse arenduspaki.

Et olla võimalikult kristallselge: olen kõik kvaliteedi poolt. Asjade saatmist ilma selleta võib vaadelda kui vastutustundetuse harjutust.

Kuid ma usun ka, et aja- ja eelarvepiirangutes võimalikult optimaalse, funktsionaalse ja tulemuslikuma koodi kirjutamise vahel tuleb leida tasakaal.

Ma ei usu, hoolimata sellest, kui kõvasti me seda endale peale suruda püüame, et elame arendajate utoopias, kus saame optimeerida, kujundada ja rakendada igas projektis puutumatuid süsteeme.

Tundub siiski, et oleme selle loomiseks teinud kõik endast oleneva, kas pole?

Kuid kas pole ühel hetkel mõtet küsida, kas kõik tööriistad, mida me loome, ja kõik asjad, mida oma projektidesse lisame, eemaldavad just selle, mis meid sellesse tööstusesse viis? Tõenäoliselt on see mõne jaoks teistsugune. Kas on õiglane küsida, et idee omamine, selle ellu viimiseks koodi kirjutamine ja selle probleemi lahendamise nägemine on see, mis meid sellesse aitas?

Siinkohal oleme aga kasutusele võtnud nii palju tööriistu, et andmebaasist brauserini töötava veebirakenduse arenduskeskkonna loomine ja käivitamine on hirmutav ülesanne.

Nii palju asju peab juhtuma enne, kui oleme tegelikult valmis koodi kirjutama hakkama, et see võib muutuda tüütuks ja isegi veidi kurnavaks juba ainuüksi esimeste sammude tegemisel.

Isiklik, lõplik arvamus

Soovin rakendada tugevaid objektorienteeritud tavasid ja tööriistu paljudes projektides, mille kallal koos oma meeskonnaga töötan ja mida teistele saadan, sest tean oma kogemusest, et aeg, dollarid ja andmed, mis võivad kaduma minna, on t adresseeritud igast küljest.

See ei tähenda, et millegi tarnimine muudaks selle kõik ümber. Kuid projekti taga oleva koodi protsess ja korraldus on midagi, mida mul on väga raske ignoreerida nii palju, et tundub, et oleks peaaegu halvatud tarnida midagi, mida pole testitud ja kontrollitud võimalikult kõrgel tasemel (ja isegi siis on probleemid).

Teisest küljest aga on osa minust, kes soovib katsetada ideed või kahte ideed "saada või sure" mentaliteedi taga, lihtsalt näha, kui kiiresti saab midagi ehitada, tarnida ja teenida mis tahes tulu, olenemata sellest, kui puutumata. koodi alus on.

Ja võib-olla proovin seda mõne tulevase projektiga.