Chemaclass - refactoring

Artesanía Limpia

2022-07-11T00:00:00+00:00

El libro tiene tres partes: disciplinas, estándares y ética.

La primera es la más técnica. Te guía con ejemplos de TDD y muestra cómo el testing te ayuda a diseñar tu código.

La segunda trata sobre productividad, calidad y coraje.

La tercera explica cómo hemos llegado hasta aquí como profesionales del software y nuestra responsabilidad ética: no hacer daño, integridad y trabajo en equipo.

Una de mis partes favoritas del libro:

Nuestra industria es dinámica y cambia constantemente. Hay que aprender de forma continua y agresiva.

¿Cómo y cuándo aprendes? Si tu empresa te da tiempo para ello, aprovéchalo al máximo. Si no, tendrás que hacerlo por tu cuenta.

Prepárate para dedicar varias horas al mes. Reserva ese tiempo.

Sí, ya sé: familia, facturas, viajes, la vida. Pero también tienes una profesión. Y las profesiones requieren cuidado y mantenimiento. Aprendamos de forma continua y agresiva.

Capítulo 11. Coraje - Aprendizaje Agresivo Continuo

Índice #

Parte I: Las Disciplinas #

Capítulo 1. Artesanía #

Extreme Programming
Test-Driven Development
Refactoring
Diseño Simple
Programación Colaborativa
Tests de Aceptación

Capítulo 2. Test-Driven Development #

Visión General
Lo Básico

Capítulo 3. TDD Avanzado #

Quedarse Atascado
Arrange, Act, Assert
Test Doubles
Arquitectura

Capítulo 4. Diseño de Tests #

Testeando Bases de Datos
Testeando GUIs
Patrones de Test
Subclase Específica de Test
Humble Object
Diseño de Tests
Rompiendo la Correspondencia

Capítulo 5. Refactoring #

¿Qué es Refactoring?
El Kit Básico de Herramientas
Extract Method
Las Disciplinas

Capítulo 6. Diseño Simple #

YAGNI
Cubierto por Tests
Cobertura
¿Diseño?
Maximizar Expresión
La Abstracción Subyacente
Minimizar Duplicación
Minimizar Tamaño

Capítulo 7. Programación Colaborativa #

Capítulo 8. Tests de Aceptación #

La Disciplina
El Build Continuo

Parte II: Los Estándares #

Capítulo 9. Productividad #

Nunca Enviaremos M***da
Adaptabilidad Económica
Siempre Estaremos Listos
Productividad Estable

Capítulo 10. Calidad #

Mejora Continua
Competencia Sin Miedo
Calidad Extrema
No Volcaremos en QA
QA No Encontrará Nada
Automatización de Tests
Testing Automatizado e Interfaces de Usuario
Testeando la Interfaz de Usuario

Capítulo 11. Coraje #

Nos Cubrimos Mutuamente
Estimaciones Honestas
Debes Decir NO
Aprendizaje Agresivo Continuo
Mentoría

Parte III: La Ética #

El Primer Programador
Setenta y Cinco Años
Nerds y Salvadores
Modelos a Seguir y Villanos
Gobernamos el Mundo
Catástrofes
El Juramento

Capítulo 12. Daño #

Primero, No Hacer Daño
Mejor Trabajo
Prueba Repetible

Capítulo 13. Integridad #

Ciclos Pequeños
Mejora Implacable
Mantener Alta Productividad

Capítulo 14. Trabajo en Equipo #

Trabajar como Equipo
Estimar Honesta y Justamente
Respeto
Nunca Dejes de Aprender

Charla de Uncle Bob donde cubre la mayoría de los temas del libro.

Escucha sobre:
* Cita e Intro - [00:00:00]
* Trayectoria Profesional - [00:07:29]
* Clean Craftsmanship - [00:10:53]
* Programador como Profesión - [00:15:31]
* Artesanía - [00:18:45]
* Disciplinas - [00:22:45]
* Disciplinas: Test-Driven Development - [00:28:49]
* Disciplinas: Refactoring - [00:34:31]
* Cobertura de Código - [00:39:02]
* Estándar: Nunca Enviar M***da - [00:42:35]
* Estándar: Siempre Estar Listo - [00:47:15]
* Ética: No Hacer Daño - [00:50:00]
* Ética: Estimar Honestamente - [00:53:56]
* 2 Sabiduría de Tech Lead - [00:57:50]

London vs Chicago

2021-11-20T00:00:00+00:00

Hay dos escuelas conocidas en TDD: la escuela mockista (también conocida como Outside-in) y la escuela clasicista (también conocida como Inside-out).

¿Por qué London y Chicago? #

Dos empresas, una de Londres y otra de Chicago, afirmaban hacer TDD pero con enfoques diferentes. La de Londres construía software de afuera hacia adentro; la de Chicago, de adentro hacia afuera. Veamos cada una.

Outside-in: Escuela de Londres #

Un enfoque guiado por comportamiento para TDD. Empiezas desde el exterior de la aplicación y vas hacia adentro, bajando a capas inferiores. Por ejemplo, desde la API/Controladores hacia las capas de aplicación o dominio.

PROS #

Enfocado en Comportamiento: requiere muchos dobles de test porque testeas abstracciones que aún no existen (creas lógica de alto nivel primero). No escribirás código muerto, pero es fácil crear tests muy acoplados a la lógica, lo que dificulta el refactoring.
Separación Comando-Consulta: es una disciplina para gestionar efectos secundarios. O realizas una acción (comando) o pides un valor (consulta).

CONTRAS #

Tests Frágiles: tiende a crear tests que se rompen fácilmente porque suelen estar muy acoplados al código de producción.
Refactoring Difícil: por la misma razón, tener tests acoplados hace que el refactoring continuo sea lento y complicado.

Inside-out: Escuela de Chicago #

Un enfoque informal, exploratorio, basado en estado. Empiezas desde el interior de la aplicación (normalmente el dominio) y vas hacia afuera, hacia las APIs.

PROS #

Red de Seguridad Fuerte: produce tests desacoplados de la implementación. Puedes cambiar el software sin miedo a romperlo, ideal para el refactoring continuo.
Alta Cohesión: a medida que los tests se vuelven más generales, el código de producción se vuelve más específico. Alta cohesión lleva a bajo acoplamiento, lo que mejora extensibilidad, mantenibilidad y testeabilidad.
Minimiza Dobles de Test: construir de adentro hacia afuera requiere menos dobles porque construyes sobre tests previamente escritos. Esto ayuda a tener tests menos frágiles.

CONTRAS #

YAGNI: a menudo sobre-diseña soluciones, con código que realmente no se necesita (¡o ni siquiera se usa!) al final.

Londres y Chicago funcionan mejor juntas #

No se trata de elegir uno u otro. Se trata de entender tu contexto y optimizar las cualidades que lo necesitan. London y Chicago tienen sus pros y contras. El mejor enfoque para TDD es integrar ambas escuelas.

Referencias #

Test-Driven (Development)

2021-08-01T00:00:00+00:00

La complejidad aquí no está en escribir tests en sí, sino en los hábitos que tenemos que cambiar para crear software que sea fácil de testear.

La raíz del problema #

Sin experiencia sólida en testing, los desarrolladores lo pasan mal al intentar aplicar tests en su trabajo diario. No es solo por la complejidad del tema, sino porque están acostumbrados a escribir código difícil de testear.

Escribir tests para software que ya funciona (sobre todo cuando se hizo sin pensar en testing) se siente aburrido y casi inútil. Viene acompañado de falta de motivación, culpando al sujeto equivocado: “los tests me hacen ir más lento”.

En un contexto de dominio, si una pieza de lógica de software es difícil de testear, el problema no es el test, sino el código que no estaba bien escrito.

Ya hay cientos de tutoriales, libros y documentación sobre testing. Aquí comparto mi experiencia y cómo aplico esta filosofía en mi trabajo diario.

Test-Driven se basa en esta simple regla #

En lugar de: diseñar código -> desarrollar código -> escribir tests.

Se trata de: escribir test automatizado que falla -> ejecutar test que falla -> desarrollar código para hacer pasar el test -> ejecutar test -> repetir.

La idea de guiar tu código con tests depende del nivel de abstracción de lo que estés escribiendo. No quieres acoplar mal los tests con el código testeado. Quieres testear el comportamiento de tu lógica.

TDD se basa en un bucle de pequeños pasos que te ayuda a encontrar patrones y guiar tu diseño de software con refactorizaciones constantes. Es la mejor opción si quieres asegurar el comportamiento esperado de todos los caminos posibles de tu lógica.

Lo bonito es que no necesitas conocer el algoritmo completo desde el principio. Vas descubriendo cómo debería ser tu lógica expresando la implementación deseada, paso a paso, en tests automatizados.

Escribir tests al mismo tiempo que escribes el código te obliga a escribir mejor software. Porque quieres que sea fácil de testear, y eso lleva a mayor calidad.

Ya escribí otro post sobre la relación entre calidad y testing del software: El Arte del Testing: donde el diseño se encuentra con la calidad.

Mejora tus habilidades de Test-Driven #

La mejor manera de aprender Test-Driven es haciendo katas de software. Pruébalas solo y con otros. Ambas son igualmente importantes.

Solo: para desafiar tu yo interior sin ninguna distracción excepto tú mismo.
Con otros: el pair-programming es esencial en nuestro trabajo. Las katas son las mejores herramientas para entrenar nuestras habilidades de comunicación y aprender juntos unos de otros.

¿Qué es una Code Kata? #

Los desarrolladores no practicamos lo suficiente. La mayor parte de nuestro aprendizaje ocurre en el trabajo, y ahí es donde cometemos la mayoría de nuestros errores.

Otras profesiones creativas sí practican: los músicos tocan piezas técnicas, los poetas reescriben obras constantemente. En karate, un estudiante dedica la mayor parte del tiempo a aprender y perfeccionar movimientos básicos. Esas son las katas.

¿Cuál es el objetivo de una kata? ¿Qué deberíamos tener al final? #

Las katas existen para que los desarrolladores obtengamos los mismos beneficios que practicar en otras profesiones. Son ejercicios simples y artificiales que permiten experimentar y aprender sin la presión de producción.

No hay respuestas correctas o incorrectas en ninguna kata de software: el beneficio viene del proceso, no del resultado.

Consejos #

Cuando resuelvas una kata, vuelve a intentarla en unas semanas o meses.
Explora nuevas soluciones. Sé creativo y no te apresures.
En grupo, no es una competición para ver quién logra más.
El foco debe estar en el proceso, nunca en el resultado.
El verdadero valor de cualquier kata son los aprendizajes que obtendréis después de hablar y compartir experiencias.

Puedes encontrar muchas katas en Internet. Por ejemplo:

TDD es más un flujo de trabajo que un diseño #

“TDD es una herramienta de diseño.” Eso es lo que Sandro dijo durante años. Pero ya no. Tras trabajar con diferentes equipos y organizaciones, y observar cómo trabaja él mismo, Sandro cambió de opinión sobre el rol de TDD en el diseño de software.

TDD en pocas palabras; se trata del ritmo.

Especifica lo que quieres.
Hazlo funcionar.
Hazlo mejor.

Kent Beck #

1. Change the code as usual
2. Write a test that only passes after the change
3. Revert to before 1
4. Type the test again (copy/paste is cheating & invalidates the warranty of the exercise)
5. Make it compile by changing the code
6. See it fail
7. Change the code to make it pass
— Kent Beck 🌻 (@KentBeck) July 30, 2021

Imágenes originales de Emmanuel Valverde Ramos.

Nunca Uses array_merge en un Bucle

2020-11-10T00:00:00+00:00

Usar array_merge dentro de un bucle mata el rendimiento. El operador spread te ayudará a mejorar esto aplanando el array.

Aplanando un array de un nivel #

He visto a gente usar array_merge dentro de un bucle así:

<?php
$lists = [
 [1, 2],
 [3, 4],
 [5, 6],
];
$merged = [];
foreach($lists as $list) {
 $merged = array_merge($merged, $list);
}
// $merged === [1, 2, 3, 4, 5, 6];

Esto es mala práctica porque destroza el rendimiento de memoria. Mejor usa el operador spread (disponible desde PHP 5.6):

<?php
$lists = [
 [1, 2],
 [3, 4],
 [5, 6],
];
$merged = array_merge(...$lists);
// === [1, 2, 3, 4, 5, 6];

Desempaquetando un array asociativo #

¿Y si tuvieras un array asociativo como este?

<?php
$lists = [
 'key-1' => [1, 2],
 'key-2' => [3, 4],
 'key-3' => [5, 6],
];

En ese caso, necesitarás desempaquetar sus valores:

<?php
$merged = array_merge(...array_values($lists));
// === [1, 2, 3, 4, 5, 6];

En programación funcional, esto se conoce como aplanar una lista. Sin bucles ni problemas de rendimiento.

Aplanando un array multinivel #

¿Y si quisieras aplanar un array multinivel como este?

<?php
$lists = [[1], 2, [[3, 4], 5], [[[]]], [[[6]]], 7, 8, []];

¿O como este, incluso con clave-valores?

<?php
$lists = [
 'key-1' => [
 1,
 [2],
 'key-2' => [
 3,
 [
 'key-3' => [4, 5],
 ],
 ],
 ],
 6,
 'key-4' => [7, 8],
];

Para estos casos, puedes usar la librería estándar de PHP:

<?php
$merged = iterator_to_array(
 new RecursiveIteratorIterator(
 new RecursiveArrayIterator($lists)
 ),
 $use_keys = false
);
// $merged === [1, 2, 3, 4, 5, 6, 7, 8];

Qué enfoque de aplanado usar #

Normalmente, saber aplanar un array de dos niveles suele ser suficiente:

<?php
$flattenList = array_merge(...array_values($lists));

Para casos más complejos, la librería estándar de PHP te saca del apuro.

Referencias #

Testeando Código Legacy de Forma Efectiva

2020-08-17T00:00:00+00:00

Estos tests también se conocen como tests de caracterización.

Un test de caracterización describe el comportamiento real de una pieza de software existente, y por lo tanto protege el comportamiento existente del código legacy contra cambios no intencionados mediante testing automatizado. Este término fue acuñado por Michael Feathers.

Permiten y proporcionan una red de seguridad para extender y refactorizar código que no tiene tests adecuados. Se puede escribir un test que afirme que la salida del código legacy coincide con el resultado observado para las entradas dadas.

¿Cómo empezar? #

Estos son mis aprendizajes un año después de leer Working Effectively with Legacy Code y aplicarlo a los diferentes proyectos en los que he trabajado desde entonces.

1. ¿Qué quieres testear? #

Averigua las aserciones. Crea un archivo de test para tu clase, y un método de test para la función que quieres testear. Pista:

Si tienes el siguiente método applySomeLogic(): ReturnType,
el test que podrías escribir es test_apply_some_logic(): void.

final class MyBusinessLogic
{
 private DependencyInterface dependencyInterface;
 private ConcreteDependency concrete;

 public function __construct(
 DependencyInterface dependencyInterface,
 ConcreteDependency concrete
 ) {
 this.dependencyInterface = dependencyInterface;
 this.concrete = concrete;
 }

 public function applySomeLogic(Input input): ReturnType
 {
 // caja negra responsable de crear un ReturnType
 // basado en el Input dado
 return returnType;
 }
}

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 // Quiero afirmar que "aplicando alguna lógica"
 // de MyBusinessLogic con el Input dado
 // recibiré un ReturnType concreto con un
 // cierto valor como su propiedad. Algo como:

 returnType = myBusinessLogic.applySomeLogic(input);
 assertEquals('expected', returnType.getProperty());
 }
}

2. Instancia la clase concreta/final que quieres testear. #

No mockees tus clases concretas. Especialmente tu dominio de negocio. Mockea solo interfaces. De lo contrario, puedes estar ocultando bugs sin querer (¡con tests verdes/pasando!). Trata tus clases de dominio de negocio como finales.

O mockea la interfaz o instancia una clase anónima si quieres crear un Stub:

Los Stubs proporcionan respuestas a llamadas hechas durante el test, normalmente sin responder a nada fuera de lo programado para el test.

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface.class),
 new ConcreteDependency(/* ... */)
 );
 // O
 myBusinessLogic = new MyBusinessLogic(
 new FakeDependency(),
 new ConcreteDependency(/* ... */)
 );
 // ...
 }
}

Donde FakeDependency es una implementación concreta de DependencyInterface con “datos/implementación falsos” ya preparados que solo es útil para propósitos de testing.

3. Llama al método de esa clase proporcionando la entrada deseada. #

La salida será determinada por el estado inicial de la clase de lógica de negocio que queremos testear MÁS los argumentos de entrada que estamos usando.

input = new Input(/* ... */);
returnType = myBusinessLogic.applySomeLogic(input);

4. Afirma la salida con el valor esperado. #

Del paso 1 necesitas saber qué quieres. Aplica la(s) aserción(es) ahora.

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface::class),
 new ConcreteDependency(/* ... */)
 );

 input = new Input(/* ... */);
 returnType = myBusinessLogic.applySomeLogic(input);
 assertEquals('expected', returnType.getProperty());
 }
}

5. Puede que quieras afirmar diferentes valores esperados. #

Puedes proporcionar fácilmente diferentes argumentos a tu lógica de negocio ya sea a través de la construcción de la lógica o diferentes argumentos dados. Para hacerlo, usa la anotación @dataProvider. El método “dataProvider” debe ser público y devolver cualquier iterable.

final class MyBusinessLogicTest extends TestCase
{
 /** @dataProvider providerApplySomeLogic */
 public function test_apply_some_logic(
 array concreteMapping,
 string argInput,
 string expectedValue
 ): void {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface.class),
 new ConcreteDependency(concreteMapping),
 /* ... */
 );

 input = new Input(argInput, /* ... */);

 actual = myBusinessLogic.applySomeLogic(input);
 assertEquals($expectedValue, actual.getProperty());
 }

 public function providerApplySomeLogic(): Generator
 {
 yield [
 'concreteMapping' => ['key' => 'value'],
 'argInput' => 'something',
 'expectedValue' => 'expected-value-A',
 ];

 yield [
 'concreteMapping' => ['key2' => 'value2'],
 'argInput' => 'something-else',
 'expectedValue' => 'expected-value-B',
 ];
 }
}

Por último: limpia lo que hiciste. #

Sí, limpia los tests. Merecen estar tan limpios como tu código de producción. De lo contrario, se pudrirán con el tiempo y ¡permanecerán sucios para tus compañeros y tu yo futuro!

Por ejemplo, puedes aplicar el refactoring extract method para mover los detalles de implementación (de la creación de los diferentes objetos) y mantener el mismo nivel de abstracción mientras lees el código del test.

myBusinessLogic = this.createBusinessLogic(concreteMapping);
input = this.createInput(argInput);
actual = myBusinessLogic.applySomeLogic(input);
assertEquals(expectedValue, actual.getProperty());

Por supuesto, todo depende del contexto. ¿Realmente tiene sentido extraer a un método privado createBusinessLogic() o incluso createInput()? Bueno, eso depende de ti. Depende del número de líneas y, lo más importante, del nivel de abstracción que pertenece a ese contexto.

Solo recuerda: mantén tus métodos pequeños.

Ahora puedes refactorizar el código de producción que cubriste con tests sin ese miedo a romperlo.

Todo junto #

El código legacy es código sin tests #

Por supuesto, hay mucho más que aprender sobre testing y trabajo con código legacy. De hecho, especialmente cuando tratamos con código legacy, encontrarás situaciones donde el código está acoplado de alguna manera que podrías querer mockear tus clases concretas porque no hay interfaz (todavía) para ello.

Este libro te presenta muchas técnicas sobre cuándo, por qué, dónde y cómo puedes aplicar estos cambios.

Cuando trabajas con código necesitas retroalimentación. La retroalimentación automatizada es la mejor. Por lo tanto, esto es lo primero que necesitas hacer: escribir los tests.

Primero, añade tests, luego haz tus cambios. #

Cambia la menor cantidad de código posible para poner los tests en su lugar con la receta: #

Identifica “puntos de cambio” para romper las dependencias de tu código.
Rompe las dependencias.
Escribe los tests.
Haz tus cambios.
Refactoriza.

Advanced Web Application Architecture

2020-08-16T00:00:00+00:00

Este libro te ayuda a poner en forma tus aplicaciones web. Trae muchas técnicas para desacoplar tu código de la infraestructura (el framework, la base de datos, etc.).

La Parte 1 presenta patrones de diseño para separar código de negocio e infraestructura. La Parte 2 muestra cómo estos patrones encajan con conceptos arquitectónicos como capas, puertos y adaptadores (arquitectura Hexagonal). El libro cierra con estrategias de testing y decisiones de diseño.

Lo que aprenderás #

Separar código mezclado en código de negocio e infraestructura usando patrones.
Dividir tu código en capas con una distinción clara entre puertos y adaptadores.
Testear aplicaciones desacopladas.

Compra el libro: https://leanpub.com/web-application-architecture

Patrones de diseño para modernizar código legacy #

El Arte del Refactoring

2020-06-28T00:00:00+00:00

Si ves algo, en el ámbito de tu tarea actual, que puede mejorarse fácilmente, mejóralo. Y si tienes alguna pregunta al respecto, pregunta.

¿Qué es el refactoring? #

Refactoring significa mejorar tu código. Puede ser renombrar una variable, extraer líneas en un método privado, o separar responsabilidades de una clase en varias.

El refactoring demuestra que te importa lo que haces como profesional. Es un tema controvertido desde hace tiempo. Pero eso no debería frenarnos de mejorar la calidad del sistema.

¿Cuándo y cómo refactorizar? #

Siempre. Dentro del ámbito de tu tarea actual, a menos que sea una tarea planificada específicamente para refactoring de arquitectura.

El refactoring debería ser parte del trabajo diario, no una tarea separada.

No necesitamos pedir permiso para refactorizar. ¿Acaso pedimos permiso para hacer nuestro mejor trabajo?

Para refactorizar bien, la intención debe estar clara. ¿Qué queremos lograr y cómo? El pair programming (o incluso el “pair thinking”) ayuda porque sincroniza dos cerebros y fomenta mejor comprensión mutua.

Refactorizar de forma colaborativa es fundamental en equipo. No debería ser tabú. Al contrario: ayuda a unificar objetivos y dirección de calidad del código.

Algunos consejos sobre el “cómo” #

Buscamos mejora continua, pero…

Si tus cambios generan más ruido que ayuda, para. Piensa si valen la pena en el estado actual del sistema. Quizás no es el momento. Quizás estás contaminando el diff con cambios fuera del ámbito. O quizás es demasiado grande para tu tarea actual. En ese caso, mejor crear una tarea de seguimiento.
Si el refactoring es necesario antes de empezar tu tarea, hazlo primero.

Refactorizamos para aumentar productividad: código más legible es código más fácil de entender.

Testing #

Necesitas un buen conjunto de tests cubriendo la lógica que vas a cambiar. Sin tests, refactorizar es arriesgado. Por lo general, cuanto más fácil es testear algo, más fácil es reemplazarlo o eliminarlo.

Puedes leer más sobre cómo el testing está relacionado con la calidad aquí.

¿Por qué hacerlo? #

¿No querrías un sistema mejor con el tiempo?

El software no es como el vino: no mejora solo. Si quieres un sistema mejor, tienes que trabajar para conseguirlo.

Trabajando con código legado

2019-07-01T00:00:00+00:00

¿Qué es código legacy? #

El código legacy es simplemente código sin tests.

Beneficios de los tests #

El comportamiento es clave para entender los beneficios del testing:

El comportamiento es lo más importante del software. Los usuarios dependen de él. Les gusta que añadamos funcionalidad (si es lo que querían), pero si cambiamos o rompemos comportamiento del que dependen, pierden la confianza.

Cómo implementar tests en bases de código legacy #

Para cambiar código necesitas tests. Pero para añadir tests muchas veces tienes que cambiar código.

El enfoque sugerido:

Identificar puntos de cambio.
Encontrar puntos de test.
Romper dependencias.
Escribir tests.
Hacer cambios y refactorizar.

Un término útil es “costura” (seam): un lugar donde puedes cambiar el comportamiento sin editar ese código directamente. Como la costura en la ropa, donde dos partes se unen. En software, estos lugares suelen tener interfaces bien definidas. Puedes aprovecharlos para cambiar implementaciones con inyección de dependencias o mocking en tests.

El Programador Pragmático

2016-10-01T00:00:00+00:00

Aprendizajes #

No te repitas.
La mentalidad importa tanto como el conocimiento.
El buen código es más fácil de cambiar que el mal diseño.
Elige buenas herramientas y domínalas.

No Te Repitas (DRY) #

Cada pieza de conocimiento debe tener una única representación clara dentro del sistema.
DRY trata sobre la duplicación de conocimiento, de intención. Es expresar lo mismo en dos lugares, quizás de formas diferentes.

La mentalidad importa tanto como el conocimiento #

Aspectos clave:

Asume la responsabilidad de tu trabajo. Sin excusas ni culpas cuando algo sale mal.
Escribe software “suficientemente bueno”. No pierdas tiempo perfeccionando lo que ya funciona para el producto.
No ignores la deuda técnica. Los autores usan la analogía de las ventanas rotas:

No dejes “ventanas rotas” (malos diseños, decisiones incorrectas o código pobre) sin reparar. Arregla cada una cuando la descubras. Si no hay tiempo, al menos tápalas. Comenta el código problemático, muestra un mensaje de “No Implementado” o usa datos ficticios temporalmente.

Código Limpio

2016-05-01T00:00:00+00:00

El código malo puede funcionar, pero si no está limpio, puede hundir a una empresa. Cada año se pierden horas y recursos por culpa de código mal escrito. No tiene por qué ser así.

Resumen #

Capítulo 1: ¿Qué es el código limpio? #

El código se puede medir como “bueno” o “malo” en una revisión, o por cuánto tiempo tardas en explicarlo.
El código limpio es elegante, eficiente, legible, simple, sin duplicaciones y bien escrito.
Tu código debe añadir valor al negocio.
Al abrir un archivo fuente, el código limpio transmite calidad y se entiende fácilmente.
Haz tu código limpio y legible para que cualquiera pueda entenderlo rápido. No hagas perder tiempo a otros.

Capítulo 2: Nombres significativos #

Los nombres de las clases, variables y métodos deben ser significativos e indicar claramente lo que hace un método o lo que es un atributo.
Crea nombres pronunciables para facilitar la comunicación.
Evita acrónimos y nombres confusos, que pueden llevar a conclusiones erróneas a cualquiera que lea el código.
Usa nombres que reflejen el dominio del sistema, el contexto y los problemas que deben resolverse.

Capítulo 3: Funciones #

Los métodos deben ser fáciles de leer y entender.
Deben transmitir su intención.
Deben ser pequeños: hasta 20 líneas.
Deben hacer solo una cosa.
Usa nombres que digan claramente qué hace el método.
El número ideal de parámetros es cero, luego uno, luego dos.
Evita tres parámetros; si los usas, justifícalo.
Un Boolean como parámetro indica que el método hace más de una cosa.
Evita la duplicación.

Capítulo 4: Comentarios #

Cuando necesitas comentarios suele ser porque el código es malo.
Si piensas escribir un comentario, mejor refactoriza el código.
Los comentarios no salvan el código malo.
El código debe explicarse por sí mismo.
A veces los comentarios son útiles en ciertos lugares específicos.
No expliques el código con comentarios. Usa nombres descriptivos de variables y métodos.
Los comentarios pueden destacar la importancia de ciertos puntos.
No escribas comentarios redundantes, inútiles o falsos.
Para saber quién cambió qué y por qué, usa control de versiones.
No comentes código sin usar. Elimínalo.

Capítulo 5: Formato #

El formato es una forma de comunicación entre desarrolladores.
El código desordenado es difícil de leer.
La legibilidad afecta a todos los cambios futuros.
Las clases pequeñas son más fáciles de entender.
Pon un límite de caracteres por línea (por ejemplo, 120).
Mantén los conceptos relacionados cerca verticalmente para crear un flujo natural.
Usa espacios entre operadores, parámetros y comas.

Capítulo 6: Objetos y estructuras de datos #

Sigue la Ley de Demeter:
- Cada unidad debe tener solo conocimiento limitado sobre otras unidades: solo unidades “estrechamente” relacionadas con la unidad actual.
- Cada unidad solo debe hablar con sus amigos; no hables con extraños.
- Solo habla con tus amigos inmediatos.
No hagas objetos tontos.
Los objetos ocultan la abstracción de datos y exponen métodos que operan los datos.
Las estructuras de datos exponen sus datos y no tienen métodos significativos.

Capítulo 7: Manejo de errores #

Planifica el manejo de errores con cuidado.
Cuando algo falla, hay que hacer que el sistema responda correctamente.
Lanza excepciones en lugar de ocultarlas.
Crea mensajes de error informativos: qué falló, dónde y, si es posible, por qué.
Separa las reglas de negocio del manejo de errores.
Evita devolver NULL; devuelve un objeto vacío.
Evita pasar NULL a los métodos; puede causar NullPointerExceptions.

Capítulo 8: Límites #

Al usar código de terceros, encapsula las APIs para no exponer objetos externos.
Haz tests de las APIs de terceros.
Estudia la documentación y prueba la API antes de usarla.
Conoce bien las características que vas a usar.

Capítulo 9: Tests unitarios #

Asegúrate de que cada pieza de código hace lo que esperas.
Sigue las leyes de TDD:
- No escribas código sin tener primero un test que falle.
- No escribas más tests de los necesarios para fallar.
- No escribas más código del necesario para pasar el test.
Mantén tus tests limpios.
Los tests evolucionan junto con el código.
Código sucio = tests difíciles de mantener.
Usa la regla F.I.R.S.T:
- Fast: ejecución rápida.
- Independent: independientes entre sí.
- Repeatable: repetibles en cualquier entorno.
- Self-validating: auto-validantes.
- Timely: escritos a tiempo.
Los tests son tan importantes como el código de producción.

Capítulo 10: Clases #

Organiza las clases así:
- Constantes públicas estáticas.
- Variables privadas estáticas.
- Variables de instancia privadas.
- Luego los métodos.
El nombre de la clase debe reflejar su responsabilidad.
Cada clase debe tener una sola responsabilidad: una razón para cambiar.
Intenta describir la clase en una frase breve.
Los métodos deben ser pequeños y con una sola responsabilidad.

Esta entrevista se basa en el libro de Uncle Bob “Código Limpio”. Repasan algunas guías que te ayudarán a ser mejor programador y exploran cómo los libros y tendencias actuales están moldeando el mundo del software.