Chemaclass - software-design

Bitcoin con Rigor

2025-01-18T00:00:00+00:00

Un análisis detallado de cómo funciona Bitcoin, desglosando sus componentes de forma clara para entender tanto las partes como el sistema completo. Explora su potencial y riesgos como experimento monetario que, aunque no ha superado la prueba del tiempo como el oro, tiene un diseño prometedor.

Bitcoin es difícil de entender del todo. Requiere conocimientos de computación, economía y finanzas, y además es un activo digital sin precedente histórico que sirva de guía. Pero igual que Internet (también joven pero innegablemente transformador), Bitcoin tiene el potencial de redefinir sistemas y dejar un impacto duradero.

Este libro busca darte las herramientas para entender cómo funciona Bitcoin. Así podrás formar tu propia opinión informada sobre su papel en la sociedad o, si lo decides, empezar una carrera profesional en este sector. Está escrito con rigor pero sin tecnicismos excesivos: conciso, accesible y pensado para que comprendas Bitcoin de verdad.

Contenido #

1. Conceptos Básicos de Computación #

Información y Comunicación
Cómo Funcionan las Computadoras
Lenguajes y Protocolos
El Modelo OSI: La Cebolla de la Computación
Puertas Lógicas: Funciones Fundamentales de Computación
Redes Cliente-Servidor y P2P

2. Conceptos Básicos de Criptografía #

Complejidad Asimétrica
Cifrados, Claves y Criptografía Simétrica
Criptografía Asimétrica
El Movimiento Cypherpunk
Funciones Hash Criptográficas

3. Los Fundamentos de Bitcoin y las Criptomonedas #

Generadores de Claves y Aleatoriedad
Firmas Criptográficas
El Problema del Logaritmo Discreto
Criptografía de Curva Elíptica
Árbol de Merkle
Dinero Digital Tradicional
Algoritmos de Consenso Distribuido
Prueba de Trabajo (PoW)

4. Bitcoin Pieza por Pieza #

¿Blockchain o Hashchain?
Sincronización de Bloques
La Headerchain
Claves y Firmas en Bitcoin
Transacciones y el Modelo UTXO
Bitcoin Script y Opcodes
P2PKH (Pay to Public Key Hash) y P2PK
Multifirmas y P2SH (Pay to Script Hash)

5. Nodos y Blockchain en Detalle #

Tamaño y Frecuencia de Transacciones
Inicialización de un Nodo de Red Completo
Bases de Datos y Pruning
Cómo Funciona una Wallet
Wallets, Nodos SPV y Otros
Del Mempool a la Blockchain
Forks y Criticidad del Consenso
Hard Fork vs. Soft Fork

6. Actualizaciones y Aplicaciones de Bitcoin #

Mucho Trabajo por Delante
Maleabilidad de Transacciones
Segregated Witness (SegWit)
P2WPKH y P2WSH
Canales de Pago Unilaterales
Canales Lightning
Pagos Multicanal y HTLCs
Lightning Network
Discreet Log Contracts (DLCs)
MAST, P2SMR y P2CH
Taproot y Grafroot

Presentación del libro #

Enlaces relacionados

Sitio web del libro: www.bitcoinconrigor.com

Bitcoin: A Work in Progress

2024-08-02T00:00:00+00:00

Con miles de proyectos cripto por ahí, dicen que Bitcoin es viejo y aburrido. Nada más lejos de la realidad. Este libro te guía por los últimos desarrollos de Bitcoin desde la perspectiva de uno de sus desarrolladores.

Aprenderás sobre Taproot (el último soft fork), los retos de mantener software open source libre de bugs y malware, nuevas formas de proteger nodos contra atacantes, cómo gestionar una blockchain que no para de crecer, y mucho más.

El libro enlaza a más de doscientos artículos, videos, podcasts e incluso código fuente. Y gracias a los códigos QR junto a cada enlace, nunca tendrás que escribir URLs largas.

Contenidos #

Lo básico #

1. Direcciones Bitcoin
2. DNS Bootstrap y Tor V3
3. SegWit
4. libsecp256k1

Uso de recursos #

5. Tiempo de Sincronización y AssumeUTXO
6. Utreexo

Atacando Bitcoin #

7. Ataques Eclipse
8. Nodos Falsos
9. Guix

Mejores Wallets #

10. Script, P2SH, y Miniscript

Taproot #

11. Taproot y Schnorr
12. Opciones de Activación

Apéndice #

A. Más Episodios
B. Un crimen en Testnet
C. White Paper de Bitcoin

Enlaces relacionados

Código fuente del libro: GitHub/Sjors
Sitio web del libro: www.btcwip.com

¿Qué Es Waterfall?

2024-08-01T00:00:00+00:00

Waterfall es como seguir un camino recto donde te mueves de un paso al siguiente en un orden definido, como el agua fluyendo por una cascada a través de diferentes etapas.

El problema es que cada paso puede llevar mucho tiempo y recursos para completarse. Además, no recibes retroalimentación hasta que toda la etapa está terminada, lo que puede llevar a mucho tiempo desperdiciado. Esto es especialmente complicado en el desarrollo de software, donde las cosas siempre están cambiando y evolucionando.

Usualmente sigue una secuencia directa como esta:

La realidad de Waterfall #

Waterfall puede ser como el comunismo en teoría, parece perfecto en papel pero no funciona en el mundo real.

Los clientes a menudo no saben exactamente lo que quieren.
Los requisitos están constantemente cambiando.
Los negocios necesitan adaptarse rápidamente a los cambios del mercado y las necesidades de los clientes.
El software necesita ser flexible para mantenerse al día con estos cambios.

Entonces, en un mundo en constante cambio, Waterfall puede realmente perjudicar a un negocio. Tiende a frustrar a los desarrolladores y equipos, y también puede molestar a los clientes y a los negocios que pagan por el software. Esto usualmente lleva a retrasos y costos adicionales.

Por qué las empresas aún usan Waterfall #

Incluso con sus problemas, muchas empresas aún usan Waterfall porque parece directo y lógico. Esto les hace reacios a tomarse el tiempo de aprender Agile. Además, conseguir que la dirección acepte cambiar a Agile puede ser difícil de vender, especialmente ya que requiere una inversión en tiempo y aprendizaje.

El gran problema es cuando los superiores dictan exactamente cómo deben trabajar los equipos, llevando a la microgestión. Esto arruina la flexibilidad que Agile aporta. Por lo que he visto, esto es un problema común.

Mirando hacia atrás, cambiar a Agile podría haber solucionado muchos problemas.

Por qué se creó Agile #

Agile fue creado para superar las limitaciones del método Waterfall. Se enfoca en la interacción constante con clientes y equipos.

Agile construye equipos autónomos y responsables que manejan tareas de principio a fin, reduciendo tiempo y recursos desperdiciados. Enfatiza la flexibilidad, la colaboración y la retroalimentación del cliente.

A diferencia de Waterfall, Agile usa desarrollo iterativo, dividiendo proyectos en pequeños sprints o iteraciones manejables que duran de 1 a 4 semanas. Cada ciclo incluye planificación, desarrollo, pruebas y revisión, con el objetivo de entregar valor rápidamente y recopilar retroalimentación para mejorar.

Aspectos clave de Agile #

Desarrollo iterativo: Trabaja en pequeños fragmentos y ajusta sobre la marcha.
Colaboración con el cliente: Mantén la comunicación con los clientes para asegurar que están satisfechos.
Equipos multifuncionales: Equipos con diferentes habilidades trabajando juntos.
Planificación adaptativa: Mantente flexible y ajusta los planes basándote en la retroalimentación.
Mejora continua: Siempre busca formas de mejorar.

Lee el Manifiesto Agile original.

¿Por dónde puedes empezar? #

Como desarrollador, puedes impulsar tu agilidad sumergiéndote en pair programming y TDD.

Con pair programming, dos desarrolladores trabajan lado a lado, lo que significa que obtienes retroalimentación instantánea y resolución de problemas compartida, llevando a mejor código.
TDD, por otro lado, implica escribir tests antes del código, lo que ayuda a especificar lo que quieres hacer, enfocándote en pequeños pasos.

Juntas, estas prácticas hacen tu proceso de desarrollo más flexible, colaborativo y de alta calidad, encajando perfectamente con el enfoque de Agile en ajustes rápidos y mejora continua. Ve más prácticas aquí.

La clave es colaboración, pequeños pasos y retroalimentación rápida en todo lo que trabajas.

Mi experiencia con Agile #

He hablado sobre Agile en varios eventos tecnológicos y lo he explorado en profundidad porque me apasiona cómo puede potenciar a los equipos de software. Cuando se hace bien, Agile puede cambiar completamente cómo trabajan los equipos, haciéndolos más rápidos, más eficientes y mejores en entregar lo que los clientes y negocios realmente necesitan.

2022-06-26 | International PHP Conference [Berlín, Alemania] (EN)
2022-09-16 | Code Talks [Hamburgo, Alemania] (EN)
2022-10-26 | International PHP Conference [Múnich, Alemania] (EN)
2022-12-21 | IES Ginés Pérez Chirinos [Murcia, España] (ES)
2023-01-19 | devm.io [Remoto] (EN)
2023-07-28 | WeAreDeveloper World Congress [Berlín, Alemania] (EN)

WeAreDevelopers World Congress en Berlín #

Dominando Bitcoin

2024-07-05T00:00:00+00:00

Este libro cubre desde los conceptos básicos hasta los aspectos técnicos más profundos de Bitcoin. Una guía excelente para entender este mundo y participar en el Internet del dinero.

La primera edición se publicó en diciembre de 2014. Diez años después, ya tenemos una tercera edición actualizada. Muy recomendable para cualquier persona interesada en este tema y la tecnología que hay detrás.

Introducción amplia a Bitcoin y su blockchain, ideal para usuarios no técnicos, inversores y ejecutivos.
Explicación técnica para desarrolladores, ingenieros y arquitectos de software.
Detalles sobre la red descentralizada, arquitectura P2P, ciclo de vida de transacciones y seguridad.
Novedades como Taproot, Tapscript, firmas Schnorr y Lightning Network.
Inmersión profunda en aplicaciones de Bitcoin: cómo combinar sus bloques de construcción en herramientas nuevas.
Historias, analogías, ejemplos y fragmentos de código que explican los conceptos clave.

Contenidos #

Introducción
Cómo Funciona Bitcoin
Bitcoin Core: La Implementación de Referencia
Claves y Direcciones
Recuperación de Wallet
Transacciones
Autorización y Autenticación
Firmas Digitales
Comisiones de Transacción
La Red Bitcoin
La Blockchain
Minería y Consenso
Seguridad de Bitcoin
Aplicaciones de Segunda Capa

Libro completo también en GitHub.

Puntos clave #

Tu wallet no almacena bitcoins, solo las claves para acceder a ellos. Las monedas están en la blockchain.
Entender los UTXOs es clave para entender las transacciones.
- Son outputs de transacciones anteriores que aún no se han gastado.
Una transacción necesita:
- inputs: UTXOs y un script de desbloqueo (scriptSig) que prueba la propiedad.
- outputs: dirección del destinatario y cantidad a enviar.
El script de desbloqueo usa un lenguaje llamado Script.
- La validación se hace ejecutando el script.
- Permite expresar una variedad casi infinita de condiciones.
- Script es un lenguaje basado en pila, procesado de izquierda a derecha.
Bitcoin se conoce como “dinero programable” porque permite multifirma, bloqueo temporal y gasto condicional.
- Va más allá de simples transferencias de valor.
Tipos de direcciones comunes:
- P2PKH: Empieza con 1. Transacciones estándar con hashes de clave pública.
- P2SH: Empieza con 3. Encapsula scripts complejos como multisig.
- P2WPKH: Empieza con bc1. SegWit nativo, más eficiente.
- P2WSH: Empieza con bc1. SegWit para scripts complejos.
- P2TR: Empieza con bc1p. Taproot, mejor privacidad y eficiencia.
- Bech32: Empieza con bc1. Legible por humanos, para SegWit y Taproot.
Las firmas digitales cumplen tres funciones en Bitcoin:
- Prueban que quien controla la clave privada ha autorizado el gasto.
- La prueba de autorización es innegable.
- La transacción autorizada no puede cambiarse por terceros no autenticados.
Las firmas de Schnorr no son exclusivas de la criptografía de curva elíptica (ECC) de Bitcoin, aunque hoy se asocian mucho con ella. Tienen propiedades interesantes:
- Seguridad demostrable: garantías fuertes basadas en el problema del logaritmo discreto, con pruebas formales de robustez.
- Linealidad: permite agregar múltiples firmas en una sola firma compacta, simplificando la verificación.
- Verificación por lotes: verificar múltiples firmas a la vez de forma más eficiente.
El algoritmo más conocido para compartir secretos de forma segura es Shamir’s Secret Sharing.
Ejecutar un nodo completo te da la experiencia pura de Bitcoin: verificas todas las transacciones de forma independiente, sin confiar en nadie.
Los árboles Merkle resumen todas las transacciones de un bloque, creando un compromiso con el conjunto completo y permitiendo verificar de forma muy eficiente si una transacción está incluida.
La minería es una de las invenciones que hacen especial a Bitcoin: un mecanismo de consenso descentralizado que es la base del efectivo digital P2P.
- Asegura el sistema y permite que emerja consenso a nivel de red sin autoridad central.
Un soft-fork es un cambio compatible hacia adelante en las reglas de consenso. Los clientes no actualizados pueden seguir operando con las nuevas reglas.

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.

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.

Introduciendo un Nuevo Stack Tecnológico

2023-04-14T00:00:00+00:00

Cuando introduces una nueva tecnología en tu equipo, necesitas explicar el porqué y tener una estrategia clara. Va a afectar a todos.

¿Por qué ese nuevo stack tecnológico? #

Antes de decidir, recuerda que es una decisión de equipo. Piensa en la estandarización y mantenibilidad del proyecto. Pero lo más importante: ¿qué problema quieres resolver? ¿Es porque mola? ¿O hay una necesidad real que esta tecnología resuelve?

La dirección de la tecnología #

Cuando propones adoptar una nueva biblioteca, framework o tecnología, hay que conocer su trasfondo y hacia dónde se dirige.

¿Cuál es la motivación detrás de esa tecnología? ¿Por qué quieres añadirla a tu stack actual?

Acoplamiento y dependencias #

Al adoptar nuevas tecnologías en el día a día, es fácil acoplarse a ellas. Eso hace más difícil dar marcha atrás si después nos arrepentimos.

No me malinterpretes: aprender y experimentar con nuevas tecnologías está genial. Pero introducirlas en tu trabajo diario es otra historia. Afecta a todo el equipo, así que hay que ser cuidadosos.

El enfoque de la conversación #

¿Qué aporta esta nueva tecnología al proyecto?
¿Qué problema queremos resolver?
¿Podemos resolverlo con nuestra tecnología actual?
Si ya tenemos algo similar, ¿queremos mezclar ambas?
¿Cuáles son los trade-offs de usarla vs. no usarla?
¿Vale la pena la complejidad extra a largo plazo?
¿Cuál es la estrategia para que todos se suban al carro?

Architectural Decision Records (ADRs) #

Sea cual sea el resultado, escríbelo como un ADR para poder revisarlo con el tiempo. Un ADR documenta las decisiones del equipo: pros, contras y los argumentos que encontrasteis juntos para decidir qué hacer y por qué.

Los ADRs ayudan a entender decisiones antiguas. Guárdalos en el control de versiones, en el mismo proyecto si es posible. Son útiles para el equipo actual y para los nuevos que lleguen.

Accelerate

2023-03-19T00:00:00+00:00

Accelerate explora cómo los equipos que usan Lean Software y DevOps pueden medir su rendimiento. También muestra cómo el rendimiento de ingeniería impacta a toda la organización.

Nota: DevOps integra y automatiza el desarrollo de software (Dev) con las operaciones de TI (Ops). El foco: mejorar y acortar el ciclo de vida de desarrollo.

Capacidades Clave #

Entrega Continua #

Usar Control de Versiones para todos los Artefactos de Producción
Automatizar tu Proceso de Despliegue
Implementar Integración Continua
Usar Métodos de Desarrollo Basado en Trunk
Implementar Automatización de Tests
Entrega Continua (CD)

Arquitectura #

Usar una Arquitectura Débilmente Acoplada

Producto y Proceso #

Recopilar e Implementar Feedback del Cliente
Hacer Visible el Flujo de Trabajo a través del Value Stream
Trabajar en Lotes Pequeños
Fomentar y Habilitar la Experimentación del Equipo

Gestión Lean y Monitoreo #

Tener Procesos Ligeros de Aprobación de Cambios
Monitorear la Aplicación e Infraestructura para Informar Decisiones de Negocio
Verificar la Salud del Sistema Proactivamente
Mejorar Procesos y Gestionar el Trabajo con Límites WIP (Work-In-Process)
Visualizar el Trabajo para Monitorear la Calidad y Comunicar a través del Equipo

Cultural #

Apoyar una Cultura Generativa
Fomentar y Apoyar el Aprendizaje
Apoyar y Facilitar la Colaboración entre Equipos
Proporcionar Recursos y Herramientas que Hacen el Trabajo Significativo
Apoyar o Encarnar el Liderazgo Transformacional

Cuatro Métricas Clave #

Lead Time de Cambio
- Tiempo para implementar, probar y entregar código para una funcionalidad
Frecuencia de Despliegue
- Número de despliegues en un período de tiempo dado
Tasa de Fallo de Cambios
- Porcentaje de cambios fallidos sobre todos los cambios (independientemente del éxito)
Tiempo Medio de Recuperación
- Tiempo que toma restaurar el servicio después de un fallo en producción

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

Ingeniería de Software Moderna

2022-06-29T00:00:00+00:00

El libro presenta el desarrollo de software como una práctica de ingeniería real. Para dominarlo hay que ser experto en aprender y gestionar la complejidad.

Optimizar para aprender #

El libro presenta cinco comportamientos clave para aprender mejor:

Trabajar de forma iterativa
Buscar feedback
Incrementalismo
Empirismo
Ser experimental

La idea central: trabajar en pasos pequeños, recoger feedback y ajustar.

Optimizar para gestionar la complejidad #

Cinco ideas para manejar la complejidad:

Modularidad
Cohesión
Separación de responsabilidades
Ocultación de información y abstracción
Gestión del acoplamiento

Gestionar la complejidad de nuestros sistemas es fundamental.

Herramientas para apoyar la ingeniería #

El libro profundiza en ideas como:

Testeabilidad
Desplegabilidad
Control de variables
Entrega continua

Un vídeo donde el autor explica las ideas principales del libro:

Modern CTO

2022-01-23T00:00:00+00:00

Los desarrolladores no son CTOs, pero pueden aprender a serlo.

Joel Beasley ofrece una guía práctica para pasar de desarrollador a CTO. Comparte desde su experiencia los retos, las lecciones aprendidas y los errores típicos en este camino.

Estos son los temas que encontrarás en el libro:

Un CTO moderno sabe… #

Los desarrolladores no son CTOs
La epidemia del código espagueti MVP
La sobre-ingeniería es un problema
Si contratar, comprar o superar a la competencia
Cómo no escalar prematuramente
Cómo resolver cualquier problema
Cómo trabajar con programadores cuando no eres uno
Errores de UX a tener en cuenta
Cuándo hablar
Cuándo contratar y despedir consultores
Cómo analizar el fracaso
Cómo recuperarse de restricciones imprevistas
Responder la pregunta: “¿Qué tan difícil es codificar…?”
Cómo evitar al “tipo del noveno inning”
Cuándo responder a la retroalimentación
Cómo validar a un experto en cualquier campo
Cómo comunicar efectivamente ideas complejas

Citas favoritas #

Si me apoyo en logros pasados, nunca creceré.

APROVECHA LA EXPERIENCIA DE OTROS. Los libros condensan toda una vida de experiencia en unas pocas horas de lectura.

Solo hay dos razones por las que escribes mal código:

Sabes cómo escribir buen código, pero eliges escribir mal código.

No sabes cómo escribir buen código. Y ambas apestan.

Como CTO, debes tener un enfoque de negocio.

Siempre vuelve a tus metas principales. […] Me aseguro de que cada meta tenga un “por qué” claro detrás. Así, cuando me pierdo, vuelvo a mi “por qué”.

Referencia a “Empieza con el Por Qué” de Simon Sinek.

Cuando eres el jefe, recuerda esta regla de oro: Pregunta a la gente qué piensa en lugar de decirles qué hacer.

Si no puedo evaluar el componente humano, no puedo liderar un equipo. […] La composición del equipo pesa tanto o más que la experiencia técnica.

Como CTO, si no puedes explicar el valor de forma simple, significa que no entiendes el valor de negocio detrás de tu tecnología.

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 #

TDD vs BDD

2021-09-25T00:00:00+00:00

Estas son dos técnicas diferentes. La clave de cada una está en la mentalidad y el contexto de lo que quieres lograr.

BDD es una “funcionalidad guiada por tests” #

Básicamente, es un desarrollo test-first, donde el enfoque principal es asegurar el comportamiento final esperado, y por lo tanto el resultado de la lógica de software que quieres tener al final.

En BDD el enfoque principal es el comportamiento de tu lógica de dominio que aún no existe. Es, desde un punto de vista abstracto, sobre toda la funcionalidad y los requisitos del dominio.

TDD es sobre el ritmo #

Especifica lo que quieres.
Hazlo funcionar.
Hazlo mejor.

TDD no es solo la ya conocida mentalidad “red-green-refactor”, sino principalmente sobre el flujo de trabajo que te ayuda a entender las constantes decisiones de diseño que haces cada vez para cada lógica que estás diseñando.

TDD es sobre retroalimentación constante de tus decisiones.

En el contexto de OOP (para hacer los ejemplos más claros), siempre hay toneladas de formas diferentes de diseñar tu clase:

¿Cuál es el nombre de la clase de este método?
¿Cuáles son las dependencias o colaboradores de esta clase?
¿Cómo se comportará esta clase cuando use esta otra clase dentro de ella?
¿Cuál es el resultado esperado de este método cuando le doy estos argumentos?
etc, etc…

Hacemos estas preguntas (y muchas más) cada vez, y también les damos una respuesta, pero normalmente sin ningún pensamiento racional o reflexión sobre ello. Simplemente hacemos lo que creemos que es “lo mejor” en ese momento particular enfocándonos en hacer que algo funcione, pero ¿es suficiente hacerlo funcionar?

El bucle de retroalimentación constante #

El testing no es solo una gran herramienta porque te da una red de seguridad para refactorizar con confianza, sino también porque ayuda a diseñar mejor el sistema. ¿Cómo es eso? Porque antes de implementar cualquier solución, te obliga a pensar en las decisiones que necesitas tomar. Te desafías a ti mismo para entender los argumentos de tus decisiones, y por qué A y no B es mejor solución en un contexto particular.

BDD y TDD no son mutuamente excluyentes, de hecho, pueden y deben coexistir. Depende principalmente del contexto de lo que quieres construir y testear.

BDD es sobre desarrollo de funcionalidades Test-First. El objetivo no es el cómo sino el qué. El bucle de retroalimentación es largo porque obtendrás el “verde” una vez que la funcionalidad esté implementada y funcionando como se esperaba.

TDD también es otro desarrollo guiado por Test-First pero, a diferencia de BDD, se trata de un bucle de retroalimentación más corto y rápido.

Primero, especificas lo que quieres. Piensas sobre el diseño de tu clase o método. Su nombre o firma. Sus dependencias. Pero todo esto con pequeños pasos, uno a la vez.
Segundo, haces que esa pequeña cosa funcione de la manera más simple posible.
Finalmente, lo haces mejor. Porque el software es lo suficientemente difícil y complicado como para hacerlo bien al primer intento, así que el refactoring es imprescindible para mantener un sistema saludable. En este punto, con un “test verde ejecutándose”, puedes refactorizar y mejorar tu lógica de forma segura.

Lo anterior es básicamente TDD, cierto, pero… ¿qué tiene de especial? El bucle de retroalimentación constante y las decisiones de diseño que necesitas tomar antes de escribir realmente la solución. Este es el poder de TDD.

¿Por qué pasos tan pequeños en TDD? #

Teóricamente “debes” escribir pequeños pasos para cada iteración, pero ¿por qué? Se trata del bucle de retroalimentación. Esto depende de ti, tus expectativas y tu experiencia con testing.

Recursos #

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.

Phel: el Lisp que Compila a PHP

2021-02-01T00:00:00+00:00

Un nuevo lenguaje de Programación Funcional construido sobre el ecosistema de PHP.

El Lenguaje Phel #

Phel es un lenguaje de Programación Funcional (FP) que compila a PHP. Es un dialecto de Lisp inspirado en Clojure y Janet.

Características #

Construido sobre el ecosistema de PHP
Buenos reportes de errores
Diferentes estructuras de datos (Arrays, Tables y Tuples)
Macros
Funciones recursivas
Sintaxis potente pero simple
REPL

¿Por qué Phel? #

Phel lo creó Jens Haase. Como menciona en el sitio web, “es el resultado de muchos intentos fallidos de hacer programación funcional en PHP”. Buscaba algo con estas características:

Inspirado en LISP
Lenguaje de Programación Funcional
Que funcione en proveedores de hosting baratos
Sea fácil de escribir y depurar

A finales de mayo de 2020 terminé el libro Seven Languages in Seven Weeks, donde aprendí los fundamentos de Prolog, Erlang, Clojure, Haskell… Incluso creé un repositorio en GitHub para guardar mi progreso.

A principios de junio de 2020, vi un post en el canal de PHP de Reddit mencionando este proyecto “Phel”: un lenguaje de programación funcional escrito en PHP.

Llevo unos 8 años trabajando con PHP, y siempre intento combinar OOP con FP (creo que ambos paradigmas funcionan mejor juntos; no son excluyentes). Un nuevo dialecto de Lisp escrito en PHP 7.4 nativo sonaba emocionante. Decidí echarle un vistazo al código.

Las lecturas recientes de Mathias NoBack, como Object Design Style Guide y Advanced Web Application Architecture, me dieron el empuje para aplicar lo aprendido en un proyecto real. Este fue (y sigue siendo) un desafío que me ayuda a crecer profesionalmente.

Mi primer commit fue el 6 de junio de 2020. Desde entonces dedico un poco de tiempo cada día en mis horas libres. Me ayuda a aprender sobre FP, diseño interno de lenguajes, testing y arquitectura de software en general.

Empecé con cambios menores hasta que acabé refactorizando toda la estructura del compilador para hacer los módulos más legibles. Psalm, tipos estrictos, buena cobertura de tests, estilo de código unificado… Estos fueron algunos de mis temas favoritos.

Ejemplo de código Phel #

El siguiente ejemplo da una breve impresión de cómo se ve Phel:

# Define un namespace
(ns my\example)
# Define una variable con nombre "my-name" y valor "world"
(def my-name "world")
# Define una función con nombre "print-name" y un argumento
(defn print-name [your-name]
 (print "hello" your-name))
# Llama a la función
(print-name my-name)

Estado actual de Phel #

Preparamos una fácil Guía de Inicio
Preparamos un Repositorio GitHub fácil con una Plantilla de Scaffolding de Phel
Acabamos de lanzar la primera versión oficial: 0.1.0

Consulta el sitio web oficial con toda la documentación: https://phel-lang.org/

También recomendado #

Functional Programming with Phel - JesusValera

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

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.

Domain-Driven Design Distilled

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

Este libro hace que DDD cobre vida. Da igual si eres desarrollador, consultor o cliente: te ayuda a entenderlo y sacarle provecho.

Desarrolladores de todo el mundo lo están adoptando porque da resultados reales. Es una guía accesible que responde:

¿Qué es DDD?
¿Qué problemas resuelve?
¿Cómo funciona?
¿Cómo sacarle valor rápido?

Aprenderás a separar modelos de dominio con Contextos Acotados (Bounded Contexts), a desarrollar un Lenguaje Ubicuo dentro de cada contexto, y a lograr que expertos de dominio y desarrolladores colaboren para crear ese lenguaje.

También cubre cómo usar Subdominios para manejar sistemas legacy e integrar varios Contextos Acotados definiendo relaciones entre equipos.

Domain-Driven Design Distilled da vida a DDD.

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 #

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

Siete lenguajes en siete semanas

2020-05-21T00:00:00+00:00

El Programador Pragmático recomienda aprender un lenguaje nuevo cada año. Pero si uno por año está bien, ¿por qué no siete en siete semanas?

Este libro te lleva de paseo por Clojure, Haskell, Io, Prolog, Scala, Erlang y Ruby. Aunque tu lenguaje favorito no esté en la lista, vas a ampliar tu forma de pensar al ver estos lenguajes lado a lado. Aprenderás algo valioso de cada uno. Y lo mejor: aprenderás a aprender lenguajes rápido.

Creé este repositorio con todo lo que fui aprendiendo mientras leía y experimentaba con los lenguajes del libro: https://github.com/Chemaclass/7LangIn7Weeks

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.

Agile Limpio

2020-03-12T00:00:00+00:00

Clean Agile viene de Uncle Bob, uno de los padres fundadores de Agile. Fue una de las diecisiete personas que escribieron el Manifiesto Ágil en 2001.

El libro trata sobre Agile: lo que fue, lo que es y lo que será. Es un regreso a lo básico que cubre la historia de Agile, qué lo motivó y qué ha pasado desde entonces. Cubre las prácticas básicas y las compara con la variedad actual de procesos ágiles.

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.

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.

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.