¿Cómo puedo hacer que mi código sobreviva? (anti software rot)

Question

mirando hacia atrás en mi carrera de programación. He hecho muchas cosas. Pero desafortunadamente, mucho de eso ya no funciona.

conseguir el código para volver a compilar, resulta ser complicado, así:

• Las bibliotecas son anticuados (ya no funcionan, actualizado a las versiones más recientes que son incompatibles con las versiones 5 versiones de respaldo)
• Incompatibilidades del sistema operativo
• hardware cambiado (tarjeta de video, tarjeta de sonido, etc.)
• Incluso rareza del compilador. (Las cosas viejas hechas en Watcom, simplemente no se compilan de fábrica en Visual Studio 2008)

En realidad. Esta comprensión me deprimió un poco.

Aquí estamos, todos los días diseñando y programando nuestros pedacitos más inteligentes de programas, y en pocos años ya no funciona (aparte del hecho de que es probablemente superado por otro programa de software que es aún más inteligente)

Si fuera un constructor. Yo pondría ladrillos en otros ladrillos. Y 80 años después, caminaría por la ciudad con mi nieto. Señala una casa y di: Mira chico ... tu abuelo hizo esto.

Así que mi pregunta:

¿Cómo puedo asegurar que mi software sobrevive a la prueba del tiempo?

¿Algún idioma especial debería trabajar? ¿Algún sistema operativo dado que sea más adecuado para esto que otro?

Cualquier idea bienvenida!

Answer 1

• como base los marcos/bibliotecas/plataformas que tienen un historial sólido.

  Algunas proyecto que acaba de hacer estallar la semana pasada es probable que todavía va a cambiar drásticamente o desaparecer por completo pronto. Busca algo que haya sido estable por un tiempo.

• Elija una plataforma que parezca que va a funcionar por un tiempo.

  Lo que significa que debe estar respaldado por una gran empresa que tiene bastante interés en la tecnología, o es una plataforma de código abierto que parece que va a mantenerse por un tiempo.

• Escribir código de limpieza.

  Evita los cortes a toda costa, escribir código de libro de texto, utilice sólo llamadas API oficial.

• No se base en el comportamiento no documentado. (según demanda popular)

  Si la documentación no dice que debería estar haciendo esto, no lo use, podría dejar de hacerlo eventualmente.

• Observe las API desaprobadas o las que parecen ser candidatas a desaprobar.

  Nunca uses el anterior, pregunta a los dioses por este último.

• Stay en el bucle y mantener.

  A pesar de todas las precauciones, que prácticamente sólo se puede mantener de forma activa su aplicación para que siga funcionando. Mientras mejor sea el trabajo que haga en los otros puntos, necesitará menos mantenimiento.

Answer 2

1. Presupuesto una cantidad específica de tiempo para dedican a la fijación de los problemas de actualización cada vez que se actualiza algo.
2. Las actualizaciones son las primeras en el modo de prueba/evaluación. Solo después de validados se aceptan como el nuevo estado oficial de su sistema.

En un proyecto que estaba en que se negaron a utilizar la última versión de Borland C++ sólo porque no cumplía uno de los requisitos, en relación con el orden alfabético de las cadenas con caracteres internacionales ('ñ', 'ç') . Nos apegamos a la versión anterior porque simplemente necesitábamos esa característica.

Answer 3

A menudo es una cuestión de buen diseño de la biblioteca, si sus desarrolladores pensaban en compatibilidad con versiones anteriores o no.

En ocasiones, le corresponde a usted leer la documentación y no utilizar las soluciones rápidas que están marcadas con "sujeto a cambios en el futuro".

Si puede, mantenga las versiones exactas de los componentes de terceros que estaba utilizando junto con sus proyectos.

En cuanto al lenguaje de programación o sistema operativo que utiliza, en realidad no importa. Más importante es limitar las dependencias en componentes de terceros o en tecnologías experimentales pero no maduras.

Answer 4

Dudo que un moderno UNIX contiene cualquiera de código original de Ken Thompson (Linux desde luego no lo hace) pero todavía es conocido como el creador de UNIX. La razón por la que la descomposición del código afecta a las bases de código se debe a que las personas dejan de usar el código compilado, por lo que no hay más razón para mantenerlo. Por lo tanto, si desea poder comunicarles algo a sus nietos, deben idear un concepto (no solo el código) que las personas quieran usar en 40 años más o menos. Y eso es difícil.

Answer 5

Los edificios permanecen durante mucho tiempo porque se mantienen. Cuando no hay gente alrededor, los edificios no durarán mucho (mira el themepark in Tsjernobyl abierto nunca). Para el software es simular, pero tanto la construcción como la degradación pueden ir mucho más rápido.

Asegúrese de que el software se construye es * valiosa para la sociedad * es de código abierto (para que otros puedan hacerse cargo de la tarea de rejunivation; actualizar el código para el mundo y bibliotecas disponibles) O que mantienen el ambiente en el cual funciona vivo; pero esto no será fácil.

Es mucho más fácil hoy en día mantener vivos los artefactos binarios; la virtualización y la emulación son muy buenas ahora.Puede emular un C64 en su máquina Wintel multi-Ghz-multi-core

¡Buena suerte!

Answer 6

Entregue su software como virtual appliance. Siempre que el proveedor de VM proporcione una ruta de actualización para mantener en funcionamiento las imágenes de VM antiguas, su software seguirá funcionando. Puedes hacer lo mismo para tu entorno de desarrollo.

Los proveedores de sistema operativo se enfrentan a problemas similares porque quieren mantener el software existente ejecutándose en las nuevas versiones de su sistema operativo. Ellos también se han virtualizado para lograr esto (por ejemplo, Windows XP mode for Windows 7).

Answer 7

En resumen, pensar multiplataforma!

Una empresa para la que solía trabajar usé C++ para desarrollar algunos subsistemas de software. En lugar de utilizar un único compilador de proveedor (que sería gcc), se utilizó un compilador diferente para cada plataforma (gcc para Linux, compilador de HP para HP-UX y compilador de Sun para Solaris). Esto obligó al código a escribirse de una manera que no utilizara características no estándar del compilador favorito; otro beneficio adicional fue que cada compilador dio advertencias diferentes para hacer aún más resistente a la putrefacción del software. También la parte de Java del software se ejecuta en JVM diferente por lo que las pequeñas inconsistencias de escriben una vez que se ejecuta en todas partes principio se detectaron y se repararon.

Así que si su lenguaje es soportado por múltiples implementaciones del intérprete o compilador o tiempo de ejecución, incluso si no planea usar otro que no sea uno para producción, puede usar esas otras implementaciones para validar su software .

También puede desarrollar su software para que se ejecute en múltiples plataformas, aislando las partes específicas de la plataforma detrás de las API diseñadas conceptualmente y tan compactas como sea posible (puede hacerlo incluso si se dirige a una única plataforma).