Chemaclass - clean-code

Aprendiendo Concurrencia en Golang

2024-04-02T00:00:00+00:00

Quería aprender un nuevo lenguaje, así que después de probar algunos, terminé con Golang como uno de mis favoritos por su simplicidad y capacidades. Tiene características que no había usado en años, como multithreading y concurrencia.

Golang (o Go) soporta concurrencia mediante hilos ligeros llamados goroutines. Son diferentes del multithreading tradicional de Java, donde hay que manejar sincronización y coordinación para gestionar recursos compartidos de forma segura. Las goroutines son ligeras, las gestiona el runtime de Go, y son más baratas de crear y manejar.

El paralelismo es hacer varias cosas simultáneamente. La concurrencia es lidiar con varias cosas a la vez. En ambos casos, no conocemos el orden de ejecución: no sabemos qué pasará primero ni qué terminará antes.

Imagina que cocinas: preparas una sopa, una ensalada y una tortilla. Eres una sola persona, pero preparas varios platos. Podrías terminar primero la ensalada, la sopa o la tortilla… no hay garantía. Esto es concurrencia: lidias con varias cosas a la vez. Cuando tu pareja viene a ayudarte, eso ya es paralelismo.

Recuerdo haber construido un juego similar en Java cuando aprendía multithreading hace diez años. Aprovecho esta oportunidad para hacerlo de nuevo con Go moderno.

Construi un juego de terminal que simula una carrera de caballos. Cada caballo es una goroutine que corre en una matriz bidimensional compartida. Cuando un caballo llega al final, notifica al canal compartido con los demas caballos (que corren en diferentes procesos) y todos se detienen, mostrando al ganador.

Separé el código en cuatro áreas para ayudar a visualizarlo:

Punto de entrada
Generando el tablero
Renderizando el juego
Moviendo los caballos

Punto de entrada #

La estructura Horse representa cada Caballo en la carrera. El juego consiste en una lista de líneas, en las cuales cada Caballo está corriendo.

type Horse struct {
 Name string // El nombre del caballo
 Line int // La línea de competición
}

func (h Horse) Letter() string {
 return fmt.Sprintf("%c", h.Name[0])
}

func (h Horse) Equals(other *Horse) bool {
 return other != nil &&
 h.Line == other.Line &&
 h.Name == other.Name
}

func (h Horse) String() string {
 return fmt.Sprintf("%s (line:%d)", h.Name, h.Line)
}

Puedes generar un nuevo proceso usando la palabra clave go al invocar cualquier función. En este juego, esto se usa 1) para renderizar el juego RenderGame() y 2) para el movimiento de cada caballo startRuningHorseInLine(). El objetivo es mantener la “renderización” y la “lógica de movimiento” trabajando en paralelo.

func main() {
 const lines, lineLength = 12, 30

 board := NewRaceBoard(lines, lineLength)
 go RenderGame(board)

 winnerChan := make(chan Horse)
 for line := range board {
 // cada caballo será movido en diferentes procesos
 go startRunningHorseInLine(board, line, winnerChan)
 }

 // esperar hasta que un caballo llegue al final
 winner := <-winnerChan
 // renderizar una última vez para asegurar el último estado del tablero
 RenderRaceBoard(board, &winner)

 fmt.Println("Race finished!")
 fmt.Printf("# Winner: %s\n", winner)
}

Generando el tablero #

El tablero de carreras es una matriz bidimensional de punteros a Horses. Cada línea “contiene” un solo Caballo: solo un puntero apunta a un Caballo real, el resto son nil. Al generar el Tablero, creamos un Caballo en la primera posición de cada línea.

func NewRaceBoard(lines, lineLength int) [][]*Horse {
 board := make([][]*Horse, lines)
 for line := range board {
 board[line] = make([]*Horse, lineLength)
 board[line][0] = &Horse{
 Name: generateHorseName(),
 Line: line,
 }
 }
 return board
}

Los nombres se generan aleatoriamente usando HorseNames.

var HorseNames = [][2]string{
 {"Alloping", "Giggles"},
 {"A-lot", "Gallop"},
 {"BoJack", "Jack"},
 {"Baroness", "Belle"},
 // ...
}

func generateHorseName() string {
 name := HorseNames[rand.Intn(len(HorseNames))][0]
 surname := HorseNames[rand.Intn(len(HorseNames))][1]

 return name + " " + surname
}

Renderizando el juego #

Los métodos RenderGame(), renderRaceBoard(), renderRaceLine() y renderRacePosition() están separados para que cada uno tenga una responsabilidad clara: renderizar su sujeto correspondiente.

RenderGame() se está ejecutando en otro proceso usando go.

func RenderGame(board [][]*Horse) {
 for {
 time.Sleep(renderDelay * time.Millisecond)
 RenderRaceBoard(board, nil)
 }
}

func RenderRaceBoard(board [][]*Horse, winner *Horse) {
 // usar un "buffer de string" para guardar todo el estado del tablero
 // para que luego podamos usar una sola llamada IO para renderizarlo
 var buffer bytes.Buffer
 buffer.WriteString("\n")
 for line := range board {
 renderRaceLine(board, line, &buffer, winner)
 }
 clearScreen()
 fmt.Println(buffer.String())
}

func clearScreen() {
 cmd := exec.Command("clear")
 cmd.Stdout = os.Stdout
 cmd.Run()
}

func renderRaceLine(
 board [][]*Horse,
 line int,
 buffer *bytes.Buffer,
 winner *Horse,
) {
 buffer.WriteString(fmt.Sprintf(" %.2d | ", line))
 var current Horse
 for col := range board[line] {
 h := renderRacePosition(board, line, col, buffer, winner)
 if h != nil {
 current = *h
 }
 }
 buffer.WriteString(fmt.Sprintf("| %s", current.Name))

 if current.Equals(winner) {
 buffer.WriteString(" [Won!]")
 }
 buffer.WriteString("\n")
}

func renderRacePosition(
 board [][]*Horse,
 line, col int,
 buffer *bytes.Buffer,
 winner *Horse,
) *Horse {
 if board[line][col] == nil {
 buffer.WriteString(" ")
 return nil
 }

 current := board[line][col]

 if current.Equals(winner) {
 removeChars(buffer, col+1)
 for range board[line] {
 buffer.WriteString("-")
 }
 }

 buffer.WriteString(current.Letter())

 return current
}

Moviendo los caballos #

En main(...), el winnerChan es un canal compartido que usará el primer Caballo que llegue a la última posición de su línea.

Cada Caballo ejecuta un bucle hasta llegar al final de la línea o recibir (vía winnerChan) el mensaje de que otro Caballo ya ganó. Hasta entonces, cada caballo se mueve de forma independiente, durmiendo milisegundos aleatorios antes de avanzar a la siguiente posición.

startRuningHorseInLine() se ejecuta en otro proceso usando go.

func main() {
 //...
 winnerChan := make(chan Horse)
 for line := range board {
 // cada caballo será movido en diferentes procesos
 go startHorseRunning(board, line, winnerChan)
 }
 // esperar hasta que un caballo llegue al final
 winner := <-winnerChan
 //...
}

func startRunningHorseInLine(board [][]*Horse, line int, winnerChan chan Horse) {
 for {
 select {
 case <-winnerChan: // verificar si otro caballo terminó
 return // en tal caso, entonces detener el bucle for
 default:
 time.Sleep(time.Millisecond * time.Duration(rand.Intn(maxSleepDelay)))
 moveHorseOnePos(board, line, winnerChan)
 }
 }
}

func moveHorseOnePos(board [][]*Horse, line int, winnerChan chan Horse) {
 cols := len(board[line])
 for col := cols - 1; col > 0; col-- {
 if board[line][col-1] == nil {
 continue
 }
 // aquí identificamos que hay un caballo en
 // la siguiente columna, así que lo movemos a la
 // columna actual, y ponemos `nil` en la otra
 board[line][col] = board[line][col-1]
 board[line][col-1] = nil

 if col+1 == cols {
 winnerChan <- *board[line][col]
 }
 break
 }
}

Código fuente #

El código de este post es una versión simplificada. Si quieres ver el código completo funcionando, está aquí: Chemaclass/go-horse-racing.

Pair Programming Efectivo

2024-03-28T00:00:00+00:00

¿Qué es el pair programming? Dos personas trabajando juntas en el mismo problema, al mismo tiempo.

No se trata de que una persona muestre sus habilidades frente a otra, ni de que una persona tenga miedo de cometer errores debido al síndrome del impostor.

Cada persona tendrá un rol:

Navegador: prestará atención al panorama general; ej: arquitectura, relación entre colaboradores, diseño de objetos, etc.
Conductor: prestará atención a los pequeños detalles; ej: naming, convenciones de código, sintaxis de escritura, diseño de objetos, etc.

La pareja podría, y debería, intercambiar roles ocasionalmente; ej: cada X commits pusheados, cada 10 min,… depende de ellos.

El pair programming no debería considerarse una práctica solo para “seniors” hacia juniors, sino independientemente del nivel de experiencia de los miembros del equipo.

Se trata del flujo de colaboración, la comunicación de calidad, la ausencia de sentirse juzgado y la idea de dar la bienvenida a la vulnerabilidad con tus compañeros, sabiendo que te apoyarán y ayudarán.

Se trata de desafiarse constantemente mutuamente, buscando la solución más pragmática mientras se mantiene simple. Siempre buscando retroalimentación rápida al hablar entre ustedes, pero también sobre la solución que acordaron implementar y su dirección.

Se trata del bucle de retroalimentación corto, rápido e inmediato mientras hablas con tu compañero, quien revisa tu código sobre la marcha. Puedes guiar como navegador o ayudar al conductor a validar sus ideas en un panorama más amplio.

Se trata de la atmósfera constante de compartir conocimiento por defecto, reduciendo bus-factors y áreas de conocimiento aislado al máximo. Aumentando el enfoque al tener dos mentes trabajando en la misma tarea simultáneamente.

Se trata de cohesión de equipo y afilar el sentimiento de que pertenecemos. Cuando entendemos las fortalezas y debilidades de cada uno, nos daremos cuenta de cuánto podemos ayudarnos a crecer mutuamente.

¿Cómo puedes practicar pair programming? #

El pair programming puede hacerse de diferentes maneras:

Puedes empezar y terminar una tarea con pairing. Puedes limitarlo a 30, 60, 90 minutos. De cualquier manera, se recomienda tener pausas en el medio - Pomodoro.
Puedes empezar la tarea juntos y parar cuando uno de tus compañeros se sienta lo suficientemente confiado para continuar solo.

Depende del equipo, y de la tarea en contexto, decidir cuándo y cómo aplicar pairing para sacar lo mejor de ello.

Esto no significa que debas trabajar constantemente “sin importar qué” en pareja. No se trata de crear reglas; por el contrario, se trata de abrazar esta práctica hasta el punto de que te sientas confiado para elegir cuándo y cómo usarla para sacar lo mejor de ella.

El pair programming podría convertirse en una de las mejores herramientas en la caja de herramientas de tu equipo para las interacciones diarias. No porque lo hayas leído en algún lugar, sino por los beneficios que tú y tu equipo encontrarán.

Patrones Comunes #

Diferentes estrategias para pairing efectivo #

Driver-Navigator: Una persona está conduciendo el código (con el teclado), enfocándose en el aspecto de detalle de la tarea en sí. La otra es navegadora (sin teclado), teniendo una imagen más abstracta de la tarea en mente.
Ping-Pong: Cambio frecuente de roles driver-navigator en pequeñas interacciones, ej: cada N minutos, cada N commits, etc.
Backseat driver: El navegador se involucra activamente con el conductor.
Tourist guide: El navegador aprende pasivamente con el conductor.

Anti-patrones mientras haces pairing #

The silent partner: El navegador no participa, está en silencio.
The solo act: El conductor ignora todas las aportaciones del navegador.
Distracted pair: La pareja no se enfoca en el problema a resolver.
The Dictator: Una persona está diciendo qué hacer, ignorando las aportaciones del otro.
Philosophical pair: La pareja está haciendo bikeshedding en temas irrelevantes.
The code war: La pareja no llega a un acuerdo y comienza una guerra innecesaria, que desperdicia tiempo y esfuerzo.

¿Quieres más? Mira esto: Learning Through KATAS

La conclusión #

El pairing no es una regla que imponer, es una herramienta a la que recurrir. Úsalo cuando la tarea es compleja, el conocimiento está aislado o lo que está en juego es importante. Sáltalo cuando el trabajo es trivial. El objetivo nunca es “hacer siempre pairing”, es mejor software y un equipo más fuerte. Elige una tarea real esta semana, hazla en pareja e intercambia roles a menudo. Los beneficios aparecen más rápido de lo que esperas.

Gran Ingeniería

2023-12-30T00:00:00+00:00

Programar no es solo otro trabajo. Escribir software puede ser realmente divertido y, aún más, ¡puede ser tu hobby personal también! Podrías estar enfocado en programar, programar y más programar para subir de nivel tus propias habilidades profesionales.

Eso no tiene nada de malo. La práctica hace al maestro, y programar mucho te ayudará a mejorar tus habilidades de codificación. Pero hay otros aspectos que debes tener en cuenta para crecer como gran ingeniero.

Como ingeniero de software, tu trabajo no es “solo escribir código”, sino usar el software para resolver problemas reales de negocio. Para lograrlo, existen muchas metodologías. Pero en algo hay que estar de acuerdo: necesitas identificar y entender las necesidades de tu cliente para saber qué construir.

Necesitas conocer tu producto, al menos hasta cierto nivel, para diseñar tu software usando un lenguaje cercano al negocio. Esto ayuda a su evolución y calidad, y facilita el mantenimiento presente y futuro.

IT, Software, Producto y Personas están muy conectados. Entender la relación entre estos campos ayuda a cada persona a cumplir mejor sus objetivos.

Un gran trabajo en equipo no es solo la suma de las partes: multiplica el valor creado entre los compañeros. Para eso, saber comunicar bien es clave para generar claridad a cualquier nivel.

Por eso un gran ingeniero conoce de negocio, cliente, producto y programación. Entender estos puntos marca la diferencia entre un ingeniero promedio y uno excelente.

Imagen original de Nicola Ballotta.

¿Cómo Testear Métodos Privados?

2023-10-20T00:00:00+00:00

Esta pregunta me la han hecho muchas veces a lo largo de los años. Aquí recopilo mis ideas al respecto.

Respuesta corta #

Nunca.

Respuesta larga #

Nunca jamás.

¿Y si…? #

Si realmente quieres testear un método privado, considera extraer esa lógica del método privado en una clase separada, y escribe un test unitario para el comportamiento de esa clase.

Para este, me inspiré en el post original de Fran Iglesias.

¿Equipos de QA Dedicados en Software?

2023-05-17T00:00:00+00:00

Esto será controvertido, pero hablemos de la posición de QA. La verdad oculta detrás de la falta de calidad del software y por qué esto debería preocuparte si escribes software.

QA es un rol, no una posición #

Como desarrollador de software, cuando escribes software, eres responsable de la calidad de lo que sea que estés escribiendo. Una tercera persona actuando como QA podría encontrar que tu solución no funciona como se esperaba, pero ¿cómo es posible? Podrías argumentar que podrían encontrar casos límite, pero ¿cómo podría ser posible si el software ya fue testeado previamente?

El objetivo final de un equipo de software es hacer la posición de QA inútil porque no deberían encontrar nada más que software bien funcionando. Pero ¿cómo llegas a ese punto? ¿Cómo podemos asegurar que el software que escribimos funciona como se espera y no hay necesidad de una persona QA en nuestro equipo?

La verdad oculta detrás de la falta de calidad del software #

Desafortunadamente, en nuestra industria del software, la demanda de proyectos “rápidos, rápidos y sucios” terminó en MVPs pobremente desarrollados simplemente aplicando parches y código sobre código con solo testing manual comprobando caminos felices, a veces incluso ignorando casos límite.

“La fecha límite es en una semana, ¡así que mejor termínalo a tiempo!”

No aprendemos la importancia de lo que el testing automatizado puede aportar a nuestro trabajo diario, así que no lo tomamos en serio, y por lo tanto, no lo practicamos lo suficiente. Y, por esa misma razón, porque no lo practicamos, no sabemos cómo realizarlo correctamente. ¡Sí, estoy hablando de escribir tests automatizados que prueban el comportamiento de tu software!

Nuestra incapacidad para escribir código testeable resulta en software que es difícil de testear, y por lo tanto delegamos el testing a terceros trasladando la responsabilidad de la calidad final general del producto o servicio que escribimos.

La práctica hace al maestro #

Debes aprender y aplicar técnicas de testing apropiadas cuando tengan sentido. ¿Cómo y cuándo usar efectivamente dobles de test, preparar tests solitarios o sociables, qué compromisos y razones respaldan tu mente al elegir uno u otro camino hacia tus estrategias de testing?

Eres la última y principal persona responsable de tu conocimiento, así que mejor invierte en ti mismo porque nadie más lo hará por ti.

Mira todo lo que haces como una oportunidad de aprendizaje. Practica y mejora por defecto en todo lo que haces.

Si no sabes cómo empezar, aquí está mi consejo favorito: siempre puedes practicar y mejorar tus habilidades de testing usando katas de código. Lee más sobre este tema aquí.

Buena teoría, pero… ¿para qué molestarse? #

El testing manual es, por supuesto, necesario. Es otra estrategia de testing que no estoy culpando o atacando. Aún podríamos necesitar una persona dedicada a cargo de descubrir qué nuevas funcionalidades queremos construir para satisfacer a nuestros clientes. Pero este post no es sobre esa posición.

Se trata de acortar el bucle de retroalimentación. Si puedes escribir software para que funcione de maneras específicas, ¿no puedes escribir tests automatizados para probar que el software que escribiste se comporta de la manera que esperas?

Si has cubierto con tests automatizados el comportamiento de tu software a cualquier nivel que tenga sentido, ¿qué queda para una persona QA dedicada?

La próxima vez que pienses “Necesitamos una persona QA para testear esto”, intenta el ejercicio de pensar en cambio, “¿Cómo puedo escribir un test automatizado que verifique lo que esperaría si una persona QA estuviera comprobando esto?”

Y así es como cambias la “posición de QA a tiempo completo” en una “mentalidad de rol para todos los que escriben software.”

El código nunca miente y nunca olvida; una vez que está escrito y automatizado en tu pipeline, puedes ejecutarlo en cualquier momento sin coste.

Recipes for Decoupling

2022-11-28T00:00:00+00:00

¿Qué es el acoplamiento y por qué nos perjudica? ¿Cómo desacoplar de forma eficiente? Este libro recopila estrategias para separar tu código de dominio de los detalles de infraestructura. El resultado: un sistema más sano a largo plazo.

Aprenderás a crear reglas de PHPStan desde cero. Además, el libro te guía por múltiples oportunidades de desacoplamiento:

framework web
frameworks cli
validación de formularios
orm y base de datos
framework de testing

Lee más sobre el libro: matthiasnoback.nl/book/recipes-for-decoupling/

Cómpralo aquí: leanpub.com/recipes-for-decoupling

Diferentes Creencias sobre la Calidad del Software

2022-10-08T00:00:00+00:00

Hace poco recibí una pregunta en Twitter que me hizo pensar bastante. Decidí compartir mis reflexiones al respecto.

El tweet que empezó esto #

Primero, algo de contexto: me siento muy bien porque el código base donde trabajo mejora cada vez más, así que tuiteé esto:

“A medida que el software mejora con el tiempo, puedes sentir que lo estás haciendo bien.”

Y entonces recibí una pregunta pidiendo sugerencias:

Así que aquí vamos…

Mi respuesta #

Crear acuerdos #

Lo primero es crear acuerdos sobre qué significa software de calidad para tu equipo y para ti. Esto aclara qué cultura de software quieres construir. Dejar tu empresa debería ser el último recurso.

Antes de pensar en irte, pregúntate:

¿Por qué crees que no puedes mejorar el código base de tu empresa?
¿Qué puedes hacer para reducir la fricción entre tus diferentes creencias sobre calidad?

No existe un código base perfecto. El software es una entidad viva que cambia constantemente. Para mí, software de calidad es el que puede adaptarse al cambio con facilidad.

Una vez que acordéis ese objetivo, hay muchas formas de lograrlo. Mi favorita es mantener una mentalidad agile con dosis de valores, principios y prácticas de Extreme Programming.

El software es sobre personas #

El software no es solo escribir código limpio y sólido. Eso es deseable, claro, pero primero hay que entender por qué lo queremos. El “por qué” se basa en los valores del equipo.

Si no compartís el mismo propósito, el mismo “por qué”, no disfrutaréis trabajando juntos. En ese caso, buscar otra empresa que comparta tus valores es una opción. Pero antes, intenta arreglar el problema de raíz y ayuda a tu equipo a mejorar.

Entendiendo tu por qué #

Primero necesitas entender tu “por qué” a fondo para transmitirlo a tus compañeros. ¿Has hecho todo lo posible para comunicar tu “por qué”?

Algunas ideas: fomentar la programación colaborativa (pair/mob), dar charlas técnicas internas, crear una cultura de compartir conocimiento a diario, cuestionar el statu quo y buscar oportunidades de mejora en todas partes.

Tu trayectoria profesional #

Si después de varios meses intentando estas ideas de verdad ninguna funciona, busca una empresa que comparta tus creencias. Al fin y al cabo, tú eres el principal responsable de tu carrera profesional.

Hilo de twitter original.

Pensamientos adicionales #

Si quieres que algo sea diferente, no esperes a que cambie solo. Intenta cambiarlo; si no funciona, déjalo. Quizás no es tu sitio.

Eso sí, reflexiona si ves este patrón repetirse a menudo (cambiar de empresa demasiado rápido). Si es así, quizás el problema no son las empresas sino tú.

El desarrollo de software no es solo código, es negocio. Hay que encontrar un equilibrio justo entre velocidad, costes y calidad según la situación. A veces conviene asumir algo de deuda técnica para llegar antes al mercado.

Ningún equipo debería tener “baja calidad” como parte de su identidad. Cada equipo tiene expectativas de calidad. La clave está en acordar qué es buena calidad.

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]

El Camino a la Seniority en Software

2022-06-08T00:00:00+00:00

Todos hemos sido desarrolladores junior en algún momento. Esto es fácil de saber porque es al principio de tu carrera. Tus responsabilidades fueron delimitadas por otros compañeros que cuidaban de ti.

En algún momento, después de meses o años, conseguiste tu promoción u otro trabajo, donde ya no eras junior, sino intermedio.

Un intermedio (también conocido como middle) es algo entre junior y senior. Ahora sabes que ya no eres junior, sabes cómo entregar valor pero aún tienes sentimientos encontrados sobre la seniority. Quieres ser senior, pero no sabes cómo. No hay un camino claro para alcanzar este objetivo.

Espera un segundo… ¡en realidad hay dos formas fáciles de conseguir el título de senior! Puedes ser promovido como tal en tu empresa, o puedes empezar una nueva posición como “senior” en otra empresa, ¿fácil no?

Marketing y política #

Desafortunadamente, el nivel de “seniority” está muy contaminado por marketing y política. Primero, ¿qué significa “senior” en este contexto? En todas las empresas donde he trabajado (si no todas) siempre he estado rodeado de personas que afirmaban ser “seniors” cuando en realidad solo a unos pocos los consideraría como tales.

La etiqueta de senior está inflada por la necesidad de las empresas de tener expertos en papel más que en la realidad, y es un problema con el que debemos lidiar y del que debemos hablar.

Seniority generalmente significa más experiencia, pero ¿cómo calculas esto? Es fácil desde el punto de vista de una empresa: más años en la industria. Pero, ¿es realmente relevante el número de años que has estado trabajando en una industria que está en constante cambio y evolución? En realidad, esto no sería un gran problema si tienes los fundamentos del software bien interiorizados, pero curiosamente, he visto estos fundamentos solo en ~10% de los seniors que he conocido a lo largo de muchos años y varias empresas.

El hecho de que hayas estado trabajando durante 10 o más años no significa necesariamente que seas un “senior” con el software. ¿Qué más podemos medir para identificar si realmente mereces este título?

No todo se trata del dinero #

Seamos honestos, los títulos senior están mejor pagados que las posiciones junior o middle. Si tienes la oportunidad de conseguir un salario más alto porque tienes “senior” en tu título de trabajo, bueno, no sería inteligente rechazarlo. Pero, independientemente de la política y el marketing, debemos abordar algunos fundamentos de seniority para entender mejor qué significa la palabra “senior” en este contexto.

No todo se trata del dinero, sino también de las responsabilidades que vienen con la seniority.

Fundamentos de la seniority #

Ser senior en nuestra industria del software no se trata del “número de años de experiencia” sino:

¿Qué tan bien transmites tu conocimiento a otros? Compartir lo que sabes es una tarea esencial para una persona senior.
¿Qué tan bien colaboras con otras personas, incluyendo al PM/PO y a otros equipos? La colaboración es crucial para crear un bucle de retroalimentación constante.
¿Qué tan bien trabajas en conjunto con tus compañeros? El pair-programming fomenta la cohesión del equipo y ayuda a que todos mejoren.
¿Qué tan fuertes son tus habilidades de testing? El testing está ligado a la calidad de tu trabajo, y un senior debería apuntar a un diseño incremental.
¿Qué tan bien entiendes entregar valor constantemente en pequeñas partes? Cuanto antes entregues valor, antes obtendrás retroalimentación sobre ello.
¿Qué tan profundo es tu conocimiento técnico sobre software de calidad y los trade-offs para llegar allí? Principios SOLID, código limpio, TDD, refactoring como parte de tu trabajo diario, bajo acoplamiento, alta cohesión, estructuras de datos apropiadas y elegir la solución correcta (KISS, YAGNI…).
¿Qué tan bien te adaptas y lidias con el cambio? El cambio es inevitable, así que debemos aprender a gestionarlo, especialmente lo que no podemos controlar.
¿Qué tan desarrollado está tu pensamiento emprendedor? Siempre manteniendo los objetivos de la organización en mente.

Como puedes ver, no hay mención de tecnología concreta o años de experiencia. ¿Por qué? Porque la tecnología es solo un “detalle de implementación”, y la experiencia viene de practicar y la actitud, no de dejar pasar el tiempo.

La actitud es importante #

Tenemos dos personas:

A) una persona que trabaja desde hace 15 años, haciendo relativamente lo mismo cada día, y sin preocuparse por sus propias habilidades. Simplemente hace lo que otros le dicen que haga.

B) una persona que trabaja desde hace 5 años, desafiándose a sí misma cada semana, probando diferentes enfoques al lidiar con problemas, y afilando sus propias habilidades constantemente.

¿Puedes ver la diferencia principal? No, no son los 10 años de diferencia de “experiencia” entre ellos, sino su actitud.

Entendemos erróneamente que un año de experiencia debe venir con aprendizaje y conocimiento, así que tendemos a usar el tiempo como medida de seniority. Pero argumento que el “factor actitud” es igual o incluso más importante. He estado rodeado de muchas personas que se llaman a sí mismas seniors con 3, 6, 10 y más años de “experiencia” pero sin actitud, y podías ver claramente este problema a diario.

Necesitas esta combinación para construirte como un desarrollador verdaderamente senior; tiempo, experiencia, y lo más importante: actitud hacia mejorar tus propias habilidades y las de quienes te rodean.

Por dónde empezar #

La seniority no se concede, se practica. No esperas el título, construyes el comportamiento hasta que el título te alcanza. Empieza pequeño, y empieza ahora:

Enseña lo que sabes. Elige una cosa que entiendas y explícasela a alguien esta semana. Si no puedes explicarla, aún no la dominas.
Busca lo incómodo. Ofrécete para la tarea que te queda algo grande. El crecimiento vive en el borde de lo que ya sabes hacer.
Reflexiona con intención. Después de cada proyecto, pregúntate qué harías diferente. Experiencia sin reflexión es solo repetición.

El camino no es una promoción. Es la decisión diaria de mejorarte a ti mismo y a quienes te rodean. Hazlo el tiempo suficiente, y el título se vuelve un trámite.

Mockear o No Mockear

2021-01-11T00:00:00+00:00

Mockear es útil, pero “qué mockear” suele resultar más complicado de lo esperado si no tratas esto con cuidado.

Cómo escapar del infierno del mocking #

¿Qué pasa realmente cuando creamos un mock? ¿Qué tipos hay? ¿Es bueno o malo mockear? Como siempre, depende del contexto. Aquí veremos las situaciones principales: cuándo mockear, cuándo no hacerlo, y sobre todo por qué.

¿Qué pasa cuando mockeas algo? #

Primero, deberíamos definir qué es un mock:

En un test unitario, los objetos mock pueden simular el comportamiento de objetos reales complejos y por lo tanto son útiles cuando es impracticable o imposible incorporar un objeto real en un test unitario.

Mockear tiene sentido en testing unitario. Un test de integración pasa por la implementación real, verificando cómo interactúan varias unidades. Estos tests sí pueden hablar con la BD o el sistema de archivos. Partimos de esta base: un test unitario es rápido, determinista, no depende de recursos externos y no requiere contexto especial para ejecutarse.

Los mocks cumplen el contrato de la interfaz. Nos permiten testear funcionalidad sin invocar clases colaboradoras complejas.

Un mock es un doble de test que sustituye la implementación real. Además, puede verificar cómo el código bajo test lo utilizó durante la ejecución.

Recomiendo encarecidamente que leas este post si quieres entrar en los detalles de por qué Mockear es un code smell (Temas como estos: ¿Qué es un mock? ¿Qué es un test unitario? ¿Qué es la cobertura de tests? ¿Qué es el acoplamiento fuerte? ¿Qué causa el acoplamiento fuerte? ¿Qué tiene que ver la composición con el mocking? ¿Cómo eliminamos el acoplamiento? ¡y más!)

El problema con mockear #

Cuando mockeas, anulas la lógica de la clase mockeada. La lógica real queda oculta, y ahí es donde los bugs se esconden. Ten en cuenta que:

El mock puede tener atributos, métodos o argumentos que el objeto real no tiene.
Los valores de retorno del mock pueden diferir de los reales. Por ejemplo, puede devolver un tipo distinto con atributos diferentes.
Los efectos secundarios y comportamiento del mock pueden diferir del objeto real. Quizás el mock no lanza una excepción que el objeto real sí lanzaría.

Alternativas a mockear #

“¿Estás diciendo que mockear es malo y no deberíamos mockear?” No.

Depende de lo que estés “anulando”.

¿Es tu lógica de dominio de negocio lo que estás mockeando? Entonces está mal.
¿Es la conexión a la BD lo que estás mockeando? Entonces está bien.

Depende del contexto de la lógica y dónde pertenece esa lógica.

¿Es parte de tu lógica de dominio de negocio? Entonces no deberías mockearla sino instanciarla.

¿Es una dependencia de infraestructura como conexión a BD, sistema de archivos, red, o cualquier servicio externo que no tiene que ver con tu dominio de negocio? Entonces mockéala usando abstracciones/interfaces.

La interfaz es el contrato entre tu lógica de dominio y sus dependencias de infraestructura. Imagina lo fácil que es testear tu dominio instanciándolo y llamando a sus métodos con diferentes argumentos, todo bajo tu control total.

Algunos trucos #

Cuando estés escribiendo un test unitario:

Intenta instanciar tus clases primero.
Evita mockear clases concretas. Escribí un artículo exclusivamente sobre esto: fomentando clases finales e interfaces.

Mockea interfaces. Instancia clases concretas.

“El uso excesivo de mocks lleva a código legacy.” - Philippe Boargau

¿Cómo podemos evitar el mocking excesivo? #

Favorece el estado inmutable sobre el estado mutable.
Haz las dependencias explícitas.
Programa hacia una interfaz, no hacia una implementación.

Referencias #

Mocking is a code smell - Eric Elliott
When to mock & Test Definitions - Uncle Bob
Final classes by default - Matthias Noback
The problem with mocks - Sean Hammond
A Set of Unit Testing Rules - Michael Feathers

Principios de diseño de paquetes

2020-11-12T00:00:00+00:00

Aprende a aplicar principios de diseño a tus clases para que sean reutilizables. El libro te enseña a crear paquetes con la cohesión y acoplamiento adecuados, pensados para usuarios y mantenedores.

La primera parte cubre los cinco principios SOLID para mejorar el diseño de clases. La segunda parte entra en las mejores prácticas de diseño de paquetes: principios de cohesión y de acoplamiento.

Los principios de cohesión te dicen qué clases van juntas, cuándo dividir un paquete, y cuándo un grupo de clases puede llamarse “paquete”. Los de acoplamiento te ayudan a elegir bien las dependencias y evitar ciclos en el grafo de dependencias.

Lo que aprenderás #

Aplicar los principios SOLID
Decidir si las clases pertenecen al mismo paquete
Saber cuándo un paquete puede depender de otro

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 #

Arrays Tipados en PHP

2020-10-13T00:00:00+00:00

Desempaquetado de argumentos, lista de argumentos variables de función, y funciones variádicas.

La combinación perfecta #

Desempaquetado de argumentos: pasa los elementos de un array como argumentos individuales a una función.
Lista de argumentos variables: la función recibe los argumentos como un array.
Función variádica: permite verificar los tipos con un type-hint.

Usaremos este snippet para nuestros ejemplos. Tenemos una clase Customer:

<?php
/**
 * @psalm-immutable
 */
final class Customer
{
 // Usando la promoción de propiedades en constructor de PHP 8
 // https://wiki.php.net/rfc/constructor_promotion
 public function __construct(
 public string $name,
 ) {}
}
// Creamos una lista de 6 clientes
$customers = array_map(
 fn(int $i): Customer => new Customer("name-{$i}"),
 range(1, 6)
);

Siempre que queramos manipular una lista de Customers, podemos pasar como argumento: …$customers.

Cómo solíamos hacerlo #

Definimos el tipo del array con PHPDoc, pero no podemos forzar el tipo real de cada elemento. El código se ejecuta sin problemas aunque pases cualquier tipo en array $customers:

<?php
/**
 * @param Customer[]
 */
function createInvoiceForCustomers(array $customers): void
{
 foreach ($customers as $customer) {
 // ... alguna lógica irrelevante para este ejemplo
 }
}

El código de abajo funcionaría en “tiempo de compilación”. Pero podría fallar en “tiempo de ejecución”.

<?php
createInvoiceForCustomers($customers);
createInvoiceForCustomers([new Customer('any name')]);
createInvoiceForCustomers([new AnyOtherType()]);

Una alternativa recomendada: extraer la lógica y pedir el tipo concreto para verificarlo en tiempo de ejecución. Fallará si alguno de los elementos no es un Customer:

<?php
/**
 * @param Customer[]
 */
function createInvoiceForCustomers(array $customers): void
{
 foreach ($customers as $customer) {
 createInvoice($customer);
 }
}
function createInvoice(Customer $customer): void
{
 // ... alguna lógica irrelevante para este ejemplo
}

Todo lo de aquí abajo funcionaría en “tiempo de compilación”. Seguro que fallará durante “tiempo de ejecución” si createInvoice(Customer $customer) recibe algo diferente a un Customer.

<?php
createInvoiceForCustomers($customers);
createInvoiceForCustomers([new Customer('any name')]);
createInvoiceForCustomers([new AnyOtherType()]); // no funcionará

Con createInvoice(Customer $customer) aseguramos el tipo del argumento. Pero, ¿podemos ir un paso más allá? ¿Podríamos verificar los tipos al llamar a createInvoiceForCustomers(array $customers), y que el IDE se queje si los tipos no son correctos?

Eso es precisamente para lo que sirven los Generics, pero aún no existen en PHP. Ni siquiera en PHP 8. Quizás lleguen pronto, pero por ahora hay una alternativa menos conocida con sus pros y contras. Veamos un ejemplo:

<?php
function createInvoiceForCustomers(Customer ...$customers): void
{
 foreach ($customers as $customer) {
 createInvoice($customer);
 }
}

Todo lo de aquí abajo funcionaría en “tiempo de compilación”. Seguro que fallará durante “tiempo de ejecución” si createInvoice() recibe algo diferente a un Customer.

<?php
createInvoiceForCustomers(...$customers); // OK
createInvoiceForCustomers(
 new Customer('any name'),
 new Customer('any name'),
); // OK
// Esto ni siquiera es posible de escribir. El IDE te gritará.
// Está esperando un `Customer`, pero `AnyOtherType` es dado:
createInvoiceForCustomers(new AnyOtherType());

PROS #

Podemos tipar una lista de cualquier tipo concreto de forma sencilla.

CONTRAS #

Mejor limitar las funciones a uno o dos argumentos. De lo contrario, se complica la lectura.

Observaciones importantes #

Debe ser el último argumento de la función.
Ayuda a minimizar el número de argumentos.

Los variadics simulan arrays tipados, úsalos con cabeza #

El desempaquetado de argumentos, combinado con funciones variádicas, nos permite simular arrays tipados. Un gran poder conlleva una gran responsabilidad. Hay que conocer bien nuestras herramientas para usarlas con criterio.

Referencias #

Guía de estilo para diseño de objetos

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

Los objetos son el corazón de lenguajes como Java, Python y C#. Si aplicas buenas prácticas de diseño, tu código será más fácil de leer, escribir y mantener.

Este libro reúne docenas de técnicas para crear código OO profesional que aguanta el paso del tiempo.

Los ejemplos usan pseudocódigo fácil de entender. Las técnicas aplican a cualquier lenguaje OO, desde C++ hasta PHP.

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.

Strict Types en PHP

2020-08-09T00:00:00+00:00

En diciembre de 2015, PHP 7 introdujo las declaraciones de tipos escalares y la bandera strict types. ¿Qué es esto?

Lo bueno de declarar un archivo PHP como estricto es que se aplica solo al archivo actual. Asegura tipos estrictos en ese archivo, pero no afecta al resto del proyecto. Puedes migrar de código no estricto a estricto paso a paso, especialmente en archivos o proyectos nuevos.

Para habilitar el modo estricto, coloca una directiva declare al principio del archivo. La estrictez de tipado para escalares se configura por archivo. Esta directiva afecta tanto a los parámetros como al tipo de retorno de las funciones.

Strict types afecta la coerción de tipos #

Usar type hints sin strict_types puede causar bugs sutiles.

Sin strict types, int $x significa “$x debe ser coercionable a int”. Cualquier valor coercionable a int pasaría:

un int (42 -> 42)
un float (13.1459 -> 13)
un bool (true -> 1)
un null (null -> 0)
un string con dígitos al inicio (“15 Trees” -> 15)

Con strict_types=1, le dices al motor que int $x significa que $x debe ser un int real, sin coerción. Tienes la seguridad de que recibes exactamente lo que se pasó, sin conversiones ni pérdida de datos.

¿A quién le importa esta línea? #

declare(strict_types=1); es más para el lector que para el escritor. Le dice explícitamente:

Los tipos en este archivo se tratan de forma estricta.

‘strict_types=1’ es más para el lector que para el escritor

El escritor solo necesita mantener esa estrictez mientras escribe. Pero como escritor, deberías preocuparte por tus lectores. Eso incluye a tu yo futuro.

Referencias #

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.

Clases Final en PHP | Java | Cualquiera

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

Contratos claros, efectos secundarios aislados, testeabilidad, baja complejidad y carga cognitiva, fluidez del código y confianza en ti mismo.

Motivación #

Reduce la visibilidad al mínimo #

Cuando una clase es final, no puede ser extendida. Esto la hace más legible y te asegura que la lógica está limitada a esa clase.

Fomenta “composición sobre herencia” #

El Principio Abierto-Cerrado dice: abierto para extensión, cerrado para modificación.

Si decides crear una herencia (por una buena razón, de la que deberías ser consciente), simplemente quita final y listo.

Cuando por defecto no puedes extender una clase, te fuerzas a pensar en composición en lugar de herencia.

¿Por qué esta clase no es final? #

Si preferimos composición sobre herencia, deberíamos evitar la herencia tanto como sea posible. La herencia se usa mal a menudo en POO.

Un concepto mal entendido #

Cuando nos enseñaron POO, normalmente empezamos con el ejemplo clásico de herencia.

Pero cuando Alan Kay creó Smalltalk, la herencia no era el concepto principal. Lo principal era el paso de mensajes: enviar mensajes a objetos que encapsulan datos y lógica, cambiando comportamiento mediante diferentes objetos. Eso es composición. La herencia se hizo tan popular que terminó eclipsando a la composición.

Beneficios #

Contratos claros. Usar interfaces te obliga a pensar en comunicación entre objetos.
Código aislado, sin efectos secundarios. Inyectar solo interfaces elimina efectos secundarios molestos.
Testeabilidad. Mockear interfaces es muy fácil.
Complejidad manejable. Todo aislado significa menos cambios en cascada.
Baja carga cognitiva. Menos complejidad, más foco en lo importante.
Flexibilidad. Sin acoplamiento innecesario, mover código es más fácil.
Confianza. Testear código aislado te da seguridad para cambiarlo.

Composición sobre herencia #

Si necesitas reconfigurar un objeto, cambiar partes de un algoritmo o reescribir parte de la implementación, considera crear una nueva clase en lugar de sobreescribir una existente.

¿Necesitas representar una jerarquía donde las subclases sustituyen a las clases padre? Esta sería la situación clásica donde podrías usar herencia. Aun así, el resultado suele ser mejor si heredas de interfaces abstractas, no de clases concretas.

Qué hacer en su lugar #

Usa interfaces para definir contratos entre clases.
Usa clases finales para implementar esas interfaces.
Usa composición (inyección de dependencias por constructor) para unir las piezas.

Interfaces -> Clases finales -> Composición

El Arte del Testing: Donde el Diseño se Encuentra con la Calidad

2020-04-07T00:00:00+00:00

¿Por qué considerar el testing parte de tu desarrollo diario? Porque está directamente vinculado a la calidad del software.

No voy a explicar las diferentes técnicas de testing ni las diferencias entre tests unitarios, de integración, funcionales o end-to-end.

Me sigue sorprendiendo la falta de experiencia con testing en el mundo del software. Hay una ignorancia generalizada sobre buenas prácticas. Si has trabajado en varios proyectos y equipos, seguro que lo has visto.

Testing de software #

Algunos patrones horribles que he visto (y hecho):

Testear por testear: testear cada archivo individual, confundiéndolo con una “unidad”.
Mockear cada clase, anulando la implementación real y creando comportamiento falso. Esto da una falsa sensación de cobertura.
Acoplar código de producción con tests por todas partes. Imposible cambiar nada sin romper tests, aunque la funcionalidad siga funcionando.
No testear nada porque “ya funciona, ¿para qué perder más tiempo?”

Una razón principal del testing es verificar el comportamiento esperado del software. Pero el testing puede (y debería) ser mucho más que eso.

Diseño de software #

El diseño de software abarca desde algoritmos hasta arquitectura. Aunque estos dos niveles tienen necesidades distintas, comparten patrones comunes. Por ejemplo, el testing:

Si es fácil de testear, probablemente será debido a un buen diseño.

Calidad del software #

Medir la calidad es difícil. Hay muchas métricas a considerar. Aun así, seguro que podemos estar de acuerdo en esto:

Si aspiras a la calidad en tu software, mejor busca un buen diseño.

Testear significa “probar”. ¿Cuántas veces hemos abandonado tests por la complejidad de probar cierta lógica?

El arte del testing consiste en usar los tests para contribuir al resultado final. Si usamos el testing a nuestro favor, según el contexto, mejoraremos la calidad del producto.

Por tanto, el testing no solo verifica comportamiento. También guía el software hacia un mejor diseño.

¿Deberíamos testear todo? Depende del contexto. Habrá situaciones donde los tests no aporten beneficio. Aun así, escribe código como si fuera a ser testeado.

El código testeable tiende a un mejor diseño y, por lo tanto, a mejor calidad.

Arquitectura Limpia

2018-06-04T00:00:00+00:00

Principios de diseño de código (SOLID) #

Responsabilidad Única: una clase debe tener una sola razón para cambiar. O en su versión nueva: un módulo responde ante un solo actor.
Abierto-cerrado: abierta para extensión, cerrada para modificación.
Sustitución de Liskov: puedes reemplazar objetos por instancias de sus subtipos sin romper el programa.
Segregación de Interfaces: mejor muchas interfaces específicas que una general.
Inversión de Dependencias: depende de abstracciones, no de implementaciones concretas.

Principios de componentes #

Cohesión de componentes #

Equivalencia Reutilización/Liberación: las clases reutilizadas juntas deben liberarse juntas. Mismo número de versión y changelog adecuado.
Cierre Común: las clases que cambian juntas van juntas. Es el principio de responsabilidad única a nivel de componente.
Reutilización Común: no obligues a los usuarios a depender de lo que no necesitan. Segregación de interfaces a nivel de componente.

Acoplamiento de componentes #

Dependencias Acíclicas: sin ciclos en el grafo de dependencias. Los ciclos fuerzan a liberar componentes juntos. Usa inversión de dependencias para romperlos.
Dependencia Estable: los componentes menos estables dependen de los más estables. Depende en dirección de la estabilidad.
Abstracciones Estables: los componentes estables deben ser abstractos. Ejemplo: una política de alto nivel que se extiende siguiendo abierto-cerrado.

Principios de arquitectura #

Estableciendo límites #

Los límites separan elementos de software: lo que importa de lo que no, lo de alto nivel de lo de bajo nivel. Si el código de alto nivel depende del de bajo nivel, los cambios se propagan hacia arriba. Ponemos un límite usando polimorfismo para invertir el flujo. Esto es el Principio de Inversión de Dependencias de SOLID.

Separando capas #

Cuatro capas principales (aunque puede variar):

Entidades: objetos con lógica de negocio crítica. Ejemplo: un banco que no da préstamos a clientes sin cierta puntuación crediticia. Se comparten entre aplicaciones de la empresa.
Casos de uso: reglas de negocio específicas de la aplicación. Ejemplo: la secuencia de pantallas para hacer una transferencia.
Adaptadores de interfaz: gateways, presenters, controllers. Aquí va la arquitectura MVC de la GUI y la transformación de datos entre base de datos y casos de uso.
Frameworks y drivers: frameworks web, base de datos, la vista de MVC.

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.

El Programador Limpio

2016-08-01T00:00:00+00:00

Los programadores que triunfan bajo presión e incertidumbre comparten algo: les importa de verdad crear buen software. Lo tratan como un oficio. Son profesionales.

Aprenderás #

Qué significa ser un verdadero artesano del software
Cómo lidiar con conflictos, plazos ajustados y jefes difíciles
Cómo entrar en flujo y superar el bloqueo
Cómo manejar la presión y evitar el agotamiento
Cómo combinar actitudes clásicas con nuevos paradigmas de desarrollo
Cómo gestionar tu tiempo y evitar atascos
Cómo crear entornos donde los programadores y equipos prosperen
Cuándo decir No y cómo hacerlo
Cuándo decir Sí y qué implica realmente

Resumen #

Capítulo 1: Profesionalismo #

Ser profesional significa asumir responsabilidad total de tus acciones.
Primera regla: no dañes ni la función ni la estructura del software.
Siempre cometerás errores, pero aprende de cada uno.
Confía en el código que liberas. Espera que QA no encuentre nada.
- Prueba una y otra vez.
- Automatiza tus tests.
- Diseña el código para que sea fácil de probar.
Sigue la regla del Boy Scout: deja el código un poco más limpio de como lo encontraste.
Tu carrera es tu responsabilidad, no la de tu jefe.
- Dedica 20 horas semanales extra a mejorar tus habilidades.
- Lee, experimenta, practica (katas), habla con otros, colabora, mentoriza.
- Que sea divertido.
Conoce tu dominio e identifícate con tu cliente (nunca “nosotros vs. ellos”).

Capítulo 2: Decir No #

Los profesionales tienen el coraje de decir no a sus jefes.
Managers y desarrolladores a menudo chocan porque sus objetivos a corto plazo entran en conflicto.
Cuanto mayor el riesgo, más valioso es un “no” y más difícil de decir.
Los buenos equipos trabajan hacia un sí, pero solo un sí correcto que funcione en la práctica.

Capítulo 3: Decir Sí #

Hay tres partes para hacer un compromiso:
- Dices que lo harás
- Lo dices en serio
- Realmente lo haces
Tu compromiso debe respetar los límites de lo que esperas (basado en tu experiencia) poder y no poder hacer.
- Si reconoces que probablemente no podrás cumplir un compromiso, necesitas levantar una bandera roja inmediatamente.

Capítulo 4: Codificación #

Programar requiere un nivel de concentración que pocas disciplinas exigen.
“La zona” (o flujo) no es tan buena como parece: serás productivo localmente, pero puedes perder la visión global y producir diseños mediocres.
Las interrupciones son malas distracciones.
- El pair programming ayuda a gestionarlas.
- TDD hace que el contexto pre-interrupción sea reproducible.
  - Minimiza el tiempo de depuración.
Programar es una maratón, no un sprint. Conserva energía y creatividad.
Vete cuando sea hora, aunque estés en medio de algo importante.
Reestima continuamente tu tiempo de finalización y avisa en cuanto veas que llegarás tarde.
- No dejes que nadie te meta prisa.
- Define bien qué significa “terminado”, con requisitos de calidad altos.
Programar es difícil para todos. Pide ayuda y ofrécela, especialmente como mentor.
- No tengas vergüenza de preguntar.

Capítulo 5: Test-Driven Development #

TDD no es una cura milagrosa y es impráctico o inapropiado en algunos casos (raros).
Ciclo TDD:
1. Añade un test
2. Ejecuta todos los tests. El nuevo test debería fallar por razones esperadas
3. Escribe el código más simple que pase el nuevo test
4. Todos los tests deberían pasar ahora
5. Refactoriza según sea necesario
6. Repite

Capítulo 6: Practicar #

Una Kata de programación es un conjunto preciso de pulsaciones de teclas y movimientos de ratón coreografiados que simula la resolución de algún problema de programación.
- Una Kata es sobre el proceso, no la solución.
- No estás resolviendo el problema porque ya conoces la solución.

Capítulo 7: Tests de Aceptación #

Evita “basura entra, basura sale”. Asegúrate de entender los requisitos.
- Entenderlos bien significa eliminar ambigüedad.
La mejor forma es definir tests de aceptación:
- Los tests automatizados verifican que el software cumple las condiciones del cliente.
- Pasar esos tests define “Terminado”.
Empieza a implementar solo cuando los tests estén definidos.
Los tests unitarios son para programadores. Los tests de aceptación son para negocio y desarrolladores.
Ejecuta todos los tests en integración continua y arregla los fallos de inmediato.

Capítulo 8: Estrategias de Testing #

QA es parte del equipo. Escriben tests de aceptación, casos de fallo, casos límite y hacen testing exploratorio.
Pirámide de testing:
- La mayoría son tests unitarios: por y para desarrolladores.
- Muchos son tests de componentes o integración: por QA/Negocio con ayuda de desarrolladores, para ambos.

Capítulo 9: Gestión del tiempo #

En desarrollo de software, gestionar bien el tiempo es esencial.
Las reuniones son necesarias pero a menudo una pérdida de tiempo. Evita las que no aporten valor claro: es una obligación profesional.
Las reuniones deben tener agenda y objetivo claro.
- Las dailies ágiles son un formato eficiente.
- La planificación de iteración debería ocupar el 5% de la iteración.
La concentración es un recurso escaso.
- Úsala cuando la tengas y recarga con tareas simples y descansos.
- Para mejorarla:
  - Haz deporte.
  - Busca estímulos creativos.
  - Toma descansos cortos cada 45 minutos.

Capítulo 10: Estimación #

Las estimaciones son la mayor fuente de desconfianza entre negocio y desarrolladores. Los desarrolladores dan estimaciones que negocio trata como compromisos.
- Ambos olvidan que una estimación es una distribución de probabilidad, no un número fijo.

Capítulo 11: Presión #

El profesional mantiene la calma bajo presión. Sigue sus disciplinas porque sabe que es la mejor forma de cumplir plazos.
Evita situaciones de presión:
- Haz solo compromisos que puedas cumplir.
- Mantén tu código limpio.
- Trabaja de forma que no necesites cambiar de método en crisis.
No entres en pánico. Habla con tu equipo. No te aceleres. Confía en tus disciplinas.
Ofrece hacer pairing a compañeros en crisis.

Capítulo 12: Colaboración #

A la mayoría de programadores les gusta trabajar solos. Pero hay que entender los objetivos de quienes nos rodean, incluido negocio.
- Eso requiere comunicación.
Dentro del equipo: solo la propiedad colectiva del código y el pairing producen buena comunicación.
- Programar es comunicarse.

Capítulo 13: Equipos y proyectos #

Los equipos necesitan meses para consolidarse, conocerse y aprender a trabajar juntos.
- Asignar personas a varios proyectos a la vez es mala idea. Romper un buen equipo también.
- Mejor asignar varios proyectos a un mismo equipo.

Capítulo 14: Mentoría, aprendizaje y artesanía #

Los programadores jóvenes necesitan mentoría, ya sea implícita o explícita.
El software controla todos los aspectos de nuestras vidas. Un período de entrenamiento y práctica supervisada es más que apropiado.

En esta lección, Uncle Bob explica por qué es necesario escribir código limpio y establece las bases para lograrlo, tanto sociales como técnicas. El futuro de la programación se basa en un código ético y bien educado.

En esta segunda lección, Uncle Bob habla del propósito de los comentarios. Rompe la idea de que comentar es algo que “hay que hacer” por ser supuestamente buena práctica. Para él, escribir un comentario es señal de fracaso: el buen código se explica solo. Menos comentarios = mejor código.

En esta tercera lección, Uncle Bob quiere crear conciencia sobre la necesidad de elevar el criterio al producir código. Señala la falta de preparación de muchos programadores como una de las principales causas de la ineficiencia en el desarrollo de software actual.

En esta cuarta lección, Uncle Bob introduce el Test-Driven Development (TDD). Es una práctica con curva de aprendizaje larga, pero produce código más robusto, seguro, mantenible y desarrollado con mayor eficiencia.

97 cosas que todo programador debería saber

2016-07-15T00:00:00+00:00

97 consejos cortos y útiles para programadores. Da igual qué lenguaje uses: aquí encontrarás nuevos enfoques para viejos problemas, buenas prácticas y consejos de expertos para mejorar tu oficio.

Mis principales aprendizajes #

01.- Paga la deuda técnica lo antes posible.

02.- Aprende y domina la programación funcional.

Hace tu código menos propenso a errores y más fácil de depurar.

03.- No adivines lo que haría un usuario; haz que los usuarios hagan cosas y obsérvalos.

04.- Automatiza los estándares de código.

05.- Escribe código simple, nombres descriptivos simples, relaciones simples.

06.- Antes de refactorizar: considera los tests existentes y el código.

Trabaja en incrementos, asegúrate de que los tests sigan pasando después de cada cambio.

08.- Siempre deja el código más limpio de lo que lo encontraste, incluso si no lo escribiste.

10.- Elige tus librerías/frameworks cuidadosamente para evitar complejidad innecesaria.

11.- Haz tu código fácil de entender usando términos del dominio.

13.- El formato del código también es importante.

14.- Usa revisiones de código enfocándote en compartir conocimiento entre miembros del equipo.

15.- Objetos inmutables siempre que sea relevante. Cada variable debería tener el menor alcance posible. Nunca incluyas más de cuatro argumentos de función.

18.- Toma responsabilidad de tu propia educación. Nunca dejes de aprender.

Basta con dedicar un poco de tiempo cada semana: podcasts, cursos, libros…

19.- Al diseñar una API, apunta a hacerla fácil de usar, no conveniente de codificar.

20.- Despliega temprano y frecuentemente. No lo dejes hasta el final del proyecto.

22.- Mejorar tus habilidades debería ser algo diario.

23.- Adapta el nivel técnico de tu lenguaje específico del dominio a tu audiencia.

24.- No tengas miedo de romper cosas si eso es lo necesario para arreglar cosas.

25.- Ten cuidado con tus datos de prueba porque podrían hacerse públicos accidentalmente.

26.- Maneja tus errores cuando aparecen, no lo dejes para después.

27.- Aprende diferentes lenguajes de programación.

Aprende su propia “cultura” o forma de hacer las cosas.
Definitivamente te hará un mejor programador.

28.- No solo captures tus errores, realmente manéjalos.

29.- Entiende al menos algunas complejidades de tu negocio, no solo programación.

30.- DRY: No Te Repitas.

32.- Encapsula comportamiento, no solo estado.

33.- Los números de punto flotante inevitablemente pueden crear errores en los cálculos.

34.- El código abierto es una gran oportunidad para hacer trabajo interesante y desarrollar habilidades de programación.

36.- Da el contexto adecuado cuando pidas ayuda, porque la gente no puede adivinar lo que está pasando.

37.- No se trata de echar muchas horas. Aprende a trabajar con eficacia.

Dedica tiempo a aprender y a pensar en lo que haces.

38.- Escribe reportes de bugs apropiados:

Precisamente cómo reproducir el bug,
con qué frecuencia aparece,
qué debería haber pasado,
qué realmente pasó.

39.- No escribas código innecesario.

Solo escribe código que añada valor y se necesite ahora mismo.
Elimina código muerto.

41.- La causa principal de lentitud en aplicaciones suele ser el exceso de llamadas remotas entre procesos, no el algoritmo.

Por ejemplo, conexiones a base de datos.

42.- Si aparece una advertencia del compilador, arréglala.

No lo dejes para después, aunque no vaya a ser problema en producción.
“Compilador” incluye cualquier análisis estático en lenguajes no compilados.

43.- Aprender a usar herramientas de línea de comandos es una experiencia educativa valiosa, y podrías terminar prefiriéndolas.

44.- Aprende (al menos) dos lenguajes y paradigmas diferentes bien.

45.- Invierte algo de tiempo para dominar el IDE que usas.

Te hará la vida más fácil y te ahorrará tiempo a largo plazo.

46.- Conoce y trabaja con tus limitaciones: presupuesto, recursos, tiempo, etc.

47.- Trabaja en tareas pequeñas. No tengas miedo de descartar cambios.

El conocimiento adquirido no se pierde.
Ten claro qué quieres lograr antes de empezar.

48.- Usa una BD relacional si tu aplicación va a manejar un conjunto grande, persistente e interconectado de datos.

49.- Aprende a comunicar bien: no solo con tu máquina, también con negocio. Y quizás otro idioma.

Es bueno para las conexiones y para la vida.

54.- Piensa dos veces antes de implementar “soluciones temporales”.

55.- Haz la GUI fácil de usar bien y difícil de usar mal.

Anticipa errores y busca cómo prevenirlos.
Se trata de la experiencia del usuario, no de la tuya.

56.- En proyectos, encuentra formas de hacer lo invisible visible.

57.- El paso de mensajes lleva a mejor escalabilidad en sistemas paralelos.

58.- Escribe código que otras personas puedan entender fácilmente.

59.- El polimorfismo reduce la necesidad de if/else, lo que produce código más corto y seguro.

60.- QA es tu amigo, no tu enemigo.

61.- Versiona tus releases.

62.- Asegúrate de que tu código fuente indique claramente lo que el programa está haciendo.

63.- Aprende sobre el proceso de build. Es una parte importante del desarrollo.

64.- Practica pair programming.

65.- Prefiere tipos específicos del dominio sobre tipos primitivos.

Hacen el código más legible y menos propenso a errores en el desarrollo.

67.- Un profesional toma responsabilidad personal por su carrera y su código.

68.- Usa control de versiones.

69.- A veces la mejor forma de resolver un problema es alejarte del ordenador y dejar que la solución aparezca mágicamente en tu mente.

70.- Leer código es una buena forma de aprender. El código de otras personas o tu código antiguo.

72.- Reinventar la rueda es una gran forma de desarrollar tus habilidades.

75.- Si el código que escribiste es verdaderamente horrible, no intentes arreglarlo. Bórralo y empieza de nuevo.

76.- Aplica el Principio de Responsabilidad Única (SRP).

77.- Si alguien pide un cambio de producto, no lo descartes aunque no estés de acuerdo. Pregunta por qué.

Llegarás a conversaciones más productivas y mejores resultados.

78.- Si estás haciendo lo mismo una y otra vez, intenta encontrar una forma de automatizarlo.

79.- Aprovecha las herramientas de análisis de código.

80.- Escribe tests basados en la funcionalidad deseada de tu programa, no en comportamiento incidental.

83.- El testing toma tiempo, pero asegura la calidad del producto final. Hazlo.

85.- Hay muchos beneficios en el trabajo colaborativo y pair programming.

86.- A veces arreglar un error en el código lleva a descubrir un error oculto.

87.- Escribe código pensando en otros programadores.

88.- Aprende a usar herramientas Unix. Aprende a usar el terminal.

89.- Usa el algoritmo y estructura de datos correctos para el trabajo.

Para hacer eso, necesitas entenderlos bien.

90.- Ten una buena política de logging.

91.- Usar el principio DRY te ayuda a identificar y reparar cuellos de botella de rendimiento.

92.- Testers y programadores deberían colaborar.

93.- Escribe código como si tuvieras que mantenerlo el resto de tu vida.

94.- Intenta escribir funciones “pequeñas”.

Los buenos tests actúan como documentación para el código que prueban.

Describen cómo funciona el código.

Para ser un buen programador, tienes que preocuparte por la calidad del código.

97.- Habla con tus clientes antes de asumir que entiendes lo que quieren. De verdad.

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.