Lähetä tai kuole (laadulla vai ilman?)

Yksi minua kiehtovista ajatuksista on "lähetä tai kuole" -mentaliteetti. Mitä tulee sen nimeen, siitä on muunnelmia, mutta lauseen idea on yksinkertainen:

Jos sinulla on idea, hanki se konseptista tuotteeksi mahdollisimman nopeasti.

Toki ajatusta tuotteen konseptiin pääsemisestä voidaan kutsua myös "konseptiksi käteiseksi", mutta koskaan ei ole takeita siitä, että aiot tuottaa rahaa, eikö niin? On kuitenkin takuu, että saat siitä konkreettisen tuotteen.

Ja ohjelmistokehityspiireissä on aina paljon, mitä henkilö voi väittää ajatuksen puolesta tai vastaan. Päästäni heti mieleen tulevat kaksi plussaa ja miinusta:

1. Pro. Tehdään nopeasti jotain, joka toimii ja joka [mahdollisesti] tuottaa tuloja.
2. Con. Heikko arkkitehtuuri, ylläpito, skaalautuvuus, testattavuus ja niin edelleen.

Lyhyesti sanottuna voi olla kompromissi sen välillä, kuinka nopeasti saat toimituksen markkinoille, ja projektin taustalla olevan arkkitehtuurin välillä. Joskus on, joskus ei. Yleisesti ottaen uskon kuitenkin, että on turvallista olettaa edellinen.

Lisäksi jotkut saattavat nähdä edellisen helpona ulospääsynä, jotkut saattavat nähdä jälkimmäisen harjoituksena YAGNIssa tai vielä yksinkertaisemmin, että ongelmaan voidaan puuttua aina, kun se tulee esiin.

Mutta mitä tekemistä tällä on minkään kanssa tällä hetkellä?

Lähetä tai kuole?

Koko syy siihen, miksi käytän aikaa tämän kirjoittamiseen, on se, että minä ja epäilen muiden alallamme ajattelevan sitä ainakin vähän. Kaikki tämä on hyvä ja hyvä, kun puhutaan siitä abstraktissa mielessä, mutta yritän yhdistää sen johonkin hieman realistisempaan.

Olipa kerran…

Muutama vuosi sitten etupään kehitys koostui sisällön käärimisestä rivi- tai lohkotason elementteihin ja niiden muotoilusta perus-CSS:llä?

Meillä oli kehittyneitä työkaluja taustakoodimme kanssa työskentelyyn, mutta käyttöliittymä oli suhteellisen yksinkertainen lukuun ottamatta kenties yrityksen tai tiimin, jonka kanssa työskentelimme, noudattamia koodausstandardeja.

Mutta toisaalta…

Laitteemme ovat kehittyneet (mitä pidän tekniikassa hyvänä ja jopa luonnollisena asiana). Mainitun edistyksen ohella meillä on nyt erityisesti käyttöliittymäkehitykseen tarkoitettuja rakennustyökaluja, jotka ovat joiltakin osin yhtä edistyneitä kuin taustaohjelmistoissa käyttämämme työkalut.

Toki meillä on joitakin, jotka ovat "täyden pinon kehittäjiä", mutta olen iloinen voidessani myöntää, että olen paljon mukavampi työskennellä palvelinpuolella kuin käyttöliittymässä. Jos työskentelen etuosan parissa, minulla on tapana pysyä tutuissa työkaluissa ja yrittää pysyä sen kaistan määrittämien suojakaiteiden sisällä, jolla toimin.

Se auttaa pitämään kehityksen keskittyneenä, nopeana ja johdonmukaisena projekteissa.

Okei, mitä järkeä on?

Sinänsä tämä osio voisi olla pitkä postaus, mutta en ole kiinnostunut menemään niin pitkälle. Sen sijaan otan yhden osan siitä, miten käyttöliittymäkehitys toimii juuri nyt, ja katson, enkö voi käyttää sitä tehdäkseni kantani selväksi.

Saada Sassy

Otetaan esimerkiksi se, mikä CSS:stä on tullut. Meillä on kieliä kielten lisäksi (kuten Sass, joka istuu perus-CSS:n päällä tai täydentää sitä).

Ja meillä on prosessoreita, jotka kokoavat, pienentävät, nukkaavat ja estävät meitä näkemästä työtämme ennen kuin tietyt virheet ja varoitukset on korjattu laadun vuoksi. (En pidä tätä huonona asiana, mutta se osoittaa käyttöliittymämme työkalujen kasvavan monimutkaisuuden – tai ehkä kypsyyden).

Etupään kehittäminen on aivan liian helppoa. Tehdään siitä monimutkaisempi, jotta voimme tuntea olonsa älykkäämmiksi niiden kollegoidemme joukossa, jotka ilmeisesti käsittelevät liiketoiminnan "kriittisempiä" puolia. Muista, että tämä on kilpailu.

Tässä artikkelissa on humoristinen näkökulma koko asiaan.

Kohtuullinen laatu

Selvyyden vuoksi en väitä, että tämä on huono asia, mutta sanon, että asiat, jotka aiemmin jäivät palvelinpuolelle tai käännetyille kielille, ulottuvat nyt verkkosovelluksen koko kehityspinon läpi.

Mahdollisimman kristallinkirkas: kannatan laatua. Asioiden lähettäminen ilman minkäänlaista sitä voidaan nähdä vastuuttomuuden harjoituksena.

Mutta uskon myös, että on löydettävä tasapaino optimaalisimman, toimivimman ja tehokkaimman koodin kirjoittamisen välillä ajan ja budjetin rajoitusten puitteissa.

En usko, vaikka kuinka kovasti yritämmekin pakottaa sitä itsellemme, että elämme kehittäjäutopiassa, jossa voimme optimoida, suunnitella ja toteuttaa koskemattomia järjestelmiä jokaisessa yksittäisessä projektissa.

Näyttää kuitenkin siltä, ​​että olemme yrittäneet parhaamme luodaksemme sen, eikö niin?

Mutta eikö jossain vaiheessa kannata kysyä, poistavatko kaikki luomamme työkalut ja kaikki projekteihin lisäämämme asiat sen asian, joka sai meidät alunperinkin alalle? Myönnettäköön, että joillekin meistä tämä on todennäköisesti erilainen. Onko reilua kysyä, että idean omaaminen, koodin kirjoittaminen sen toteuttamiseksi ja sen ratkaisevan ongelman näkeminen ovat se, mikä toi meidät ketjuun?

Tässä vaiheessa olemme kuitenkin ottaneet käyttöön niin monia työkaluja, että kehitysympäristön saaminen käyttöön tietokannasta selaimeen käynnissä olevalle verkkosovellukselle on pelottava tehtävä.

Niin monia asioita on tapahduttava ennen kuin olemme todella valmiita aloittamaan koodin kirjoittamisen, että siitä voi tulla tylsää ja jopa hieman uuvuttavaa jo pelkkä alkuvaihe.

Henkilökohtainen, lopullinen mielipide

Haluan soveltaa vahvoja oliokeskeisiä käytäntöjä ja työkaluja monissa projekteissa, joissa työskentelen tiimini kanssa ja jotka lähetän muille, koska tiedän kokemuksesta, että aika, dollarit ja tiedot, jotka voidaan menettää jostain, ei ole t osoitettu kaikilta puolilta.

Tämä ei tarkoita sitä, että toimittaminen nopeasti mitätöisi mitään. Mutta projektin taustalla olevan koodin prosessi ja organisointi on jotain, jota minun on hyvin vaikea jättää huomiotta niin paljon, että tuntuu lähes halvaantuneelta lähettää jotain, jota ei ole testattu ja tarkistettu parhaalla mahdollisella tavalla (ja silloinkin on ongelmia).

Toisaalta osa minusta haluaa kokeilla ideaa tai kahta "lähetä tai kuole" -ajattelun takana vain nähdä, kuinka nopeasti jotain voidaan rakentaa, toimittaa ja tuottaa kaikenlaisia ​​tuloja riippumatta siitä, kuinka turmeltumaton. koodipohja on.

Ja ehkä yritän sitä joissakin tulevissa projekteissa.