Citas de desarrolladores: código, MCU, diseño de circuitos

## Aforismos de Desarrolladores: Sabiduría de Stand-ups y Revisiones de Código

A lo largo de los años en el desarrollo embebido, se acumula una colección de frases que ascienden a la categoría de aforismos. Capturan las realidades de la programación de microcontroladores, el diseño de circuitos y la gestión de proyectos. Aquí va una selección de 12 años de experiencia práctica: desde principios de código hasta periféricos de MCU.

Aforismos sobre Código y Arquitectura

Los programadores se dividen en dos bandos: los que escriben código desde cero y los que portan bibliotecas open-source. La universalidad de la computadora como dispositivo de cómputo es la definición de libro de texto, aunque no todos los graduados en física y tecnología la aceptan.

Principios clave:

• Hay una config para todo: el mejor código es pura configuración.
• Código por separado, configs por separado.
• El buen código se cristaliza con los años.
• Principio de mínima sorpresa al escribir.
• El mejor algoritmo es una tabla (una máquina de estados finitos se reduce a un grafo y una tabla).

«Programar es una maratón, no un sprint.» (Robert Martin)

La uniformidad del código prima sobre la belleza: «Escribe código uniformemente, feo está bien». Los arrays son la base de todo. Todo setter necesita un getter: xxx_write() exige xxx_read(). El nombre de una función es su comentario. Menos comentarios de texto significa diffs más limpios en git.

En C: si una función no cabe en una pantalla, probablemente no funciona. Cualquier tarea se resuelve en una línea: una llamada a función. El mejor comentario es el nombre del archivo.

Pruebas y CI/CD

Un repo sin CI es solo papel de desecho. El sistema de build debe ser uniforme, sin importar el editor. ¿Código sin pruebas unitarias? Lo mismo.

«Un programa que no se ha probado no funciona.» (Bjarne Stroustrup) «TDD es la elección de los profesionales.» (Robert Martin)

El conocimiento se transmite por escrito para transiciones suaves. Un codebase portable es la base de proyectos futuros. Todos los protocolos se reducen a memcpy entre dispositivos.

Diseño de Circuitos y Hardware

Los del hardware bromean: sé como una CPU, rechaza el sobrevoltaje. La ingeniería eléctrica es la ciencia de las conexiones que faltan. El desarrollo empieza con herramientas de debug.

Todos los sensores miden temperatura, cada uno a su manera. Por encima de 100 MHz, las señales se vuelven analógicas. Todo en electrónica es un ADC o DAC: códecs, transceptores, incluso GPIO como DAC de 1 bit.

Elección de interfaces: SPI gana a I2C. Los rusos diseñan placas para código europeo, los europeos escriben código para placas chinas. La mejor pieza es no tener pieza.

Microcontroladores y Firmware

Primero el hardware, luego el software. Cuanto más simple el esquema, más complicada el firmware, y viceversa. Firmware sin hardware es como esculpir a partir de una foto.

Los periféricos se sincronizan con el reloj del núcleo. El firmware empieza con un bootloader. Un reset arregla siete males. ¿La función asesina? Actualizaciones de firmware.

Los protocolos universales se multiplican: de 12 a 13. El assembler es como comer alforfón con pinzas. NVRAM eleva cualquier cosa. UART-CLI es imprescindible: sin él, es enchufar y rezar.

Los logs de UART son la caja negra del firmware. Un MCU es un mortero para moler números; x86 es una licuadora. CLI enciende la creatividad, GUI te encajona. Las máquinas de estados finitos son el martillo de oro para MCUs.

Un MCU decente necesita: temporizador de uptime, LED de heartbeat, UART-CLI, NVRAM, pruebas unitarias. Si no, es una cadena inútil. El firmware no se escribe solo.

Modularidad significa construir para múltiples plataformas a la vez.

Gestión y Proyectos

Lo construimos no porque sea simple, sino porque creímos que lo era. La mitad de lo que enseñan es tontería; el truco es saber cuál (Ley de Larrabee).

Desarrolla según la spec: nada de dorados. Negociar es el trabajo. ¿«No hacer nada» por solicitud? Tarea completada.

«Un resultado negativo sigue siendo un resultado.» (Niels Bohr)

Una mala solución con buen informe se elimina tarde o temprano; una buena con mal informe muere a la vista (Ley de Akin). Gestionar es quitarse de en medio.

Los compromisos de calidad se equilibran positivamente. No le pongas un tanque de gasolina a un perro. Mejor encontrar el bug ahora que en el estante. ¿Lluvia de ideas? Solo asado de ideas.

Construye no lo que piden, sino lo que necesitan. Lo perfecto es enemigo de lo bueno. Las cosas malas pasan solas. Rápido y chapucero se recuerda como chapucero; lento y sólido se queda como sólido (Korolev).

Lo Importante

• El código debe ser portable y testable: TDD, pruebas unitarias, CI unificado.
• En embebido: UART-CLI, logs, máquinas de estados finitos: lo esencial para debug.
• Hardware primero: placas simples facilitan el software.
• Proyectos según spec, docs por escrito.
• Planificación de sucesión: conocimiento capturado, repo impecable.

— Editorial Team