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 toimittaa teille meidän Ruby and React insinöörit.

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 and inspired by the MVVM architecture, he shows the advantages of its solution very accurately. Going from basic configuration, he goes through each folder while explaining on a case-by-case basis why he considers this approach appropriate. The approach itself seems quite complicated and probably unnecessary at first when the project is at the early stage but let’s remember that introducing the appropriate rules from the start will help us avoid time-consuming re-structures while expanding the project with new components and functionalities. A properly selected project structure will also allow new members of the project to easily acquire components and services.  Let’s not forget that not every way to structurize will perfectly fit in every project.
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.