3. Abstracciones adecuadas y precisas:

• Abusamos de los tipos integrados del lenguaje.
• Creamos tipos extremadamente complejos y/o poco específicos.

La tercera regla, que habla de las abstracciones, lo que dice es que, típicamente, en los proyectos o bien abusamos de los tipos integrados del lenguaje, tales como los primitivos, strings, colecciones, etc., o bien creamos abstracciones de tipos propios que son extremadamente complejos y genéricos, que no se adaptan a lo que nos hace falta para ese dominio; en el punto medio es donde está la virtud.

Realmente, los tipos integrados y primitivos deberíamos limitarlos a interactuar con las capas de software de terceros (con la interfaz gráfica, la base de datos, ...) allá donde hacen falta tipos de datos interoperables, y, obviamente, no vamos a poder prescindir de ello para enviarlos a una API como JSON, etc.; para todo este tipo de cuestiones vamos a necesitar esos tipos de datos integrados.

Ahora vienen las capas de lógica de dominio: deberíamos crear nuestros propios tipos, nuestras propias clases que tengan semántica de dominio y que expresen esos conceptos que la gente de lenguaje de negocio maneja, y no inventarnos conceptos que son de otro ámbito o invenciones demasiado genéricas que luego nadie va a entender cuando llegue al proyecto.

4. Hay una notable intención bien explícita en cada línea de código escrita:

• Refactoriza a diario y respeta el principio de menor sorpresa.
• No tomes decisiones arbitrarias, intenta ser homogéneo y evita asimetrías en el código.
• Programa de una manera explícita con una intención clara.

Por último, la cuarta regla que habla de la intención es que tenemos que pensar siempre si nuestro código será entendible por otra persona o no, y, para ello, la mejor manera es releer todos los días el código del día anterior para ver si puede estar dando sorpresas y si va bien encaminado o si hemos cambiado de opinión con respecto a algún concepto que estábamos intentando reflejar ahí.

No tomemos decisiones arbitrarias con respecto al código: si hacemos las cosas de una determinada manera intentemos ser homogéneos y respetar esa estructura y esa forma de programar para no confundir a la persona que viene porque hay asimetrías, cuando el código está hecho de una manera en un sitio y en otro lugar que debería estar igual tiene otra forma diferente, eso confunde a la persona que viene y lo lee, que cree que se ha hecho así de una manera deliberada cuando en realidad ha sido una decisión arbitraria.

Por tanto, programa de una manera explícita con una intensión clara y ten la disciplina de hacer siempre las cosas de una manera razonada, intenta no inventarte cada vez que programas un artefacto una forma diferente.

Estas son, resumidamente, las cuatro reglas del código sostenible.