G.K. Chesterton è stato uno scrittore e giornalista britannico. Ha scritto moltissimi saggi e libri, ed uno in particolare nel 1929 chiamato “The Thing” (successivamente tradotto in italiano con il titolo “La mia fede”) introduce il concetto che verrà poi conosciuto come Chesterston’s Fence:

There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”

The thing, G.K Chesterton

Nella sua forma più concisa: Non rimuovere una staccionata finché non sai perché inizialmente è stato deciso di innalzarla. Di certo nessuno ha voglia di innalzare una staccionata senza avere un buon motivo per farlo.

Questo principio si può applicare anche a sistemi informatici. Navigando in un code base molto vecchio è facile incappare in sezioni di codice che apparentemente non hanno senso. Condizione che anche il nostro IDE magari ci suggerisce che non possono mai verificarsi.

Spesso un git blame può esserci d’aiuto. Questo solo se colui/colei che ha aggiunto il codice, abbia deciso di documentare nella descrizione del commit il motivo per cui è stato necessario quel cambiamento. E’ molto comune infatti, e spesso ci casco io stesso, descrive nel messaggio di un commit cosa è cambiato. “Update README.md”, “Handle null with Optional”. Per avere una lista di cose che sono state cambiate in quel commit, un git diff è molto più efficace. Il codice non mente, e un messaggio di descrizione del genere non aggiunge nulla di più al codice. Un po’ come aggiungere un commento del tipo “questo for itera sugli elementi dell’array”.

La Chesterton’s Fence è utile da ricordare per impegnarsi ad evitare gli errori del passato. Le molte ore sono state spese nella stesura del codice, i molti bug corretti e lezioni imparate duramente, non dovrebbero essere dimenticati.

D’altra parte però, la Chesterton’s Fence non può essere una scusa per evitare i cambiamenti. Si potrebbe tradurre con “Si è sempre fatto così”. Se i motivi originali per cui una cosa è stata fatta in un certo modo sono andati persi, o sono invalidati per altre ragioni, allora il codice deve essere cambiato.