80 puntos por GN⁺ 2025-08-26 | Aún no hay comentarios. | Compartir por WhatsApp
  • Estoy tratando de mejorar mis habilidades de diseño de software y me recomendaron estudiar bases de código existentes y bien diseñadas
  • Me pregunto cuáles de las bases de código con acceso público son consideradas el estándar de oro del diseño de software

1. Bases de código recomendadas

  • Proyectos grandes/representativos
    • Git, Postgres, CPython
    • El "modelo de tenientes" del kernel de Linux
    • UNIX v6, BSDs
  • Frameworks/bibliotecas
  • Sistemas/servidores
  • Juegos/casos especiales
  • Materiales educativos/de aprendizaje
  • Otros
    • Monocypher (biblioteca de criptografía)
    • Implementación del lenguaje Tcl

2. Leer código vs aprender de documentación/diseño

  • Límites de solo leer código
    • Una base de código muestra la implementación, pero oculta la intención del diseño y los trade-offs
  • Importancia de los documentos de diseño
    • Los registros de decisiones como ADR (Architectural Decision Records), los RFC de Rust y los PEP de Python son mucho más útiles para aprender diseño
    • Escribir documentos de diseño por sí mismo también puede ser un entrenamiento
  • Libros y referencias recomendados

3. Enfoque de aprendizaje centrado en la práctica

  • Experiencia y prueba/error
    • El diseño se aprende enfrentando problemas repetidamente y aprendiendo a evitarlos
    • Solo leer código no basta; se aprende escribiendo, fallando y resolviendo esos fallos
  • Aprendizaje guiado por el interés
    • Uno aprende más a fondo cuando construye proyectos que realmente le interesan
  • Bajo costo del fracaso
    • En software, el costo de fallar es más bajo que en la ingeniería física, por lo que aprender intentando y fallando funciona bien

4. Debate sobre la naturaleza de la ingeniería de software

  • Postura de ingeniería inmadura
    • Que cinco ingenieros propongan cinco soluciones distintas es visto como evidencia de inmadurez como disciplina de ingeniería
  • Postura de afinidad experimental
    • El software tiene menos restricciones, por lo que existen muchas soluciones posibles y no hay una respuesta fija como en la ingeniería física
  • La frontera entre arte e ingeniería
    • El diseño también puede ser un acto artístico con elementos estéticos, pero es ingeniería en la medida en que satisface requisitos funcionales
    • El software se ubica entre la flexibilidad artística y el rigor de la ingeniería

5. Métodos alternativos de aprendizaje

  • Analizar código malo
    • No solo estudiar código bien diseñado, sino también arreglar bases de código deficientes produce un gran aprendizaje
  • Aprender de tu propia base de código
    • La base de código del equipo interno fue mencionada como una de las fuentes de aprendizaje más valiosas
    • Eso sí, si el código del equipo es deficiente, conviene complementarlo con ejemplos externos
  • Aprendizaje ajustado al dominio
    • Leer bases de código parecidas al tipo de problema que quieres resolver es lo más efectivo

Ideas clave

  • Las bases de código bien diseñadas ayudan, pero el aprendizaje debe ir acompañado de entender la intención del diseño y pasar por prueba y error
  • Más que la lectura de código en sí, los documentos de diseño y los registros de decisiones son el material de aprendizaje clave
  • Proyectos representativos y de alta calidad (Git, Postgres, CPython, la std de Rust, etc.) tienen un gran valor educativo
  • No solo se aprende de buen código, sino que aprender de código deficiente y del propio código resulta más práctico a largo plazo

Resumen de comentarios principales

Recomendaciones de bases de código destacadas (CraigJPerry)

  • Servidor de correo Postfix
    • Su arquitectura centrada en la seguridad mostraba una estructura similar a los microservicios incluso antes de que existiera ese concepto
    • Mientras los microservicios modernos se enfocan en la distribución a gran escala entre organizaciones, Postfix fue diseñado para seguridad y simplicidad
  • Spring Framework
    • Refleja una cultura que consideró profundamente las necesidades de los desarrolladores Java en entornos empresariales
    • Permite aprender un enfoque de diseño centrado en el usuario
  • Git
    • Si se entienden la base de datos de objetos (blob, tree, commit) y el concepto de referencias, el resto es una expansión gradual
    • Se presenta como un buen ejemplo de diseño basado en la extensión coherente de conceptos centrales
  • Varnish
    • Un proxy reverso de alto rendimiento con una base de código tan bien organizada que también sirve como herramienta de aprendizaje
  • Modelo de tenientes del kernel de Linux
    • No es una base de código, pero vale la pena como modelo de gestión de software a gran escala
  • Más que simplemente "código bien diseñado", son ejemplos en los que las decisiones de diseño dejan una fuerte impresión

Énfasis en aprender de bases de código reales de trabajo (crystal_revenge)

  • El mayor valor de aprendizaje puede obtenerse de la base de código de tu propio equipo
  • En el proceso confuso que conecta requisitos reales con la implementación, se experimentan al mismo tiempo buenas y malas decisiones
  • La restricción más importante en la práctica es la presión de tiempo, y lo clave es aprender a equilibrar entre el diseño ideal y la realidad
  • El buen software es aquel que resuelve las necesidades del usuario, y con la experiencia repetida uno aprende diseños que aumentan las probabilidades de éxito

Enlaces a debates y materiales previos (sprobertson)

Código vs documentos de diseño (alphazard)

  • Una base de código es solo el resultado de la implementación, no el diseño en sí
  • Para aprender diseño, es más efectivo escribir documentos de diseño
    • Los documentos deben ser lo bastante claros como para que otra persona pueda implementar exactamente lo mismo
    • Enumerar alternativas y registrar por qué fueron descartadas deja evidencia de las consideraciones de diseño
  • Un buen diseñador es alguien que considera un espacio de diseño más amplio y elige el punto adecuado dentro de él

Énfasis en entender el sistema completo (RossBencina)

  • El proceso de entender una base de código completa tiene mucho valor
    • No solo entrena para reconocer código bien diseñado, sino también para ver el panorama general del sistema
    • Visualizar relaciones con diagramas como UML puede ayudar
  • Enfoque de aprendizaje:
    • Es útil leer código de software parecido a lo que uno está desarrollando
    • Como punto de partida, se recomiendan bases de código de dominios que ya conoces bien (frameworks web, servidores web, biblioteca estándar de Python, VSCode, etc.)
    • Al principio, conviene empezar por programas pequeños y dominios familiares

Criterios de un buen diseño (mamcx)

  • Un buen diseño son los objetivos y las ideas; la base de código muestra hasta qué punto fueron implementados
  • Un buen diseño no debe limitarse a adjetivos como "rápido" o "seguro", sino incluir consideraciones concretas y registro de trade-offs
  • Casos observables de esto: Erlang, Pascal temprano y muchos diseños de RDBMS
  • La biblioteca estándar de Rust enfatiza seguridad y consistencia, y su código y documentación lo reflejan fielmente, por lo que es un buen material de aprendizaje

Decisiones de diseño invisibles (ben30)

  • Al mirar una base de código bien diseñada, la parte más importante es lo que no se ve
    • Decisiones de ausencia, como excluir complejidad, evitar abstracciones innecesarias o rechazar ciertos patrones, son clave
  • Para complementar eso, se pueden usar ADR (Architectural Decision Records)
    • Registran alternativas, motivos para descartarlas y fundamentos de la elección, preservando el contexto
    • Son de gran ayuda tanto para futuros mantenedores como para herramientas de IA
  • Al aprender, es efectivo revisar proyectos que, además del código, también incluyan documentos de decisiones de diseño como ADR, RFC o PEP

Aún no hay comentarios.

Aún no hay comentarios.