TheCodestReview #2 - viikoittainen ohjelmistotekniikan mehu

Sanasto käsittelemistämme näkökohdista:

1. Refaktorointivinkkejä laadun parantamiseksi.

2. Miksi frontend-arkkitehtuurilla on merkitystä ja miten siitä tehdään skaalautuva ja ylläpidettävä?

3. Siirtyminen CTO teknologiaorganisaation COO-rooliin.

Jos olet kiinnostunut aiheesta, joka koskee siirtymistä teknologiajohtajan roolista operatiiviseen rooliin, voit syventyä postauksen alareunassa oleviin lisäresursseihin.

Tämän viikon refaktorointi- ja arkkitehtuurikommentit ovat Ruby- ja React-insinööriemme toimittamia.

Stephen Bigelow alkaen Search Software Quality

Refaktorointi koodi on aina ollut valtavan suosittu, mutta kaikki eivät tiedä, miten se tehdään hyvin ja milloin on hyvä aika tehdä se. Olen nähnyt monia refaktorointiyrityksiä, jotka ovat päättyneet epäonnistumiseen (erityisesti tuotannossa, mistä ei kannata olla ylpeä). Vinkkien oppiminen mainitusta artikkelista voisi auttaa monia ohjelmoijia parantamaan ratkaisevia refaktorointitaitojaan.

Artikkelin ykkösvinkki on "ymmärrä koodia", joka on aina ensimmäinen asia tarkistuslistallani ennen refaktorointia. Et voi luoda parempaa koodia, jos et tiedä, mitä nykyinen koodi tekee. Sotkuisen koodin ymmärtäminen voi olla työlästä, mutta se on hinta, joka sinun on maksettava koodipohjan parantamiseksi. Investoinnin tuotto on kuitenkin suuri, ja se maksaa itsensä takaisin.

Seuraava mainitsemisen arvoinen vinkki on "testaa aikaisin ja usein", jota voidaan soveltaa paitsi refaktoroinnin yhteydessä myös kehittäjien päivittäisessä työssä. Testauksen aihepiiri on valtava. Kyse ei ole vain testien kirjoittamisen syntaksin opettelusta, vaan on myös erotettava toisistaan testityypit. Jos haluat oppia lisää testauksesta, suosittelen tutustumaan testipyramidiin ja sen jälkeen tutustumaan klassisen ja lontoolaisen koulukunnan eroihin.

Yhteenvetona voidaan todeta, että artikkelissa keskitytään paikalliseen refaktorointiin, mikä on hyvä asia ja voi parantaa ohjelmoijien tyytyväisyyttä työhönsä. Jos kuitenkin haluat luoda ensiluokkaisen sovelluksen arkkitehtuurin tasolla, sinun on mentävä tämän artikkelin soveltamisalaa pidemmälle ja tutustuttava sovellusarkkitehtuuriin liittyviin kysymyksiin. Tämä voi auttaa sinua aloittamaan loputtoman matkan, ja sitä toivon kaikille teille, myös itselleni.

Michael McShinsky alkaen dev.to

Miten saavutetaan skaalautuvampi ja ylläpidettävämpi arkkitehtuuri?

Oikea tapa jäsentää sovelluksesi MVVM-arkkitehtuuriin perustuen?

Miten välttää ylimääräistä työtä sovelluksen kasvaessa?

Luultavasti jokainen on uransa aikana törmännyt tapaukseen, jossa huono arkkitehtuuri on pidentänyt merkittävästi tehtävän suorittamiseen tarvittavaa aikaa. Kansioiden sotkuisuus, tiedostojen tai luetteloiden nimien epäjohdonmukaisuus voivat sabotoida projekti heti alussa.

Artikkelin kirjoittaja osoittaa selvästi, mitä etuja on oikean lähestymistavan valitsemisesta projektin rakenteeseen. Alkaen create-react-app ja MVVM-arkkitehtuurin innoittamana hän esittelee sen ratkaisun edut erittäin tarkasti. Peruskonfiguroinnista lähtien hän käy läpi jokaisen kansion ja selittää tapauskohtaisesti, miksi hän pitää tätä lähestymistapaa sopivana. Lähestymistapa itsessään vaikuttaa melko monimutkaiselta ja luultavasti aluksi tarpeettomalta, kun projekti on alkuvaiheessa, mutta muistetaan, että asianmukaisten sääntöjen käyttöönotto alusta alkaen auttaa meitä välttämään aikaa vieviä uudelleenrakentamisia, kun projektia laajennetaan uusilla komponenteilla ja toiminnallisuuksilla. Oikein valitun projektirakenteen ansiosta projektin uudet jäsenet voivat myös hankkia helposti komponentteja ja palveluja. Älkäämme unohtako, että kaikki jäsentelytavat eivät sovi täydellisesti jokaiseen projektiin.
Omalta osaltani haluaisin lisätä perussäännön, jonka mukaan optimaalisen arkkitehtuurin valitseminen hanketta varten on hyödytöntä, jos kaikki miehistön jäsenet eivät noudata vahvistettuja sääntöjä.

Lue lisää: Miten parantaa Vue.js-sovelluksia? Joitakin käytännön vinkkejä

Guillaume Clement alkaen Dailymotion

Siirtyminen CTO:stä COO:ksi.

Työskentely täysin etäympäristössä. Miten pitää joukkue energinen ja osallistuva.

Luottamus tietoon vs. vaisto.

Modernin CTO-ohjelman 236 jaksossa Joel puhuu Dailymotionin toimitusjohtajan Guillaume Clementin kanssa. Dailymotionin tehtävänä on olla mielekäs ja ravitseva videosisältöalusta monien puhtaasti viihdepainotteisten ja "videopikaruokaa" tarjoavien alustojen joukossa. Jotta tämä saavutettaisiin liiketoiminnassa, jota ohjaavat vahvasti algoritmit ja datatieteellinen suunnittelu, on tehtävä vaikeita päätöksiä, jotka perustuvat vaistoon ja datan antamiin tietoihin.

Tyypillisesti tarkka mittari videoalustoille, medialle ja Adtech yritykset, sillä "käytetty aika" ei ole itsestään selvä KPI, jonka parissa kannattaa työskennellä, jos todella haluat tarjota käyttäjillesi mielekästä sisältöä, etkä vain pitää heidän huomiotaan ruudun edessä mahdollisimman pitkään. Viittaus Netflixin The Social Dilemma -dokumenttiin on väistämätön. Guillaume on myös hiljattain vaihtanut CTO:n tehtävästä COO:n rooliin yrityksessä, mikä tuo mukanaan uusia haasteita toimintaan ja ihmisten johtamiseen. Haaste on vielä vaativampi pandemian aikana, jolloin etäasennukset ovat johtajille koetinkivi tiimien pitämisessä mukana ja ajattelutavan pitämisessä korkealla tasolla. Sosiaalisempien tai introvertoituneempien työntekijöiden yksilöllisten tarpeiden huomioon ottaminen on avainasemassa, ja toimistokeskustelua on pidettävä rajoitetusti tarjolla niille, jotka tarvitsevat säännöllistä potkua päästäkseen vauhtiin.