TheCodestReview #2 - savaitinės programinės įrangos inžinerijos sultys

Mūsų nagrinėjamų aspektų žodynėlis:

1. Refaktorizavimo patarimai siekiant pagerinti kokybę.

2. Kodėl svarbi priekinės dalies architektūra ir kaip užtikrinti, kad ji būtų keičiamo dydžio ir prižiūrima?

3. Perėjimas nuo CTO į technologijų organizacijos COO pareigas.

Jei jus domina perėjimo nuo technologijų vadovo prie operacijų vadovo vaidmens tema, galite pasinerti į papildomus išteklius, nurodytus pranešimo apačioje.

Šią savaitę refaktorizavimo ir architektūros komentarus jums pateikia mūsų Ruby ir React inžinieriai.

Stephen Bigelow iš Search Software Quality

Pertvarkymas kodas visada buvo labai populiarus, tačiau ne visi žino, kaip tai daryti gerai ir kada tinkamas laikas tai daryti. Esu matęs daug bandymų atlikti refaktorių, kurie baigėsi nesėkme (ypač gamybinėje versijoje, o tai nėra dalykas, kuriuo reikėtų didžiuotis). Minėtame straipsnyje pateiktų patarimų mokymasis galėtų padėti daugeliui programuotojų patobulinti svarbiausius refaktorizavimo įgūdžius.

Straipsnyje pateikiamas patarimas numeris vienas - “suprasti kodą”, kuris visada yra pirmasis dalykas mano kontroliniame sąraše, kurį turiu atlikti prieš refaktorizavimą. Nesukursite geresnio kodo, jei nežinosite, ką daro dabartinis kodas. Suprasti netvarkingą kodą gali tekti nemažai pastangų, tačiau tai yra kaina, kurią turite sumokėti, kad pagerintumėte savo kodo bazę. Vis dėlto šios investicijos grąža yra didelė ir ji atsipirks.

Kitas vertas paminėti patarimas - “testuoti anksti ir dažnai”, kuris gali būti taikomas ne tik refaktorizavimo kontekste, bet ir kasdieniame kūrėjų darbe. Testavimo tema yra labai plati. Reikia ne tik išmokti sintaksę, kaip rašyti testus, bet ir atskirti testų tipus. Norint daugiau sužinoti apie testavimą, rekomenduoju susipažinti su testų piramide, o tada sužinoti apie skirtumus tarp klasikinių ir Londonas mokyklos.

Apibendrinant galima teigti, kad straipsnyje daugiausia dėmesio skiriama vietiniam refaktorizavimui, kuris yra geras ir gali padidinti programuotojų pasitenkinimą savo darbu. Tačiau norėdami sukurti aukščiausios kokybės programą architektūros lygmeniu, turite peržengti šio straipsnio ribas ir sužinoti apie su programos architektūra susijusius klausimus. Tai gali padėti jums pradėti išeiti iš nesibaigiančios kelionės ir to linkiu visiems jums, įskaitant ir save.

Michael McShinsky iš dev.to

Kaip sukurti lengviau keičiamo dydžio ir prižiūrimą architektūrą?

Tinkamas būdas struktūrizuoti programėlę pagal MVVM architektūrą?

Kaip išvengti papildomo darbo augant programėlei?

Tikriausiai kiekvienas per savo karjerą yra susidūręs su atveju, kai bloga architektūra gerokai pailgino užduočiai atlikti reikalingą laiką. Netvarka aplankuose, failų ar katalogų pavadinimų nenuoseklumas gali sabotuoti projektas pačioje pradžioje.

Straipsnio autorius aiškiai parodo, kokius privalumus suteikia tinkamas požiūris į projekto struktūrą. Pradedant nuo sukurti-react-app ir įkvėptas MVVM architektūros, jis labai tiksliai parodo savo sprendimo privalumus. Pradėdamas nuo pagrindinės konfigūracijos, jis apžvelgia kiekvieną aplanką, kiekvienu konkrečiu atveju paaiškindamas, kodėl, jo nuomone, šis metodas yra tinkamas. Pats požiūris atrodo gana sudėtingas ir iš pradžių, kai projektas yra pradiniame etape, tikriausiai nereikalingas, tačiau nepamirškime, kad tinkamų taisyklių įvedimas nuo pat pradžių padės mus išvengti daug laiko reikalaujančių pertvarkymų plečiant projektą naujais komponentais ir funkcijomis. Tinkamai parinkta projekto struktūra taip pat leis naujiems projekto nariams lengvai įsigyti komponentų ir paslaugų. Nepamirškime, kad ne kiekvienas struktūrizavimo būdas puikiai tiks kiekvienam projektui.
Iš savo pusės norėčiau pridurti pagrindinę taisyklę, kad optimalios architektūros parinkimas projektui bus nenaudingas, jei kiekvienas komandos narys nesilaikys nustatytų taisyklių.

Skaityti daugiau: Kaip patobulinti Vue.js programas? Keletas praktinių patarimų

Guillaume Clement iš Dailymotion

Perėjimas nuo CTO prie COO.

Darbas visiškai nuotolinėje aplinkoje. Kaip išlaikyti komanda energingas ir įsitraukęs.

Pasitikėjimas duomenys vs nuojauta.

Modernaus CTO 236 epizode Joelis kalbasi su “Dailymotion” operatyviniu direktoriumi Guillaume'u Clementu. "Dailymotion" misija - būti prasminga ir maistinga vaizdo įrašų turinio platforma tarp daugybės platformų, kurios yra orientuotos tik į pramogas ir tarnauja "greitam vaizdo įrašų maistui". Norint to pasiekti versle, kurį stipriai lemia algoritmai ir duomenų mokslo inžinerija, reikia priimti sudėtingus sprendimus, pagrįstus nuojauta, palyginti su tuo, ką sako duomenys.

Paprastai tiksli vaizdo įrašų platformų, žiniasklaidos ir Adtech verslas, nes “praleistas laikas” nėra akivaizdus KPI, kurį reikėtų vertinti, jei iš tiesų siekiate pateikti naudotojams prasmingą turinį, o ne tik kuo ilgiau išlaikyti jų dėmesį prie ekrano. Nuoroda į “Netflix” dokumentinį filmą "Socialinė dilema" yra neišvengiama. Be to, Guillaume'as neseniai perėjo iš CTO į įmonės COO pareigas, o tai kelia naujų iššūkių operacijų ir žmonių valdymo srityje. Iššūkis dar sudėtingesnis pandemijos metu, kai nuotolinė sąranga yra išbandymas vadovams, kaip išlaikyti team dalyvavimą ir aukšto lygio mąstyseną. Labai svarbu atsižvelgti į individualius darbuotojų, kurie yra labiau socialūs arba labiau intravertiški, poreikius, imantis riboto kiekio biuro bendravimo, prieinamo tiems, kuriems reikia reguliaraus kibimo, kad galėtų įsibėgėti.