Un código sostenible minimiza estos tres elementos degradantes mediante una serie de principios y técnicas, que se aplican desde lo más minucioso hasta lo más global. Y es que, en el día a día, estamos constantemente tomando decisiones a la hora de programar, pero a veces ni siquiera somos conscientes de ello, y son importantes, como qué nombre ponemos a una variable o a una clase, o si utilizamos una clase o dos, o dónde la colocamos. Esas pequeñas decisiones son las que hacen que el código se mantenga con una calidad sostenible o que se degrade. Por ello, es muy importante que seamos conscientes.

Se proponen cuatro reglas para conseguir esta sostenibilidad en el código:

• El código está bien cubierto por baterías de test automáticos.
• Esos test son sostenibles: útiles y fáciles de mantener.
• Las abstracciones son adecuadas y precisas.
• Hay una notable intención, bien explícita, en cada línea de código escrita.

La primera es que debería tener test automáticos: si el código no tiene test no vamos a tener tranquilidad para cambiarlo.

La segunda es que esos test sean sostenibles, esto es una definición un poco recursiva, y es que lo que viene diciendo es que sean útiles, que cuando un test falle nos explique muy bien donde está el problema, que nos dé un feedback rápido y, en definitiva, que se puedan mantener en el tiempo con facilidad en el caso de que haya, por ejemplo, cambios en el diseño.

La tercera regla es que las abstracciones que tengamos en el código sean las adecuadas, que no hablemos de primitivos, que no hablemos de mecanismos de implementación técnicos sino que nos centremos en el lenguaje del negocio y tampoco queremos generalizaciones o abstracciones marcianas que no pegan en ese dominio.

La cuarta regla es que programemos con una intención de lo que estamos haciendo: que cuando alguien venga y lea nuestro código se note perfectamente cual era nuestra intención y qué queríamos hacer y que no haya dudas sobre qué puede estar haciendo el código en cada una de esas líneas.