- He hablado sobre cómo elegir programas que puedan usarse durante mucho tiempo y cómo construir una infraestructura confiable, pero reconozco que todavía no lo hago bien
- Durante el último mes reescribí el núcleo de un programa que he usado durante los últimos 2 años, y a través de eso repasé cómo ha cambiado mi forma de programar a lo largo de mi vida
2015
- Desconfiaba de las abstracciones y daba mucha importancia a las pruebas y al control de versiones
- Pensaba que el abuso de las abstracciones y la falta de pruebas/control de versiones eran la causa de los problemas
- Diseñé la plataforma Mu1 con las pruebas y las capas como restricciones fundamentales
2017
- Empecé a rehacer Mu1 para convertirlo en el Mu actual
- Al principio usé todas las ideas nuevas de pruebas y capas, pero poco a poco dejé de usarlas
- Mu tiene muchas pruebas, pero del tipo tradicional, y no porté la infraestructura de capas
2022
- Empecé a trabajar en Freewheeling Apps
- Al principio empecé sin pruebas, pero luego escribí pruebas exhaustivas para la parte central del editor de texto
- El resto era difícil de probar, pero funcionaba bien
2024
- Hace un mes borré todas las pruebas
- Rehice radicalmente el editor de texto de una manera que antes me habría preocupado por conflictos al fusionarlo con otras Freewheeling Apps
- Dejé de preocuparme por el control de versiones
- Renuncié a las pruebas y a las versiones, y terminé haciendo un programa mucho mejor
Mi visión unificada actual sobre la programación sostenible
- Construir de forma sostenible para mucha gente es demasiado difícil, así que ni siquiera deberíamos intentarlo
- La mayor parte del software está contaminada por incentivos para servir a mucha gente en el corto plazo. Hay que enfocarse en software con pocos logos, fácil de construir, con pocas dependencias y sin actualizaciones automáticas
- Pequeños cambios en el contexto pueden alterar de forma fundamental qué tan bien encaja un programa en ese contexto
- Los programas nuevos, de una manera u otra, se adentran en lo desconocido. Muchas veces no sabemos con precisión qué estamos haciendo, en ninguna dirección
- Tipos, abstracciones, pruebas, versiones, máquinas de estado, inmutabilidad, análisis formal, etc., son herramientas que pueden usarse en un terreno que todavía no conocemos bien
- Inevitablemente terminamos usando en exceso algunas de estas herramientas. La cantidad ideal de uso es mucho menor de lo que creemos. Ese exceso de uso es deuda técnica
- Cuando nuestra comprensión del contexto se estabiliza, vale la pena desechar una parte importante del programa y volver a hacerlo desde cero
- Antes de reescribir, hay que tener al mismo tiempo en la cabeza todo lo que queremos del programa y todos los escenarios que debe manejar
- Hay que construirlo todo de una sola vez
- Las pruebas y el control de versiones estorban para llegar al final de esta evolución
- Las pruebas hacen que olvidemos nuestras preocupaciones y el control de versiones nos ata al pasado
Opinión de GN⁺
- Si un programa se vuelve demasiado complejo, puede volverse imposible recordar todo en el paso 8. Esto aplica a la mayor parte del software, especialmente al software escrito por más de una persona
- No todo el software tiene necesariamente que llegar al paso 9. Muchas Freewheeling Apps son lo bastante simples y evolucionan lo bastante lentamente como para estabilizarse sin errores con solo unos pocos usuarios, sin importar las decisiones iniciales de diseño
- El diseño orientado a datos es claramente útil para llegar al paso 9. No es una herramienta que pueda aplicarse ciegamente, sino una forma de pensar que mira el panorama general de cómo un programa accede a los datos, más allá de las immediate data structure choices
- Puede que estos pasos no sean del todo correctos. Puede que esté subestimando herramientas con las que tengo menos experiencia
- Me pregunto qué etapas podrían existir más allá de estas
1 comentarios
Opiniones en Hacker News
Sin pruebas, no ves los problemas y parece que desaparecen
Al renunciar a las pruebas y a las versiones, obtuvo un mejor programa
Al principio pensé que el autor estaba equivocado, pero hay buenas observaciones
El control de versiones y las pruebas automatizadas resuelven problemas reales
Al escribir/refactorizar programas grandes, es importante escribir, desechar y volver a escribir
Este artículo es confuso
Un cambio pequeño puede alterar mucho la adecuación de un programa
Hacer software en solitario y hacerlo en equipo son cosas completamente distintas
En 2022 empecé a trabajar en Freewheeling Apps
No estoy de acuerdo con que un cambio pequeño pueda alterar mucho la adecuación de un programa
Me gusta el autor y me gusta el proyecto Mu
Me abruma la complejidad de la ingeniería de software