TheCodestReview #2 - succo settimanale di ingegneria del software

Glossario degli aspetti che stiamo affrontando:

1. Suggerimenti per il refactoring ai fini di un miglioramento della qualità.

2. Perché l'architettura del frontend è importante e come renderla scalabile e manutenibile?

3. Transizione da CTO al ruolo di COO in un'organizzazione tecnologica.

Se siete interessati all'argomento del passaggio da un ruolo di leader tecnologico a un ruolo operativo, potete approfondire le risorse aggiuntive collegate in fondo al post.

I commenti sul refactoring e sull'architettura di questa settimana sono forniti dai nostri ingegneri Ruby e React.

Stephen Bigelow di Search Software Quality

Rifattorizzazione codice è sempre stato molto popolare, ma non tutti sanno come farlo bene e quando è il momento giusto per farlo. Ho visto molti tentativi di refactoring che si sono conclusi con un fallimento (soprattutto in produzione, il che non è una cosa di cui andare fieri). Imparare i suggerimenti dell'articolo citato potrebbe aiutare molti programmatori a migliorare le proprie capacità di refactoring.

Il consiglio numero uno dell'articolo è "capire il codice", che è sempre la prima cosa da fare nella mia lista di controllo prima di rifattorizzare. Non si può creare codice migliore se non si sa cosa fa il codice attuale. Comprendere il codice disordinato può essere faticoso, ma è il prezzo da pagare per migliorare la vostra base di codice. Tuttavia, il ROI di questo investimento è elevato e sarà ripagato.

Il prossimo consiglio che vale la pena di menzionare è quello di "testare presto e spesso", che potrebbe essere applicato non solo nel contesto del refactoring, ma anche nel lavoro quotidiano degli sviluppatori. L'argomento dei test è enorme. Non si tratta solo di imparare la sintassi per scrivere i test, ma anche di distinguere i tipi di test. Per saperne di più sui test, vi consiglio di familiarizzare con la piramide dei test e di conoscere le differenze tra la scuola classica e quella londinese.

Riassumendo, l'articolo si concentra sul refactoring locale, il che è positivo e potrebbe migliorare la soddisfazione dei programmatori per il loro lavoro. Tuttavia, per creare un'applicazione di prim'ordine a livello di architettura, è necessario andare oltre lo scopo di questo articolo e approfondire le questioni relative all'architettura delle applicazioni. Questo potrebbe aiutarvi a iniziare un viaggio senza fine ed è quello che auguro a tutti voi, me compreso.

Michael McShinsky da dev.to

Come ottenere un'architettura più scalabile e manutenibile?

Il modo corretto di strutturare l'applicazione in base all'architettura MVVM?

Come evitare il lavoro extra quando la vostra applicazione cresce?

Probabilmente tutti nella loro carriera si sono imbattuti in un caso in cui una cattiva architettura ha allungato in modo significativo il tempo necessario per completare un compito. Il disordine nelle cartelle, l'incoerenza nella denominazione dei file o dei cataloghi possono sabotare la progetto all'inizio.

L'autore dell'articolo mostra chiaramente i vantaggi della scelta del giusto approccio alla struttura del progetto. Partendo dal creare-react-app e ispirato all'architettura MVVM, mostra i vantaggi della sua soluzione in modo molto accurato. Partendo dalla configurazione di base, passa in rassegna ogni cartella spiegando caso per caso perché ritiene opportuno questo approccio. L'approccio in sé sembra piuttosto complicato e probabilmente inutile all'inizio, quando il progetto è in fase iniziale, ma ricordiamo che introdurre le regole appropriate fin dall'inizio ci aiuterà a evitare lunghe ristrutturazioni durante l'espansione del progetto con nuovi componenti e funzionalità. Una struttura di progetto scelta correttamente consentirà anche ai nuovi membri del progetto di acquisire facilmente componenti e servizi. Non dimentichiamo che non tutti i metodi di strutturazione si adattano perfettamente a ogni progetto.
Da parte mia, vorrei aggiungere la regola di base che la scelta dell'architettura ottimale per il progetto sarà inutile se non tutti i membri dell'equipaggio seguono le regole stabilite.

Per saperne di più: Come migliorare le applicazioni Vue.js? Alcuni consigli pratici

Guillaume Clement da Dailymotion

Passaggio da CTO a COO.

Lavorare in un ambiente completamente remoto. Come mantenere il squadra energia e coinvolgimento.

Fiducia nei dati e nelle sensazioni di pancia.

Nell'episodio 236 di Modern CTO, Joel parla con il COO di Dailymotion Guillaume Clement. La missione di Dailymotion è quella di essere una piattaforma di contenuti video significativa e nutriente in mezzo a una serie di piattaforme che sono puramente orientate all'intrattenimento e servono come "fast food video". Per raggiungere questo obiettivo, in un'attività fortemente guidata dagli algoritmi e dalla scienza dei dati, è necessario prendere decisioni difficili basate su sensazioni istintive rispetto a ciò che dicono i dati.

La metrica tipicamente accurata per piattaforme video, media e Adtech Le attività commerciali, come il "tempo trascorso", non sono il KPI più ovvio su cui lavorare se si cerca veramente di offrire agli utenti contenuti significativi, e non solo di mantenere la loro attenzione davanti allo schermo il più a lungo possibile. Il riferimento al documentario "The Social Dilemma" su Netflix è inevitabile. Guillaume è anche passato di recente dal ruolo di CTO a quello di COO dell'azienda, il che comporta nuove sfide a livello operativo e di gestione delle persone. La sfida è ancora più impegnativa durante la pandemia, quando l'organizzazione a distanza mette alla prova i leader nel mantenere il coinvolgimento dei team e la mentalità ad alto livello. È fondamentale rispondere alle esigenze individuali dei dipendenti più socievoli o più introversi, mettendo a disposizione di coloro che hanno bisogno di una spinta regolare per andare avanti, una quantità limitata di mondanità in ufficio.