Visual Studio Code per lo sviluppo in team

di Morgan Pizzini, in Visual Studio Code,

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.

disable-extension

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.

4 pagine in totale: 1 2 3 4
Contenuti dell'articolo

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti

Top Ten Articoli

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

Misc