Visual Studio Code per lo sviluppo in team
Lo sviluppo di applicazioni moderne trova la sua massima espressione nella creazione di microservizi, se inseriti all'interno di container ed orchestrati da un agente predisposto possiamo ottenere incredibili vantaggi. Il pregio principale di questa architettura è la totale indipendenza tra i framework utilizzati dai servizi stessi: all'interno di un cluster possiamo trovare container che eseguono applicazione create con .NET Core, Node.js, PHP ecc.. Ognuno di essi, per poter essere sviluppato, richiede un preciso setup degli strumenti di lavoro e tale configurazione dovrà garantire il rispetto di una serie di regole sintattiche e semantiche specifiche per il linguaggio di sviluppo utilizzato. Con l'utilizzo di Visual Studio Code abbiamo a disposizione una vasta collezione di plugin con cui possiamo adattare l'IDE alle nostre esigenze. Queste estensioni facilitano lo sviluppo attraverso regole di formattazione, con context aware intellisense, shortcuts e settings. Come è però prevedibile, "il troppo stroppa", infatti se siamo dei front-end developer, lavoriamo con Angular, Vue e React, ed abbiamo intallato tutti i plugin raccomandati per lo sviluppo. Andando a scrivere in un file .ts, l'intellisense ci proporrà soluzioni provenienti da tutti i plugin installati e ciò non solo creerà gran confusione a noi, ma anche le prestazioni di Visual Studio Code ne risentiranno, dato che dovrà eseguire static analysis, sui files del progetto, per frameworks potenzialmente non utilizzati.
In questo contesto si sente la mancanza di uno strumento, o di una funzionalità, che permetta di sviluppare all'interno di un ambiente predisposto per la scelta tecnologica effettuata: se stiamo sviluppando diversi microservizi per altrettanti, o più, containers, non sarebbe errato pensare di utilizzare la stessa tecnologia per poter porre all'interno di uno di essi le nostre preferenze, configurazioni per condividerle, aggiornarle e renderle disponibili in qualunque occasione all'interno del team di lavoro.
La situazione attuale
Portiamo in esame una casistica molto comune all'interno di un'azienda che segue diversi progetti, ognuno dei quali impone le sue regole: ognuno dei progetti potrebbe avere bisogno di regole di formattazione diverse. Esistono, all'interno del Visual Studio Marketplace diverse estensioni che ci permettono di pre-impostare l'ambiente seguendo determinate regole. La configurazione per ogni estensione è persistita all'interno del file settings.json, questo può essere locale rispetto al progetto o globale per istanza di Visual Studio Code. Se siamo nel secondo caso, abbiamo l'obbligo di ricordarci di modificare le impostazioni al cambio del progetto, per riadattarle al nuovo ambiente di lavoro, con il rischio, in caso di dimenticanza, di modificare la tipologia di formattazione dei files.
Possiamo citare innumerevoli altri esempi che ci porteranno ad un'unica conclusione: voler configurare un'utenza di sistema diversa per ogni ambiente, in modo da poter installare più istanze di Visual Studio Code. Può sembrare una scelta estrema, ma è l'unica che garantisca di lavorare utilizzando le configurazioni corrette per ogni tipo progetto.
Attivazione e disattivazione estensioni
Cerchiamo ora di trasformare la teoria in pratica, creare più utenze è ovviamente impossibile in un contesto reale di lavoro, proviamo quindi a trovare una soluzione più sostenibile e che ci consenta di sviluppare fluidamente.
Dagli ultimi rilasci di Visual Studio Code l'installazione, attivazione e disattivazione di plugin è migliorata notevolmente, al punto tale che non è più necessario, nel più dei casi, di riavviare l'istanza. Partendo da una nuova installazione di Visual Studio Code procediamo installando tutte le estensioni necessarie al nostro lavoro. Aprendo poi una folder di lavoro, disabilitiamo i plugin non richiesti per un determinato workspace.
Questo settings sfortunatamente, al momento, non è accessibile all'utente, non si può dunque visualizzare la lista delle estensioni disabilitate, ma sono già diverse le richieste per rendere l'elenco dei plugin disabilitati un attributo del file settings.json all'interno della cartella .vscode, in modo tale che la configurazione possa essere posta sotto source control e condivisa tra gli utilizzatori del repository.
Contenuti dell'articolo
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Eseguire un metodo asincrono dopo il set di una proprietà in Blazor 8
Usare una container image come runner di GitHub Actions
Esporre i propri servizi applicativi con Semantic Kernel e ASP.NET Web API
Gestione dei nomi con le regole @layer in CSS
Utilizzare EF.Constant per evitare la parametrizzazione di query SQL
Creazione di plugin per Tailwind CSS: espandere le Funzionalità del Framework
Miglioramenti agli screen reader e al contrasto in Angular
Ordine e importanza per @layer in CSS
Usare il colore CSS per migliorare lo stile della pagina
Utilizzare Azure Cosmos DB con i vettori
Gestire domini wildcard in Azure Container Apps
Utilizzare i primary constructor di C# per inizializzare le proprietà
Top Ten Articoli
- Realizzare una Progressive Web Application con Blazor e ASP.NET Core
di Giampaolo Tucci - Gestire le chiamate a servizi esterni in ASP.NET Core e Blazor tramite Polly
di Morgan Pizzini - Usare gRPC come infrastruttura per i nostri servizi web
di Morgan Pizzini - Abilitare e gestire il prerendering nelle applicazioni Blazor WebAssembly
di Marco De Sanctis - Creare API GraphQL con ASP.NET Core e HotChocolate
di Moreno Gentili - Le novità di Blazor in .NET 6.0
di Morgan Pizzini - Blazor e il pattern Model-View-ViewModel
di Giampaolo Tucci - Le novità in ASP.NET Core e Blazor con .NET 7
di Morgan Pizzini - Introduzione a Blazor WebAssembly
di Marco De Sanctis, Moreno Gentili - Le novità di ASP.NET Core 5
di Marco De Sanctis
Articoli via e-mail
Iscriviti alla nostra newsletter nuoviarticoli per ricevere via e-mail le notifiche!
In primo piano
I più letti di oggi
In evidenza
- Eseguire script pre e post esecuzione di un workflow di GitHub
- Creare una libreria CSS universale: Cards
- Migliorare l'organizzazione delle risorse con Azure Policy
- Effettuare il log delle chiamate a function di GPT in ASP.NET Web API
- Leggere la posta usando il protocollo IMAP tramite la libreria MailKit
- Eseguire una ricerca avanzata per recuperare le issue di GitHub
- Creare una libreria CSS universale: Clip-path
- Sfruttare gli embedding e la ricerca vettoriale con Azure SQL Database