El camino del Desarrollador de Código Limpio comienza con el nivel rojo. A partir de aquí, la primera parte de los bloques de construcción del Desarrollador de Código Limpio debe incorporarse al trabajo diario y practicarse una y otra vez. El nivel rojo está diseñado para que cada desarrollador pueda empezar aquí con el mínimo esfuerzo. Apenas deberían ser necesarios cambios en las condiciones del proyecto. Esto significa que cualquiera puede iniciar su andadura como Clean Code Developer "tranquilamente".
Índice
Principios
No se repita (DRY)
Cualquier duplicación de código o acciones favorece las incoherencias y los errores.
| Cambiabilidad | |
|---|---|
| Corrección | |
| Eficacia de la producción | |
| Mejora continua | |
| Desarrollador único |
El principio DRY es: No se repita - No se repita. Ha sido cierto desde el principio del desarrollo de software; de lo contrario, no habría subrutinas ni normalización de datos. Sin embargo, es probablemente el principio más ignorado. Porque no hay nada más fácil que repetir código copiando y pegando. Esto ocurre con demasiada frecuencia, sobre todo cuando hay que hacer las cosas rápidamente.
Los desarrolladores de código limpio practican este principio en todo momento. Son conscientes de cuándo están repitiendo código u otros artefactos. Reconocen las repeticiones que ellos mismos u otros han creado. Limpian las repeticiones mediante la refactorización, si no hay otros principios o restricciones que se opongan a ello.
Mantenlo simple, estúpido (KISS)
Si haces algo más que lo más sencillo, haces esperar al cliente y complicas innecesariamente la solución.
| Cambiabilidad | |
|---|---|
| Corrección | |
| Eficacia de la producción | |
| Mejora continua | |
| Desarrollador único |
O dicho en palabras de Albert Einstein: "Todo debe hacerse lo más sencillo posible, pero no más sencillo". Para que el código sea modificable, debe ser comprensible. Por tanto, siempre hay que favorecer una solución sencilla, clara y fácil de entender. Si al cabo de poco tiempo ya no entiendes tu propio código, deberían saltar las alarmas. Sin embargo, es aún más importante que otros desarrolladores también puedan entender rápidamente el código. Las revisiones periódicas y la programación en parejas ayudan a ello. Sirven para comprobar si realmente se ha utilizado la solución más sencilla.
Existe la tentación de buscar una solución complicada, sobre todo cuando se trata de detalles técnicos. Lo conocido y obvio a veces resulta demasiado "aburrido", y ya se ha colado una solución complicada. Si la solución sencilla también funciona, hay que darle prioridad. Lo mismo ocurre con las estructuras de datos. Si una IEnumerable es suficiente, no IColección o incluso IList se puede utilizar.
Cuidado con la optimización prematura
La optimización siempre cuesta mucho esfuerzo. Quienes actúan con cautela suelen ahorrar valiosos recursos para lo que realmente beneficia al cliente.
| Cambiabilidad | |
|---|---|
| Corrección | |
| Eficacia de la producción | |
| Mejora continua | |
| Desarrollador único |
Regla 1: No lo hagas.
Regla 2 (sólo para expertos): No lo hagas todavía.
Siempre se hace hincapié en la comprensibilidad del código. Sin embargo, el código optimizado suele ser cualquier cosa menos legible. Al reducirlo a lo estrictamente necesario de la forma más breve posible, puede que cumpla los requisitos funcionales y no funcionales del cliente, pero normalmente ya no los refleja de forma comprensible. Esto es contraproducente para la longevidad del software, que suele ser la deseada. Donald Knuth escribió ya en 1974: "Hay que olvidarse de las pequeñas eficiencias, digamos unas 97% del tiempo: la optimización prematura es la raíz de todos los males." (Knuth, Donald. Programación estructurada con sentencias go toACM Journal Computing Surveys, Vol 6, No. 4, Dic. 1974. p.268).
Por tanto, la regla del buscador de caminos no significa que debamos esforzarnos siempre por optimizar el código. Más bien se refiere a lo contrario: comprensibilidad y capacidad de cambio.
Así que si al desarrollador de código limpio le tiemblan los dedos porque cree que aún puede sacarle un poco de rendimiento mediante la optimización, al menos debería pensárselo dos veces. Por un lado, esto empeoraría la comprensibilidad, pero por otro es probable que esa optimización ni siquiera sea necesaria por varias razones. Si la debilidad de rendimiento no es sólo selectiva y un caso especial, la próxima refactorización importante probablemente se encargará de ella de todos modos, porque entonces se basa en un problema estructural fundamental. O la próxima generación de hardware solucionará el problema de rendimiento. O el cliente no se siente molesto por ello en absoluto. En cualquier caso, el cliente debe haber solicitado la optimización. Ningún cambio de código sin el beneficio esperado por el cliente. Porque sólo están dispuestos a pagar por ello.
La regla de no optimizar en caso de duda se basa en otra aún más fundamental: el YAGNI. No lo vas a necesitar. En su forma completa, sin embargo, es sólo una parte de la grado azul.
P.D.: Si, a pesar de todas las advertencias y preocupaciones, la optimización del rendimiento es inevitable, sólo debería iniciarse sobre la base de un análisis detallado con un perfilador. Porque sólo quien haya utilizado un perfilador para localizar de forma comprensible los cuellos de botella de rendimiento podrá comprobar durante y después de la optimización si los ha ampliado y en qué medida.
Favorecer la composición sobre la herencia (FCoI)
La composición favorece el acoplamiento flexible y la comprobabilidad de un sistema y suele ser más flexible.
| Cambiabilidad | |
|---|---|
| Corrección | |
| Eficacia de la producción | |
| Mejora continua | |
| Desarrollador único |
La programación orientada a objetos (POO) reconoce dos candidatos muy conocidos para la reutilización de funcionalidades: La herencia (caja blanca - reutilización) y la composición (caja negra - reutilización). Si la funcionalidad se reutiliza derivándola de una clase, la subclase depende de la clase padre. En muchos casos, esto hace que un sistema sea innecesariamente complejo, menos comprobable y dificulta el intercambio de funcionalidad en tiempo de ejecución. El CCD ha proporcionado el Principio de Sustitución de Liskov (LSP) para la derivación correcta, que debe seguirse.
Durante la composición, una clase utiliza a otra. Si se utiliza una interfaz claramente definida, se favorece el desacoplamiento. También se pueden intercambiar fácilmente diferentes implementaciones. Así pues, antes de abordar la sustitución de Liskov, Favour Composition over Inheritance le pide que se pregunte si puede dar prioridad a la composición.
„Dado que la herencia expone una subclase a los detalles de la implementación de su padre, se suele decir que "la herencia rompe la encapsulación".". (Gang of Four 1995:19)
Principio de Segregación de Operaciones de Integración (IOSP)
Las jerarquías profundas de dependencias funcionales son un síntoma claro de código poco modificable. Reducen la comprensibilidad y dificultan pruebas automatizadas como la refactorización.
| Cambiabilidad | |
|---|---|
| Corrección | |
| Eficacia de la producción | |
| Mejora continua | |
| Desarrollador único |
Al mezclar instrucciones generadoras de comportamiento (lógica) en métodos con llamadas a otros métodos de la misma base de código, deja de estar claro cómo se crea el comportamiento global; las instrucciones se esparcen por una jerarquía posiblemente muy profunda. Además, los métodos con esa mezcla tienden a crecer indefinidamente.
La IOSP contraataca con una clara separación:
- Un método sólo contiene lógica, es decir, transformaciones, estructuras de control o E/S o, de forma más general, llamadas a la API. Entonces se denomina Operación llamado.
- O un método no contiene ninguna lógica, sino sólo llamadas de otros métodos de la misma base de código. Entonces se convierte en Integración llamado.
Esta estricta diferenciación tiene varios efectos positivos:
- Los métodos tienden a ser muy cortos. Esto se debe a que más de 10, 20 o 30 líneas de pura lógica o exclusivamente llamadas a métodos "no sientan bien". Como no se permite una mezcla, se extraen pequeños métodos adicionales.
- Los métodos cortos que sólo contienen lógica son fáciles de probar, ya que no tienen dependencias.
- Los métodos cortos que sólo contienen lógica son comparativamente fáciles de entender. El nombre del método puede tener realmente un efecto significativo.
- Los métodos cortos que sólo integran son muy fáciles de entender y describen "de un vistazo" lo que ocurre.
- La corrección de las integraciones puede comprobarse muy fácilmente mediante inspección visual. Sólo es necesario determinar si los pasos de procesamiento están dispuestos básicamente en el orden correcto. Del resto se encarga el compilador, o la cobertura de las pruebas de las operaciones.
- Las integraciones pueden ampliarse fácilmente "interponiendo" métodos adicionales para cumplir nuevos requisitos. En el proceso se mantiene la comprensibilidad.
La IOSP puede ser aplicada "de improviso" por cualquier desarrollador de buena voluntad. Cumplirla es fácil de comprobar para cualquiera. La forma de las integraciones y operaciones difiere significativamente. Más detalles, en particular sobre la diferenciación de la Principio de inversión de la dependencia (DIP), aquí, por ejemplo.
Prácticas
Regla de los Boy Scouts
Cada vez que tratas un objeto, se vuelve al menos un poco mejor. Sin planificación burocrática. Fundación y enfoque de base para más calidad.
| Cambiabilidad | |
|---|---|
| Corrección | |
| Eficacia de la producción | |
| Mejora continua | |
| Desarrollador único |
El sistema de valores de Clean Code Developer no puede establecerse de golpe. Se necesita tiempo. Sobre todo porque un Clean Code Developer rara vez trabaja en un sitio nuevo y solo, es difícil aplicar los principios a toda una base de código. Por eso creemos que es importante no fijarse metas demasiado altas. Es mucho más realista y motivador esforzarse por conseguir pequeños avances, pero avances continuos.
Para nosotros, la regla del pathfinder forma parte, por tanto, de los cimientos del desarrollo limpio de código. También se encuentra en Código limpio y dice: Deja siempre un lugar en mejores condiciones de las que lo encontraste.
Aplicado al desarrollo de software, esto significa que los desarrolladores de código limpio siempre dejan el código en un "mejor estado" del que lo encontraron. Una vez terminado el trabajo, el código está más en consonancia con el sistema de valores del Desarrollo de Código Limpio que antes.
Lo que un desarrollador de código limpio ha hecho para ello depende de la situación/código y, por supuesto, también viene determinado por el nivel en el que esté trabajando. En el nivel rojo, por ejemplo, un desarrollador de código limpio se asegura de que el código que aún no estaba en el repositorio de gestión de versiones ahora también está almacenado allí. Y se asegura de que las repeticiones de cualquier tipo -es decir, las violaciones del principio DRY- se "limen".
Cuando un desarrollador de código limpio identifica una suboptimización en el sentido del sistema de valores CCD, se esfuerza constantemente por mejorarla. En pequeños pasos. Y, por supuesto, se esfuerza por evitar las suboptimizaciones desde el principio. Como ya he dicho: siempre en la fase de desarrollo.
Esta máxima se sitúa en el inicio del desarrollo del Clean Code Developer, teniendo en cuenta la Teoría de las ventanas rotas. Según ella, el deterioro de la calidad en sentido general comienza con pequeñas cosas que pasan desapercibidas durante el tiempo suficiente.
Sin embargo, si los desarrolladores de código limpio trabajan según la regla del buscador de caminos, no hay "ventanas rotas" en primer lugar: las existentes se reparan una a una. La regla del buscador de caminos cierra sistemáticamente las "grietas y baches" del código sobre la base del sistema de valores CCD, de modo que no puedan acumularse más "depósitos". De este modo, contrarresta proactivamente la erosión del código. Consideramos que esto es tan fundamental que lo hemos incluido en la nota roja.
Análisis de las causas
Tratar los síntomas puede suponer un alivio rápido, pero a largo plazo cuesta más esfuerzo. En cambio, si se mira bajo la superficie de los problemas, se acaba trabajando de forma más eficiente.
| Cambiabilidad | |
|---|---|
| Corrección | |
| Eficacia de la producción | |
| Mejora continua | |
| Desarrollador único |
La norma desde el primer día como desarrollador de código limpio debería ser buscar siempre intensamente la verdadera raíz del problema. Los desarrolladores de código limpio no se conforman con curar los síntomas. Ejemplo: La ordenación de datos en memoria es demasiado lenta. Un remedio superficial sería acelerar instrucciones individuales o bloques de instrucciones. Quizás se probaría el uso de código inseguro, quizás la paralelización. Sin embargo, un análisis más profundo del problema habría revelado que la raíz del problema es un algoritmo subóptimo. Por lo tanto, se pueden evitar las optimizaciones difíciles de entender a un bajo nivel de abstracción. Un algoritmo mejor es la solución limpia.
El análisis del problema de raíz es, por tanto, un servicio en términos de comprensibilidad y esfuerzo. Porque si se conoce el problema de raíz, la limpieza suele llevar menos tiempo que la cura de los síntomas. Si el desarrollador de código limpio se encuentra con un problema, lo primero que hace es hacer una pausa para darse la oportunidad de mirar detrás de los síntomas.
El Análisis de Causas Raíz también se conoce como los Cinco Porqués. Este término procede de la terminología del Sistema de Producción Toyota (TPS). La idea básica: preguntar "¿Por qué?" al menos cinco veces.
Sistema de control de versiones
El miedo a dañar un "sistema en funcionamiento" paraliza el desarrollo de software. Con la gestión de versiones, esos temores son infundados. El desarrollo puede ser rápido y audaz.
| Cambiabilidad | |
|---|---|
| Corrección | |
| Eficacia de la producción | |
| Mejora continua | |
| Equipo |
Un requisito esencial para todo desarrollador de código limpio es colocar su código bajo la protección de un sistema de control de versiones. Que sea Mercurial, Git, Subversion, VSS, TFS o Vault es irrelevante. Simplemente creemos que hoy en día no se debería trabajar con código sin mantenerlo en un sistema de control de versiones. La razón es muy sencilla: un sistema de control de versiones libera del miedo. Y la libertad del miedo es necesaria para aplicar con valentía los principios y prácticas del sistema de valores del CCD.
Un sistema de control de versiones elimina el miedo a hacer algo mal y, por tanto, a romperlo. Si el código se mantiene en él, cualquier CCD puede cambiarlo a voluntad sin tener que preocuparse de destruir una versión existente. No se pierde nada. El sistema de control de versiones es como una máquina del tiempo para el código.
Esto hace que un sistema de control de versiones sea la mejor base para todo aprendizaje. Porque aprender significa cometer errores. Con un sistema de control de versiones como red de seguridad, todos podemos permitirnos cometer errores. Por lo tanto: El primer prerrequisito para empezar a desarrollar código limpio es el uso constante de un sistema de control de versiones.
Cuando esto no es posible en el proyecto, vemos que faltan los cimientos para un desarrollo limpio del código. Tampoco entendemos por qué no es posible utilizar una herramienta de control de versiones. No supone ningún coste y la formación necesaria para las funciones más sencillas es mínima. El CCD no prescribe ningún uso particular de un sistema de control de versiones, sólo que debe utilizarse uno.
Véase también Herramientas.
Refactorizaciones sencillas
Mejorar el código es más fácil si se conocen las técnicas típicas de mejora. Sus escenarios de aplicación le sensibilizan sobre los puntos débiles de su propio código. Como patrones reconocidos, refuerzan el valor para aplicarlos.
| Cambiabilidad | |
|---|---|
| Corrección | |
| Eficacia de la producción | |
| Mejora continua | |
| Desarrollador único |
Para dejar siempre el código un poco mejor de lo que lo encontraste, son necesarias intervenciones más o menos importantes. Gracias al sistema de control de versiones, un desarrollador de código limpio puede hacerlo sin miedo. Pero, ¿cómo facilitar al máximo su trabajo?
La palabra clave es "refactorización". Martin Fowler tiene el Refactorización/refactorización en su libro del mismo nombre como técnica fundamental para aumentar la calidad del código. En él define una serie de patrones de cambio de código para limpiar los "olores de código", es decir, las estructuras subóptimas o el desprecio general por los principios.
Para el grado rojo, se trata sobre todo de refactorizar Método de extracción relevante para cumplir el principio DRY. Los desarrolladores de código limpio lo utilizan para extraer el código que aparece varias veces en un método que se llama en los lugares de repetición en su lugar.
Como segunda refactorización, cuando se trabaja en el grado rojo, el Cambie el nombre de cuando sea necesario. Encaja con la regla pathfinder, ya que los nombres crípticos son una "suciedad" frecuente en el código fuente.
Las refactorizaciones pueden aplicarse manualmente, pero también existen herramientas de apoyo. Los IDE modernos, como Visual Studio, ofrecen algunos patrones de refactorización. Lista de herramientas.
"Refactorización" y "código limpio" forman parte de la Lecturas obligatorias de cada Desarrollador de Código Limpio a partir del nivel rojo.
Para más información, véase también refactorización-legacy-code.net.
Reflexión diaria
No hay mejora, no hay progreso, no hay aprendizaje sin reflexión. Pero la reflexión sólo tiene lugar bajo la presión del día a día si también se planifica.
| Cambiabilidad | |
|---|---|
| Corrección | |
| Eficacia de la producción | |
| Mejora continua | |
| Desarrollador único |
El desarrollo personal está en el centro del CCD. Así pues, se trata de cambiar: cada día, el sistema de valores del CCD debe manifestarse un poco más en la vida cotidiana del Clean Code Developer. Esta es la regla del Clean Code Developer aplicada a sí mismo.
Sin embargo, este camino de cambio no es fácil de recorrer en solitario. ¿Cómo mantener el rumbo? ¿Cómo medir los progresos?
Sin querer establecer un "sistema de control", creemos que esto implica dos cosas:
- Planificación a pequeña escala
- Reflexión después de cada paso
Independientemente de las directrices de gestión de proyectos, los desarrolladores de código limpio deben organizar su trabajo de forma que conste de tareas que puedan completarse en una jornada laboral. Sólo así se puede hacer balance al final de cada jornada. Creemos que esto es importante para que el trabajo no se prolongue hasta la noche. Ahí no tiene cabida; es para relajarse.
Sin embargo, estos pequeños pasos de planificación no sólo hacen más satisfactoria la vida laboral cotidiana, porque el éxito o el fracaso pueden decidirse cada día. La mera posibilidad de tomar una decisión por la tarde ¿He completado todas mis tareas? ¿Cómo he completado mis tareas? - también permite reflexionar sobre el cumplimiento del sistema de valores de Clean Code Developer.
Con el fin de convertirse sistemáticamente en un desarrollador de código limpio, el desarrollador debe preguntarse a sí mismo después de cada día de trabajo en cada nivel si ha tenido en cuenta todos los aspectos del sistema de valores relevantes para él por nivel. Para el nivel rojo, esto significa plantearse preguntas como: ¿Realmente gestiono todos los fragmentos de código en el sistema de control de versiones? ¿He aplicado sistemáticamente el principio DRY? ¿He dejado generalmente el código en mejor estado del que lo encontré?
Si tiene que responder a alguna de estas preguntas con un sí vacilante o incluso con un no, por supuesto que no es nada malo. Por mucho que lo intente, no siempre es posible poner en práctica sus buenas intenciones.
Sin embargo, o precisamente por ello, hay que hacer lo siguiente:
- O bien el desarrollador de código limpio introduce ahora mejoras hasta que deja de percibir una violación de los principios en relación con su trabajo diario.
- O incluye las violaciones de principios reconocidas en su lista de tareas pendientes para el día siguiente.
El Clean Code Developer puede ayudar con la reflexión. Pulsera ser. Somos conscientes de que llevar una pulsera de silicona de colores no es del agrado de todo el mundo. Aquellos que no tengan ningún problema con esto pueden usar la pulsera como parte de su reflexión personal. Si el Clean Code Developer no puede o no quiere limpiar la violación de principios o añadirla a su lista de trabajo, debe cambiar la pulsera que lleva de un brazo al otro. De este modo, deja claro que reconoce una diferencia entre el objetivo de su nota y lo que ha conseguido. Esto no debe malinterpretarse como una derrota o incluso como una "penitencia". Se trata más bien de un apoyo háptico al proceso de aprendizaje.
Si un Desarrollador de Código Limpio no ha tenido que cambiar su pulsera durante 21 días después de completar su trabajo, puede pasar a trabajar en el siguiente grado. Para el nivel rojo, este es el grado naranja.
Español 
Deutsch 
English 
Français