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 sulla rifattorizzazione e sull'architettura di questa settimana sono forniti dal nostro Rubino and React ingegneri.

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 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.
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.