diff --git a/docs/it/refactoring.md b/docs/it/refactoring.md
index de9f621d..41e66937 100644
--- a/docs/it/refactoring.md
+++ b/docs/it/refactoring.md
@@ -70,7 +70,7 @@ function getNetto() {
 ```
 
 Leggendone il contenuto è chiaro che ci sta tornando il totale del carrello al netto di eventuali sconti ma, senza conoscerne il contenuto, come facciamo a esserne sicuri?
-Proviamo quindi a rinominarlo con qualcosa di più "parlante".
+Proviamo quindi a rinominarlo con qualcosa di più espressivo.
 
 ```
 function getAmountWithAppliedDiscount() {
@@ -167,11 +167,11 @@ Il refactoring è un'attività contingentata che ci permette di guardare con dis
 
 ## Automazione
 
-Esistono ovviamente diversi strumenti per automatizzare le procedure di refactoring, spesso integrati direttamente nell'IDE. Forse il più famoso è Sonarqube.
+Esistono ovviamente diversi strumenti per automatizzare le procedure di refactoring, spesso integrati direttamente nell'IDE. Forse il più famoso è [Sonarqube](https://www.sonarsource.com/products/sonarqube/).
 Questi strumenti, basati su motori di analisi affidabili e complessi, riescono a individuare dalla banale duplicazione del codice alla mancata adozione di buone pratiche, spesso specifiche del linguaggio di programmazione adottato.
-A volte riescono a fare miracoli, ma a noi preme focalizzarci su un punto della questione: l'effort.
+A volte riescono a fare miracoli, ma a noi preme focalizzarci su un punto della questione: l'**effort**.
 Quanto effort occorre ad effettuare del refactoring con questi strumenti? O meglio, quanto semplificano la vita di chi sviluppa?
 È innegabile che sono dei validi aiuti e che sono formidabili nel farci notare parti di codice da semplificare a cui, magari, non avevamo nemmeno fatto caso.
 Tuttavia, affidare il refactoring all'automazione può creare delle situazioni in cui il codice modificato è così tanto, da rendere complicato il controllo da parte di chi sviluppa, tanto che potrebbe avere la tentazione di prendere in blocco tutte le modifiche. Se poi siamo in presenza di una scarsa copertura di test, la frittata è fatta.
-C'è poi un altro aspetto da considerare: la specificità. Gli strumenti utilizzati sono perfettamente in grado di identificare un eventuale problema e a darci indici di complessità. Ma non riescono a renderci edotti del codice nel suo complesso. Senza conoscere come le varie parti del codice interagiscono nel contesto, difficilmente riusciremo a individuare eventuali errori logici o colli di bottiglia.
+C'è poi un altro aspetto da considerare: la **specificità**. Gli strumenti utilizzati sono perfettamente in grado di identificare un eventuale problema e a darci indici di complessità. Ma non riescono a renderci edotti del codice nel suo complesso. Senza conoscere come le varie parti del codice interagiscono nel contesto, difficilmente riusciremo a individuare eventuali errori logici o colli di bottiglia.
 Ciò nonostante, rimangono degli ottimi aiutanti: se ad essi affidiamo la correzione di tutti quegli "errori" semplici, come la tipizzazione delle variabili (nel caso di linguaggi tipizzati, ovviamente) o la riscrittura di una funzione utilizzando il pattern _Early Return_, ci ritroveremo a dover rifattorizzare del codice già scremato, lasciando la nostra mente libera di concentrarsi sul resto del lavoro da fare.