language-agnostic

language agnostic - ¿Cuánto tiempo dura el código?



language-agnostic (24)

Estoy en el proceso de volver sobre algunos de los TODO menores en mi código. Uno de ellos pertenece a una clase que maneja fechas parciales, por ejemplo, enero de 2001. Funciona bien para fechas que se verán en nuestro sistema (1990 - 2099) y falla elegantemente para otras fechas.

El TODO que me he dejado es que no manejo fechas en el siglo 2100 y más allá. Realmente no creo que valga la pena el esfuerzo para solucionar este problema en particular, pero conozco los errores Y2k. Si estuviéramos en 2080, creo que estaría pensando de otra manera y solucionaría el error.

Entonces, ¿cuánto tiempo dura el código? ¿Qué tan lejos debemos planificar para que nuestros sistemas sigan funcionando?

Actualizar

Ok, gracias por todas tus aportaciones. Creo que voy por la opción de dejar TODO en el código y no hacer nada. Los pensamientos que encontré más interesantes fueron:

  • @Adrian - Eternidad, creo que esa es la suposición más correcta, tu punto sobre VM es bueno.
  • @ jan-hancic - Depende, sí lo hace.
  • @ chris-ballance - Supongo que voy a estar muerta para cuando se aplique esta restricción, para que puedan venir a profanar mi tumba si así lo desean, pero estaré muerto, así que solo lo atormentaré.

La razón por la que decidí no hacer nada fue simple. Agregó valor de negocio insignificante, las otras cosas que necesitaba mirar agregaron valor, así que las haré primero y si tengo tiempo las arreglaré, pero realmente no será nada más que un ejercicio académico.

3-5 años máx. Después de eso, te cambiaste a otro trabajo y dejaste tu código de mierda.

Algunas veces, el código dura más de lo que piensas. Pero, más importante es el argumento de la pendiente resbaladiza . Una vez que te perdones a ti mismo un poco de antibalas, es posible que tengas la tentación de optimizar aún más y escatimar en la corrección lógica, hasta que finalmente te muerda.

Por cierto, recomiendo tener un ID de problema (como el número de caso FogBugz) en cada comentario TODO, para que la gente pueda suscribirse y hacer un seguimiento de TODO.

Aquí están mis dos centavos:

Cuando diseñamos un proyecto, solemos declarar que dura "al menos" 5 años. Por lo general, no más de 10 años antes de rediseñarlo y construirlo de nuevo. (Estamos hablando de proyectos de tamaño medio-grande aquí).

Lo que generalmente ocurre es que el nuevo proyecto que construye debe reemplazar al anterior, ya sea tecnológicamente (es decir, pasar de MF a Windows, VB a .net, etc.), pero este proyecto nunca termina. Entonces su cliente termina trabajando con 2 sistemas a la vez y ese sistema sobrante es lo que luego se conoce como "legado".

Si espera lo suficiente, se levantará un tercer proyecto que causará que el cliente trabaje con 3 sistemas a la vez y así sucesivamente ...

Pero para responder a su pregunta, apostaría de 5 a 10 años antes del rediseño, y a menos que se suponga que las fechas sean largas en el futuro, no debe preocuparse por la limitación del 2100.

Bien, recientemente hicimos un formato de marca de tiempo donde el tiempo se almacena en un entero de 64 bits sin signo como microsegundos desde 1970. Durará hasta el año 586912, que debería ser suficiente.

No es necesario codificar para "para siempre"; por supuesto, podría usar BigIntegers y todo eso, pero ¿por qué? Solo prepárate por más de 5 o 10 años. El código de producción de hace veinte años no es del todo inusual hoy en día, y sospecho que el ciclo de vida promedio será aún mayor en el futuro cercano.

Hasta el momento en que se rompe, o deja de ser útil, y luego por un poco más de tiempo después de eso

Hay ejemplos de código que se ejecuta en máquinas antiguas que tiene 40 o 50 años.

(Bits interesantes en este hilo: http://developers.slashdot.org/developers/08/05/11/1759213.shtml ).

Tienes que preguntarte sobre la naturaleza del problema que estás resolviendo, pero en términos generales, incluso las "soluciones rápidas" estarán disponibles durante años, por lo que podrías estar buscando una década o más para un código que tenga una vida útil aceptable. .

Las otras cosas en las que debes pensar es:

1) ¿Cuál es la "vida activa" de la aplicación, es decir, dónde se usará y procesará?

2) ¿Cuál es la "vida inactiva" de la aplicación? Es decir, no va a ser utilizada día a día, pero podría utilizarse para recuperar y ver los registros antiguos. Por ejemplo, la ley de auditoría del Reino Unido significa que los registros deben estar disponibles durante 7 años, por lo que es potencialmente 7 años desde el último uso del sistema.

3) ¿Cuál es el rango de datos futuros que necesita manejar? Por ejemplo, diga que está reduciendo las fechas de vencimiento de la tarjeta de crédito: puede tener una tarjeta que no caducará durante una década. ¿Puedes manejar esa fecha?

Las respuestas a estas preguntas generalmente lo llevarán a la suposición de que nunca debe escribir a sabiendas un código que tenga restricciones de fecha más allá de las que dicta el sistema operativo / idioma que utiliza.

La pregunta no es "¿Cuánto dura el código?" sino más bien "¿Cuánto tiempo afectarán las cosas en mi código a una aplicación?"

Incluso si su código es reemplazado, es posible que sea reemplazado por un código que haga exactamente lo mismo. Hasta cierto punto, esta es la causa directa del problema Y2K. Más al punto, es la causa directa del problema Y2038 .

Más de lo que esperabas

No creo que el código dure tanto. Piense en todos los inventos y progresos realizados en los últimos 90 años.

En 2100 no tendremos que escribir el código. Habrá algún tipo de interfaz cerebro-máquina.

No puedes tener una respuesta general aquí. Depende del tipo de proyecto que estás construyendo. Si está escribiendo software para una sonda espacial, es posible que desee codificarlo para que funcione durante los próximos 100 años y más. Pero si está programando una oferta especial de Navidad para la página web de su compañía, unas pocas semanas deberían ser suficientes ...

Asuma que quien quiera que mantenga el código es un psicópata y tiene su domicilio particular .

Depende de cuánto valor comercial tiene el código y de cuánto recursos se necesita para escribirlo desde cero. Mientras más valor y recursos, más dura. Diez años y más es típico para el código comercial "funciona, no lo toques".

En mi humilde opinión todo se reduce a la artesanía: el orgullo que tomamos en nuestro trabajo, la codificación de un estándar que no nos avergonzaría otro codificador real para ver.

En el caso de fechas como esta, ha declarado que gracefully fails después de 2100. Esto parece que puede eliminar TODO sin mala conciencia, porque ha creado una respuesta que permitirá diagnosticar fácilmente la causa de la falla. y se fija en la circunstancia (aunque probable o improbable) de que se produzca una falla.

Eternidad.

Dada la tendencia que el sistema antiguo sigue ejecutando en las máquinas virtuales, debemos suponer que todo código útil se ejecutará para siempre. Hay muchos sistemas que se ejecutan desde los años 60, por ejemplo, el código de backend en el sector financiero, y parece que no hay indicios de que estos sistemas alguna vez serán reemplazados. (Y mientras tanto, la interfaz se reemplaza cada dos años con la última moda en tecnología web. Por lo tanto, cuanto más cerca esté el código de su sistema, más probabilidades tendrá de que funcione para siempre).

Mi tienda actual tiene una gran base de código que ejecuta aplicaciones financieras con reglas comerciales complejas. Algunas de estas reglas están codificadas en procedimientos almacenados, algunas en desencadenantes y otras en código de aplicación de 3gl y 4gl. Se está ejecutando código de finales de los 90, y nada de eso en sus lenguajes heredados "tradicionales" como COBOL o FORTRAN. Como se podría imaginar, es una pila humeante de código de spaghetti, la mayoría creada antes de que TDD significara algo, por lo que las personas son reacias a tocar cualquier cosa.

Nadie realmente sabe. La programación profesional ha existido durante 30-40 años, por lo que nadie sabe realmente si el código va a durar 100 años. Pero si el error del Y2K es una indicación, es que una gran cantidad de código se mantendrá por mucho más tiempo del previsto por el programador. Tenga en cuenta que incluso si toma eso en cuenta, aún podría permanecer por más tiempo de lo esperado. No importa cuánto se prepare, aún podría sobrevivir a su expectativa de vida.

Mi consejo es no planear que el código dure 100 años. En su lugar, intente asegurarse de que todo su código funcione durante el mismo período de tiempo, es decir, parte de él no debería fallar en 2 años, mientras que la otra parte debería fallar en 100 años. Recuerde, siempre debe arreglar primero el enlace más débil, por lo que no tiene sentido fortalecer el enlace más fuerte.

Siempre traté de codificar, ya que mis aplicaciones deben funcionar "para siempre". Estoy muy seguro de que ya no estaré en 2100, pero saber que mi software tiene una compilación en la fecha de vencimiento no me hace sentir bien. ¡Si conoce tales cosas, intente evitarlas! Nunca lo sabrás, pero algún programador desconocido en el futuro puede estar agradecido.

También tenga en cuenta lo que quiere decir por último.

Por ejemplo, el funcionamiento original de UNIX se desarrolló hace 30 años. Pero durante esos 30 años, el producto ha evolucionado con el tiempo.

Sin embargo, no me sorprendería si todavía existe un poco de código original hoy en día.

Así que piénselo de 2 formas ... 1) ¿Alguna vez ha antisipado el código que se va a tocar en el futuro, 2) el producto / código evolucionará si tiene soporte e implicación?

Las cosas esenciales son:

  1. ¿Qué tan bueno es su clase de fecha interna (obtener una versión de biblioteca muy robusta y atenerse a ella!)

  2. No es solo el paso del tiempo, sino también el crecimiento en el rango de entradas que sus usuarios desean. Por ejemplo, tal vez ahora tenga entradas hipotecarias a 30 años, pero el próximo mes alguien decide ingresar un contrato de arrendamiento de 99 años con vencimiento en 2110, o un bono de 100 años en Disney.

Si acepta entradas de 2 dígitos anuales con una ventana de fecha, piense detenidamente sobre cómo se aplica a las fechas de inicio y finalización, y proporcione muchos comentarios inmediatos.

Tuve la oportunidad de contratar un contrato de más de una década después del hecho para consultar sobre el cambio de código a una nueva plataforma (¡OS / 2 simplemente no es tan popular en estos días!). En caso de duda, suponga que su código vivirá más de lo que usted lo hará. Por lo menos, documente las limitaciones de esta manera; arréglelos a menos que eso requiera mucho más trabajo que documentarlos.

En 1995 comencé a trabajar en un nuevo trabajo, en una base de código de 8 años. Entonces, la fecha de entrada fue en 1987 o más o menos.

El código probablemente aún esté en servicio . Eso es que? 23 años.
Ha habido algunos movimientos de la compañía, pero probablemente hayan conservado el software (porque funciona). Si todavía está en servicio ahora, todavía estará en servicio en una década más o menos.

No es sorprendente, especialmente el código de alta tecnología, en C (en su mayoría)

En 1999 comencé en un nuevo trabajo, el código base tenía antecedentes en 1984. La nueva versión que diseñé en los 2000 todavía está en servicio, con elementos de diseño como formatos de archivos de datos del anterior (y así sucesivamente) y eso Sería un programa de desarrollo durante 26 años.

Así que el problema del año 2086 está comenzando a asomar un poco ya que esos 32 bitios firmaron que time_t se voltee.

Recuerde que uno de los principales bonos de la programación moderna es la reutilización.

Entonces eso significa que el código que escribes originalmente para resolver un problema puede ser reutilizado y utilizado en un escenario completamente diferente años después (tal vez incluso sin tu conocimiento, por un compañero de equipo).

Como nota al margen: una de las principales ventajas de las pruebas unitarias automatizadas es el código de prueba que ni siquiera puede recordar si está en un sistema. :)

Mientras la gente pueda seguir facturando por el apoyo con personas dispuestas a pagar por ello.