Tachyon es un proyecto de software de alto rendimiento, y como todo sistema complejo, sus desarrolladores han tomado una serie de decisiones de arquitectura cruciales a lo largo del tiempo. El repositorio de GitHub que se describe contiene los 'Architecture Decision Records' (ADRs) de Tachyon. Un ADR es un documento que registra una decisión de diseño específica, el contexto que la motivó y las consecuencias que tuvo (o se esperan que tenga). Piensa en ellos como un 'diario de diseño' que explica el 'por qué' detrás de las elecciones técnicas.
¿Por qué son importantes los ADRs? Sin ellos, el conocimiento sobre las decisiones de diseño clave se pierde con el tiempo, especialmente en proyectos grandes con muchos desarrolladores. Los ADRs facilitan la comprensión del sistema, ayudan a evitar la toma de decisiones contradictorias en el futuro y sirven como una valiosa fuente de información para nuevos miembros del equipo.
¿Cómo funcionan? Cada ADR sigue una plantilla estandarizada. Comienza con el 'Context', que describe el problema que se estaba intentando resolver, las limitaciones existentes (como versiones específicas del kernel o restricciones de APIs) y las fuerzas que influyeron en la decisión. Luego, se presenta la 'Decision' en sí misma: una declaración clara y concisa de la elección realizada, junto con la justificación. Finalmente, la sección 'Consequences' analiza los efectos positivos, negativos y neutrales de la decisión. Un aspecto clave es que los ADRs nunca se eliminan. Si una decisión es reemplazada por otra, el ADR original se marca como 'Superseded' y se enlaza al nuevo ADR, creando una línea de tiempo de la evolución del diseño.
Ejemplos concretos de decisiones registradas: El repositorio menciona ADRs sobre la elección entre memfd_create y shm_open para la gestión de memoria compartida (ADR-002), la comparación entre futex y eventfd para la sincronización (ADR-003), y la alineación de mensajes (TACHYON_MSG_ALIGNMENT = 64, ADR-004). Otro ADR (ADR-005) aborda el uso de 'SCM rights' frente a 'named mmap', mientras que ADR-006 trata sobre la ausencia de un contrato de serialización.
Consideraciones: El estado de los ADRs puede ser 'Proposed' (en discusión), 'Accepted' (implementado), 'Superseded' (reemplazado) o 'Deprecated' (desaconsejado). Es importante revisar el estado de cada ADR para comprender su relevancia actual. Los ADRs de Tachyon ofrecen una ventana a la toma de decisiones de diseño de un proyecto de alto rendimiento, proporcionando información valiosa para desarrolladores, arquitectos y cualquier persona interesada en comprender la complejidad de los sistemas de software.