Cos’\u00c8 la Procedura di Revisione del Codice?<\/h2>\n
L’obiettivo primario della procedura di revisione del codice \u00e8 quello di valutare qualsiasi nuovo codice per cercare bug, errori e verificare il rispetto degli standard di qualit\u00e0 stabiliti dall’organizzazione. La procedura di revisione del codice non dovrebbe consistere solo in un feedback unilaterale. Pertanto, un beneficio intangibile della procedura di revisione del codice \u00e8 il miglioramento delle capacit\u00e0 di codifica di tutto il team.<\/p>\n
Se desiderate avviare una procedura di revisione del codice all’interno della vostra organizzazione, dovreste prima decidere chi deve rivedere il codice<\/a>. Se fate parte di un piccolo team, potete assegnare ai lead del team la revisione di tutto il codice. In un team pi\u00f9 grande con pi\u00f9 revisori, potreste attivare una procedura in cui ogni revisione del codice viene assegnata a uno sviluppatore esperto in base al suo carico di lavoro.<\/p>\n La prossima considerazione per voi \u00e8 quella di decidere le tempistiche, i turni e i requisiti minimi per la presentazione delle richieste di revisione del codice.<\/p>\n La considerazione finale riguarda il modo in cui il feedback dovrebbe essere dato nella procedura di revisione del codice. Assicuratevi di evidenziare gli aspetti positivi del codice, suggerendo al tempo stesso delle alternative per gli svantaggi.<\/p>\n Il vostro feedback<\/a> dovrebbe essere costruttivo in modo da incoraggiare lo sviluppatore a comprendere il vostro punto di vista e ad avviare una conversazione quando necessario.<\/p>\n \u00c8 facile che le revisioni del codice rimangano bloccate in un limbo, il che porta ad essere meno efficienti e persino controproducenti.<\/p>\n\n La procedura di revisione del codice \u00e8 fondamentale perch\u00e9 non fa mai parte del programma di studi nelle scuole. Potete imparare le sfumature di un linguaggio di programmazione<\/a> e di project management<\/a>, ma la revisione del codice \u00e8 una procedura che si evolve con l’et\u00e0 dell’organizzazione.<\/p>\n La revisione del codice \u00e8 fondamentale per i seguenti motivi:<\/p>\n Le revisioni del codice portano a migliorare ulteriormente le competenze degli altri membri del team. Poich\u00e9 uno sviluppatore senior<\/a> di solito si occupa della revisione del codice, uno sviluppatore junior pu\u00f2 utilizzare questo feedback per migliorare le sue capacit\u00e0 di codifica.<\/p>\n Ci sono quattro modi per condurre le revisioni del codice.<\/p>\n Le revisioni del codice vengono effettuate sulla postazione di lavoro dello sviluppatore, dove un membro del team esperto scorre il nuovo codice, fornendo suggerimenti durante la conversazione. \u00c8 l’approccio pi\u00f9 semplice alle revisioni del codice e non richiede una struttura predefinita.<\/p>\n Tale revisione del codice pu\u00f2 essere effettuata ancora oggi in modo informale, insieme ad un’eventuale procedura formale di revisione del codice gi\u00e0 in atto. Le revisioni del codice over-the-shoulder sono tradizionalmente effettuate di persona, mentre i team distribuiti<\/a> possono seguire questo metodo anche attraverso strumenti collaborativi<\/a>.<\/p>\n Mentre le revisioni del codice over-the-shoulder sono un ottimo modo per rivedere il nuovo codice, i team geograficamente distribuiti si sono tradizionalmente affidati alle email per le revisioni del codice.<\/p>\n In questa procedura di revisione del codice, uno sviluppatore invia un\u2019email con le modifiche all’intero team di sviluppo, di solito attraverso sistemi di controllo delle versioni<\/a> che automatizzano le notifiche. Questa email avvia una conversazione sulle modifiche, dove i membri del team possono richiedere ulteriori modifiche, segnalare errori o chiedere chiarimenti.<\/p>\n All’inizio, la posta elettronica era il principale mezzo di comunicazione grazie alla sua versatilit\u00e0<\/a>. Le organizzazioni open source spesso mantenevano una mailing list pubblica, che serviva anche come mezzo per discutere e fornire feedback sul codice.<\/p>\n Con l’avvento degli strumenti di revisione del codice, queste mailing list esistono ancora, ma soprattutto per gli annunci e le discussioni successive.<\/p>\n La programmazione in coppia \u00e8 una procedura di revisione continua del codice. Due sviluppatori siedono su una postazione di lavoro, ma solo uno di loro codifica attivamente,<\/a> mentre l’altro fornisce un feedback in tempo reale.<\/p>\n Anche se pu\u00f2 servire come un ottimo strumento per ispezionare il nuovo codice e formare gli sviluppatori, potrebbe rivelarsi potenzialmente inefficiente a causa della sua natura, che richiede tempo. Questa procedura blocca il revisore dal fare qualsiasi altro lavoro produttivo durante la revisione.<\/p>\n Una procedura di revisione del codice assistito da uno strumento comporta l’uso di uno strumento specializzato per facilitare la procedura di revisione del codice. Uno strumento generalmente aiuta a svolgere i seguenti compiti:<\/p>\n Mentre questi sono i requisiti generali di uno strumento di revisione del codice, gli strumenti moderni possono fornire una manciata di altre funzioni. Esploreremo una serie di strumenti di revisione del codice pi\u00f9 avanti in questo articolo.<\/p>\n Il risultato principale di una procedura di revisione del codice \u00e8 l’aumento dell’efficienza. Mentre questi metodi tradizionali hanno funzionato in passato, potreste perdere efficienza se non passate a uno strumento di revisione del codice<\/strong>. Uno strumento di revisione del codice automatizza la procedura di revisione in modo che il revisore si concentri esclusivamente sul codice.<\/p>\n Uno strumento di revisione del codice si integra con il vostro ciclo di sviluppo per avviare la revisione prima che il nuovo codice venga fuso nella base principale. Potete scegliere uno strumento compatibile con il vostro stack tecnologico per integrarlo perfettamente nel vostro flusso di lavoro.<\/p>\n Per esempio, se utilizzate Git per la gestione del codice<\/a>, TravisCI per l’integrazione continua, assicuratevi di selezionare uno strumento che supporti queste tecnologie per poterle inserire nel processo di sviluppo.<\/p>\n Ci sono due tipi di test del codice nello sviluppo del software: dinamico e statico.<\/p>\n L’analisi dinamica consiste nel verificare se il codice segue un insieme di regole e nell’eseguire test unitari, tipicamente eseguiti da uno script predefinito. Il test statico del codice viene fatto dopo che uno sviluppatore crea un nuovo codice da fondere nel codice corrente.<\/p>\n Ora tuffiamoci in alcuni dei pi\u00f9 popolari strumenti di revisione del codice!<\/p>\n In questa sezione, passiamo in rassegna i pi\u00f9 popolari strumenti di revisione del codice statico.<\/p>\n Review Board<\/a> \u00e8 uno strumento open source basato sul web. Per testare questo strumento di revisione del codice, potete dare un\u2019occhiata alla demo<\/a> sul loro sito web o scaricare<\/a> e impostare<\/a> il software sul vostro server.<\/p>\n I prerequisiti per eseguire Review Board su un server sono il linguaggio di programmazione Python e i suoi strumenti di installazione, MySQL<\/a> o PostgreSQL<\/a> come database, e un server web. Review Board vi consente di eseguire sia le revisioni del codice pre-commit che quelle post-commit, a seconda delle esigenze. Se non avete integrato un sistema di controllo di versione<\/a>, potete usare un file diff per caricare le modifiche del codice nello strumento per una revisione.<\/p>\n Viene inoltre fornito un confronto grafico delle modifiche apportate al vostro codice. Oltre alla revisione del codice, la commissione di revisione consente di effettuare anche la revisione dei documenti.<\/p>\n La prima versione di Review Board \u00e8 uscita pi\u00f9 di dieci anni fa, ma \u00e8 ancora in fase di sviluppo. Pertanto, la comunit\u00e0 di Review Board \u00e8 cresciuta nel corso degli anni e probabilmente troverete supporto in caso di problemi con l’utilizzo di questo strumento.<\/p>\n Review Board \u00e8 un semplice strumento per la revisione del codice, che potete ospitare sul vostro server. Dovreste provarlo se non volete ospitare il vostro codice su un sito web pubblico.<\/p>\n Crucible<\/a> \u00e8 uno strumento collaborativo di revisione del codice di Atlassian. \u00c8 una suite commerciale di strumenti che permette di rivedere il codice, discutere le modifiche ai piani e identificare i bug attraverso una serie di sistemi di controllo di versione.<\/p>\n Crucible prevede due piani di pagamento, uno per i piccoli team e l’altro per le imprese. Per un piccolo team, \u00e8 necessario effettuare un pagamento una tantum di $10 per repository illimitati, utilizzabili per\u00f2 da un massimo di cinque utenti. Per i grandi team, le tariffe partono da $1100 per dieci utenti e repository illimitati.<\/p>\n Entrambi questi piani offrono una prova gratuita di 30 giorni senza bisogno di una carta di credito.<\/p>\n Simile a Review Board, Crucible supporta un gran numero di sistemi di controllo di versione – SVN, Git, Mercurial, CVS e Perforce. La sua funzione primaria \u00e8 quella di consentire di eseguire revisioni del codice. Oltre ai commenti generali sul codice, consente di commentare in linea all’interno della vista diff per individuare esattamente ci\u00f2 a cui ci si riferisce nello specifico.<\/p>\n Crucible si integra bene con gli altri prodotti aziendali di Atlassian come Confluence e Enterprise BitBucket<\/a>. Tuttavia, \u00e8 possibile ottenere il massimo dei vantaggi da Crucible utilizzandolo insieme a Jira<\/a>, Atlassian\u2019s Issue e Project Tracker. Permette di eseguire revisioni e audit pre-commit sul codice combinato.<\/p>\n Se usate GitHub<\/a> per mantenere i vostri repository Git sul cloud, potreste aver gi\u00e0 usato i fork e le richieste pull per rivedere il codice. Nel caso non abbiate idea di cosa sia GitHub, ecco una guida per principianti su GitHub<\/a> e sulle differenze tra Git e GitHub<\/a>.<\/p>\n GitHub include uno strumento di revisione del codice<\/a> integrato nelle sue richieste pull. Lo strumento di revisione del codice \u00e8 fornito in bundle con il servizio principale di GitHub, che fornisce un piano gratuito<\/a> per gli sviluppatori. Il piano gratuito di GitHub limita il numero di utenti a tre nei repository privati. I piani a pagamento partono da $7 al mese.<\/p>\n GitHub permette ad un revisore con accesso al repository del codice di assegnarsi alla richiesta pull e completare una revisione. Uno sviluppatore che ha presentato la richiesta di pull pu\u00f2 anche richiedere una revisione ad un amministratore.<\/p>\n Oltre alla discussione sulla richiesta di pull, \u00e8 possibile analizzare il diff, fare commenti inline e controllare la cronologia delle modifiche. Lo strumento di revisione del codice permette anche di risolvere semplici conflitti Git attraverso l’interfaccia web. GitHub si integra anche con altri strumenti di revisione<\/a> attraverso il suo marketplace per creare una procedura pi\u00f9 robusto.<\/p>\n Il tool di revisione del codice di GitHub \u00e8 un ottimo strumento se siete gi\u00e0 registrati nella piattaforma. Non richiede alcuna installazione o configurazione aggiuntiva. Il problema principale dello strumento di revisione del codice di GitHub \u00e8 che supporta solo i repository Git ospitati su GitHub. Se state cercando uno strumento di revisione del codice simile che potete scaricare e ospitare sul vostro server, potete provare GitLab<\/a>.<\/p>\n Axolo<\/a> non \u00e8 quello che vi aspettate quando leggete “strumento di revisione del codice”. Probabilmente vi state immaginando una schermata piena di diff. Non \u00e8 affatto cos\u00ec! Axolo \u00e8 tutto incentrato sulla comunicazione. In particolare, Axolo prende tutte le consuete discussioni su GitHub o GitLab<\/a> e le trasferisce su Slack.<\/p>\n Lo fanno creando un canale Slack effimero per ogni revisione del codice, invitando solo le persone che dovrebbero essere presenti (autori del codice, gli assegnatari e i revisori), inviando solo le notifiche necessarie nel canale (commenti sul codice, CI\/CD, …) e archiviando il canale una volta che la branch \u00e8 stata unita.<\/p>\n Grazie ai promemoria giornalieri, alle notifiche di riepilogo delle richieste di pull per gli stand-up e alle fasce orarie dedicate alla revisione del codice, i team di ingegneri possono rivedere il codice senza problemi, senza che le richieste di pull rimangano lettera morta.<\/p>\n Collaborator<\/a> by SmartBear \u00e8 uno strumento peer code e di revisione dei documenti per i team di sviluppo. Oltre alla revisione del codice sorgente, Collaborator consente ai team di rivedere anche i documenti di progettazione. Un pacchetto di licenze per 5 utenti ha un prezzo di $535 all’anno. Una prova gratuita \u00e8 disponibile a seconda delle vostre esigenze aziendali.<\/p>\n Collaborator supporta un gran numero di sistemi di controllo di versione come Subversion, Git<\/a>, CVS, Mercurial, Perforce e TFS. Fa un buon lavoro di integrazione con i popolari strumenti di gestione dei progetti e IDE come Jira, Eclipse e Visual Studio.<\/p>\n Questo strumento consente anche la reportistica e l’analisi delle metriche chiave relative alla vostra procedura di revisione del codice. Inoltre, Collaborator aiuta anche nella gestione degli audit e nel tracciamento dei bug. Se il vostro stack tecnologico include il software aziendale e avete bisogno di supporto per impostare la vostra procedura di revisione del codice, dovreste provare Collaborator.<\/p>\n CodeScene<\/a> \u00e8 uno strumento di revisione del codice che va oltre la tradizionale analisi statica del codice. Esegue l’analisi del codice comportamentale includendo una dimensione temporale per analizzare l’evoluzione della vostra codebase. CodeScene \u00e8 disponibile in due forme: una soluzione cloud-based e una soluzione on-premise<\/a>.<\/p>\n I piani basati sul cloud di CodeScene sono gratuiti per i repository pubblici ospitati su GitHub<\/a>. Per un massimo di dieci repository privati e un team di dieci membri, CodeScene costa \u20ac99 (circa $115) al mese. Un’installazione on-premise di CodeScene costa \u20ac15 (circa $17) per sviluppatore al mese.<\/p>\n CodeScene elabora la cronologia del vostro controllo di versione e la traspone in grafiche. Oltre a questo, applica algoritmi di machine learning per identificare modelli sociali e rischi nascosti nel codice.<\/p>\n Attraverso la cronologia del controllo di versione, CodeScene traccia i profili di ogni membro del team per mappare la sua knowledge base e creare dipendenze tra i team. Inoltre, introduce il concetto di hotspot nel vostro repository identificando i file che subiscono la maggior parte delle attivit\u00e0 di sviluppo. Vi indica cos\u00ec gli hotspot che richiedono la massima attenzione in futuro.<\/p>\n Se state cercando uno strumento che vada oltre un tradizionale strumento di revisione del codice, non perdete la prova gratuita di CodeScene. Per saperne di pi\u00f9 sulla logica alla base dell’analisi del codice comportamentale di CodeScene, date un’occhiata a questo white paper sui casi d’uso e i ruoli di CodeScene<\/a>.<\/p>\n Visual Expert<\/a> \u00e8 una soluzione aziendale per la revisione del codice specializzata in codice di database<\/a>. Offre il supporto per tre sole piattaforme: PowerBuilder, SQL Server<\/a> e Oracle PL\/SQL<\/a>. Se utilizzate un qualsiasi altro DBMS, non sar\u00e0 possibile integrare Visual Expert per la revisione del codice.<\/p>\n \u00c8 disponibile una prova gratuita, ma dovrete inviare una richiesta per ottenere un preventivo di prezzo.<\/p>\n Oltre alla tradizionale revisione del codice, Visual Expert analizza ogni modifica realizzata nel codice per cercare eventuali problemi di performance dovuti alle modifiche. Lo strumento \u00e8 anche in grado di generare automaticamente una documentazione completa della vostra applicazione partendo dal codice.<\/p>\n Se utilizzate PowerBuilder, SQL Server o Oracle PL\/SQL e desiderate uno strumento di revisione del codice specializzato per le vostre esigenze, dovreste provare Visual Expert (ecco una guida alla costruzione di query WordPress efficienti<\/a>).<\/p>\n Gerrit<\/a> \u00e8 uno strumento gratuito e open source di revisione del codice basato sul web per i repository Git<\/a>, scritto in Java. Per usare Gerrit, dovete scaricare il codice sorgente ed eseguirlo in Java. Ecco la procedura di installazione per una versione standalone di Gerrit<\/a>.<\/p>\n Gerrit combina le funzionalit\u00e0 di un bug tracker e quelle di uno strumento di revisione. Durante una revisione, le modifiche vengono visualizzate fianco a fianco in un diff unificato, con la possibilit\u00e0 di avviare una conversazione per ogni riga di codice aggiunta. Questo strumento funziona come un passo intermedio tra uno sviluppatore<\/a> e il repository centrale. Inoltre, Gerrit incorpora anche un sistema di votazione<\/a>.<\/p>\n Se possedete la competenza tecnica per installare e configurare Gerrit, e siete alla ricerca di uno strumento gratuito per la revisione del codice, questo dovrebbe servire come soluzione ideale per i vostri progetti.<\/p>\n Rhodecode<\/a> \u00e8 uno strumento basato sul web che vi assiste nell’esecuzione di revisioni del codice. Supporta tre sistemi di controllo di versione: Mercurial, Git e Subversion. Una versione di Rhodecode basata su cloud parte da $8 al mese per utente, mentre una soluzione on-premise costa $75 all’anno per utente. Oltre alla versione software aziendale, \u00e8 disponibile l\u2019edizione community<\/a> che \u00e8 gratuita e open source: potete scaricarla e compilarla gratuitamente.<\/p>\n Rhodecode consente a un team di collaborare efficacemente attraverso la revisione iterativa e conversazionale del codice per migliorarne la qualit\u00e0. Questo strumento fornisce inoltre un livello di gestione dei permessi per uno rendere pi\u00f9 sicuro lo sviluppo<\/a>.<\/p>\n Inoltre, un changelog visivo vi aiuta a navigare la storia del vostro progetto attraverso varie ramificazioni. Un editor di codice online<\/a> \u00e8 disponibile anche per piccole modifiche attraverso l’interfaccia web.<\/p>\n Rhodecode si integra perfettamente con i vostri progetti esistenti, il che lo rende un’ottima scelta per chi cerca uno strumento di revisione del codice basato sul web. Pertanto, l’edizione community \u00e8 l’ideale per chi ha esperienza tecnica e cerca uno strumento di revisione del codice gratuito e affidabile.<\/p>\n Veracode<\/a> fornisce una suite di strumenti di revisione del codice che consentono di automatizzare i test, accelerare lo sviluppo, integrare una procedura di bonifica e migliorare l’efficienza del progetto. La suite di strumenti di revisione del codice di Veracode \u00e8 commercializzata come soluzione di sicurezza<\/a> che cerca le vulnerabilit\u00e0 nei vostri sistemi. Essi forniscono un set di due strumenti di revisione del codice:<\/p>\n La revisione del codice fa parte della Software Composition Analysis e potete optare per una demo di Veracode<\/a> prima di impegnarvi completamente in essa. Ecco il link per richiedere un preventivo<\/a>.<\/p>\n Reviewable<\/a> \u00e8 uno strumento di revisione del codice per le richieste pull di GitHub<\/a>. \u00c8 gratuito per i repository open source, con piani per i repository privati a partire da $39 al mese per dieci utenti. Dal momento che lo strumento \u00e8 integrato con GitHub, potete accedere utilizzando il vostro account GitHub e iniziare.<\/p>\n Se volete vedere come risulta una tipica revisione fatta con Reviewable, potete dare un\u2019occhiata alla revisione demo<\/a>.<\/p>\n Un aspetto interessante di Reviewable \u00e8 che supera alcuni inconvenienti della revisione del codice presenti nella funzionalit\u00e0 di richiesta pull di GitHub. Per esempio, un commento su una linea di codice viene automaticamente nascosto da GitHub una volta che uno sviluppatore cambia la linea perch\u00e9 GitHub presume che il problema sia stato risolto. In realt\u00e0, le cose possono essere diverse.<\/p>\n Inoltre, GitHub ha limiti di linea relativamente ridotti per la visualizzazione dei file diff.<\/p>\n Se siete alla ricerca di uno strumento strettamente coerente con GitHub ma desiderate pi\u00f9 funzionalit\u00e0 che richieste di pull, Reviewable dovrebbe essere il vostro strumento di riferimento.<\/p>\n Se utilizzate Subversion, il plugin Peer Review for Trac<\/a> fornisce un’opzione gratuita e open source per condurre revisioni del codice sui vostri progetti. Il Peer Review Plugin si integra nel progetto open source Trac<\/a>, che \u00e8 un wiki e un sistema di tracciamento dei problemi per i progetti di sviluppo.<\/p>\n Trac integra il wiki e l\u2019issue tracker con le vostre recensioni per fornire una soluzione end-to-end. Mentre sono disponibili le funzionalit\u00e0 di base per confrontare le modifiche e la conversazione, il plugin consente di progettare flussi di lavoro personalizzati<\/a> per i vostri progetti.<\/p>\n Ad esempio, potreste decidere i compiti da svolgere in seguito a un trigger come la presentazione di una modifica o l’approvazione di una revisione del codice. Potete anche creare report personalizzati<\/a> sui vostri progetti.<\/p>\n Se siete anche alla ricerca di un wiki per la documentazione e di un issue tracker per gestire la roadmap del vostro progetto, Trac potrebbe essere l\u2019opzione corretta per voi.<\/p>\n\n La procedura di revisione del codice gioca un ruolo chiave quando si tratta di aumentare l’efficienza della vostra organizzazione. In particolare, sfruttare il giusto strumento di revisione vi aiuta a rimuovere la ridondanza nel vostro ciclo di sviluppo.<\/p>\n Abbiamo guardato pi\u00f9 da vicino gli strumenti di revisione del codice pi\u00f9 popolari disponibili nel [anno] ed ecco cosa abbiamo trovato:<\/p>\n Ora tocca a voi: quale strumento di revisione del codice utilizzate? Perch\u00e9? Ditecelo nei commenti!<\/p>\n Letture consigliate:<\/strong><\/p>\n La revisione del codice \u00e8 una parte del processo di sviluppo del software che prevede di testare il codice sorgente per identificare i bug in una …<\/p>\n","protected":false},"author":118,"featured_media":35480,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[19973,67],"topic":[25883,25873],"class_list":["post-35462","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-code","tag-webdev","topic-strumenti-di-sviluppo-web","topic-sviluppo-wordpress"],"yoast_head":"\n![\"Mantenete](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/03\/coding-review-process-scaled-1.jpg\")
Perch\u00e9 la Revisione del Codice \u00c8 Fondamentale?<\/h2>\n
\n
Come Eseguire una Revisione del Codice?<\/h2>\n
Revisioni del Codice Over-the-Shoulder<\/h3>\n
Email Pass-Around<\/h3>\n
![\"Email](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/03\/email-review-1.png\")
Programmazione in Coppia<\/h3>\n
![\"La](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/03\/in-person-code-review-scaled-1.jpg\")
Tool-Assisted<\/h3>\n
\n
Perch\u00e9 Utilizzare gli Strumenti di Revisione del Codice?<\/h2>\n
Uno Sguardo Pi\u00f9 Attento a 12 Potenti Strumenti di Revisione del Codice<\/h2>\n
1. Review Board<\/h3>\n
![\"Panoramica](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/03\/review-board.png\")
\n\u00c8 possibile integrare la scheda di revisione con una vasta gamma di sistemi di controllo di versione – Git<\/a>, Mercurial, CVS, Subversion e Perforce. \u00c8 inoltre possibile collegare Review Board ad Amazon S3<\/a> per memorizzare gli screenshot direttamente nello strumento.<\/p>\n![\"Panoramica](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/03\/review-board-modifiche.png\")
2. Crucible<\/h3>\n
![\"Strumento](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/03\/crucible.png\")
3. GitHub<\/h3>\n
![\"Lo](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/03\/github-pull-request-review-1.png\")
4. Axolo<\/h3>\n
![\"Discussione](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/04\/PH4.png\")
![\"Il](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/04\/PH2.png\")
5. Collaborator<\/h3>\n
![\"Collaborator](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/03\/collaborator.jpg\")
6. CodeScene<\/h3>\n
![\"Analisi](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/03\/codescene.png\")
![\"Knowledge](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/03\/mappe-di-conoscenza-di-codeascene.png\")
7. Visual Expert<\/h3>\n
![\"Panoramica](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/03\/visual-expert.png\")
8. Gerrit<\/h3>\n
![\"Strumento](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/03\/gerrit.png\")
9. Rhodecode<\/h3>\n
![\"Rhodecode\"](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/03\/rhodecode.png\")
10. Veracode<\/h3>\n
\n
![\"Panoramica](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/04\/veracode.png\")
11. Reviewable<\/h3>\n
![\"Panoramica](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/03\/reviewable.png\")
12. Peer Review for Trac<\/h3>\n
![\"Plugin](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/03\/peer-review-for-trac.png\")
Riepilogo<\/h2>\n
\n
\n