Clean code, ¿Qué es? ¿Cómo usarlo?

Hola estimados lectores, para esta entrada quisiera ayudarlos a comprender e implementar Clean Code en sus proyectos, esta entrada esta redactada conforme mi experiencia me gustaría leer comentarios en los que puedan atribuir ustedes hasta donde usan clean code a la hr de "tirar" código.

Pero, ¿Qué es Clean code?
Clean code puedo definirlo como una serie de buenas prácticas con las que el desarrollador puede dejar un código legible, elegante y eficaz (entre muchos otros elogios) para el desarrollador que en un futuro (cercano o lejano) le llegue a dar mantenimiento, desde el simple nombre de una variable hasta pruebas unitarias concretas debes tener en cuenta para tener un código limpio, siempre debes tener en cuenta codificar no para ti, sino para que otra persona pueda comprender tu código.

Ok, Ok y ahora ¿Cómo lo implementamos?
Dentro de Clean code, existen una serie de reglas o puedo llamar buenas prácticas en las cuales abundaré de forma sencilla para que no sea tan complejo comprenderlas.

1ra- Nombres con sentido
Cuantas veces puedes recordar que hayas dado mantenimiento a un segmento de código, a un sistema o módulo, en donde tu reacción al leer el código fue de Whaaaat?, incluso hasta con tus propios códigos (me pasaba en donde ni siquiera yo podía leer mis lineas).
La primera regla nos habla de poder redactar variables, objetos, propiedades que tengan sentido, en donde podamos aclarar sin necesidad de hacer debug  cual es la función de dicho objeto asi de simple.

Nombres de clases
Las clases u objetos deben tener nombres o frases de nombre como cliente, wikipage, cuenta. Evite palabras como manejador, procesador, data o información en el nombre de una clase. El nombre de una clase no debe de ser un verbo.

Nombre de métodos

Los nombres se métodos deben de tener nombres de verbo como EnviarPago, BorrarPagina o Guardar.

2da- No repitas lo que no debe repetirse (Don't repeat yourself)
El código repetido es uno de los factores que hacen super cansado el mantenimiento de los códigos, esta regla nos dice que no debemos andar copiando y pegando los mismos códigos por todo el proyecto, es mejor hacer métodos compartidos en donde el manejo de parámetros sea dinámico, de esta forma el mantenimiento se hace directamente a un solo código.

3ra- Que tus funciones hagan los que se supone deben hacer (The Principle of Least Surprise)
Aquí debo decir que usualmente tenemos la mala costumbre de que en un solo método queremos dominar el mundo, 1500, 2000 o mas lineas de código, la idea principal de esta regla es que cada función debe realizar la tarea por la que fue diseñada, si tienes un método en el que obtienes un resultado numérico asegurate que cualquier otra operación esté separada en su propio método, de esta forma puedes realizar unit test por cada método asegurando su correcto funcionamiento.

La siguiente imagen representa todo lo que esta tercera regla nos aconseja

4ta- La regla del boy scout
Aquí en lo personal me ha pasado de todo, desde comentarios graciosos como "Cosas locas que ni yo sé que hacen" hasta variables declaradas como aux, obj, aux1, aux2.
Usualmente los boy scout cuando asisten a sus campamentos siempre dejan igual o más limpio su lugar de campamento, esto es lo que nosotros deberíamos hacer en los códigos, poder hacer un refactor en donde puedas optimizar, cambiar los nombres a unos mas claros, redactar los summaries de los métodos, etc; algo que ayude a mejorar el código al cual le das mantenimiento.

Usa regiones, documenta tú código, utiliza dtos para la transferencia de información
Este es un consejo de mi parte el uso de regiones para segmentar ciertos método de una clase hace que tú código genere confianza a quien le vaya dar mantenimiento, creeme sirve más de lo que piensas.
Utiliza clases que solo contengan propiedades para almacenar y transferir información entre clases, a estas clases con esas características se les llama Dto esto es sumamente útil al momento de manejar servicios web.
Por último agrega un summary a cada método que hagas, esto es realmente necesario ya que si realizas métodos para re utilizar es necesario saber que significa cada parámetro, y obvio un resumen de la funcionalidad del método, nuevamente reitero recuerda debes codificar no para ti sino para quien viene detrás de ti.

El uso de summaries en tus métodos hacen que se comprenda de una forma más ágil la funcionalidad de los mismos

Aquí puedes observar como dos clases se convierten en un dto que comparte los mismos atributos

Para concluir
Existe un libro llamado Clean code del cuál he tomado la experiencia para poder darles estos tips, existen más reglas pero para mi estas son de las más importantes, además si no estas acostumbrado a llevar este tipo de disciplina y buenas prácticas es mejor comenzar poco a poco, creeme parece difícil al principio adaptarse a realizar lo que has leido hoy pero después de un tiempo de práctica haces un hábito cada una de ellas.

Me gustaría leer ustedes que opinan de este tema, y cuales son las buenas prácticas que utilizan al estar desarrollando.

Les mando un saludo, happy coding!