Código de pruebas futuras

Cuando trabajo, los desarrolladores siempre me dicen que "agregué esto por si acaso para el futuro" o "creo que es una buena idea hacerlo porque probablemente algún día lo deseen". Creo que es genial que sean proactivos al tratar de anticipar cambios futuros, pero no puedo evitar pensar que es innecesario y corre el riesgo de escribir código que puede no ser necesario y, por lo tanto, improductivo (también creo que algunos desarrolladores solo quieren probar algo nuevo por el bien de él). ¿Son inválidos los argumentos para futuras pruebas si solo escribe un código bien organizado y limpio?

Bueno, antes que nada, hay algunas cosas que necesitan aclaración:

• La prueba futura no es agregar cosas.
• Las pruebas futuras se aseguran de que pueda agregar fácilmente código / características sin romper la funcionalidad existente.

Esto significa que escribir código "a prueba de futuro" es garantizar que el código se escriba de manera acoplada, lo suficientemente abstracta, pero también código que no oculte completamente los niveles de abstracción, por lo que siempre hay una manera de ir a los niveles de abstracción más bajos si necesario.

Escribir código de prueba futura es un arte en sí mismo y está estrechamente relacionado con prácticas SÓLIDAS para el control de versiones de componentes, separación de preocupaciones, estratificación y abstracción de funcionalidad. Las pruebas futuras no tienen nada que ver con agregar características con anticipación, sino con asegurarse de que puede agregar características en el futuro de una manera ininterrumpida , a través del buen diseño de código / bibliotecas existentes.

Mi 2c

No escriba código que no se utilizará durante mucho tiempo. Será inútil ya que lo más probable es que no se ajuste a las necesidades en ese momento (que, por definición, aún no conoce).

Haga que el código sea robusto frente a situaciones de problemas inesperados que permitan una recuperación elegante o rápida, pero no escriba código para posibles usos futuros.

Una buena manera de garantizar eso es utilizar un diseño y desarrollo basados ​​en pruebas. Los casos de prueba se derivan de la especificación y los casos de uso. Todo el código debe pasar una prueba. El código innecesario no debe escribirse. Al hacerlo de esta manera, es simple determinar si es necesario o no.

Es importante darse cuenta de que hacer que el código sea a prueba de futuro y escribir código en caso de que sea necesario en el futuro son dos cosas muy diferentes. Lo primero es crucial para una buena aplicación, lo menor generalmente no es una buena práctica de codificación.

• Para mí, la prueba futura del código es escribirlo de manera que pueda interactuar con tecnologías en evolución. Esto implica modularizar su código, de modo que cada parte de su aplicación pueda interactuar independientemente del lenguaje y la tecnología de la aplicación como un todo. Un buen ejemplo de esto sería usar XML o JSON para pasar datos entre diferentes partes de la aplicación. Independientemente de cómo evolucione la tecnología, es muy probable que siempre pueda leer XML y JSON.

• Similar a lo anterior, exponer una parte de su aplicación a través de una API SOAP o REST logra algo similar. Independientemente de las tecnologías que evolucionen, no necesariamente tendrá que volver a escribir cada parte de la aplicación porque las nuevas tecnologías aún podrán comunicarse con las antiguas.

• En el punto de escribir código en caso de que sea necesario , creo que es muy peligroso ya que es probable que el código tenga poca o ninguna prueba.

Entonces, por supuesto, haga que el código sea a prueba del futuro (la NASA aún envía naves espaciales usando Fortran), pero no escriba el código 'por si acaso'.

Piensa en cuántas veces has habilitado un código en un entorno de producción y piensa: "¡Gracias a Dios que escribí eso hace 2 años!".

El código debe ser modificable / ampliable fácilmente. No agregue código que no sea inmediatamente necesario, ya que esto da una falsa sensación de seguridad y desperdicia recursos de desarrollo / prueba en un mundo de requisitos cambiantes.

Muchas de las otras respuestas abordan problemas de diseño más grandes, o son bastante abstractos. Si piensa en términos de lo que sucederá en el futuro, puede definir algunas técnicas claras para ayudar a proteger el código en el futuro .

Principalmente piense que en el futuro alguien intentará agregar una característica al código, o intentará reutilizar su código en otro lugar. También pueden intentar corregir una función en el código. Obviamente, tener un buen código limpio es un punto de partida obligatorio, pero también hay algunas técnicas específicas que se pueden hacer.

Programación defensiva : verifique la entrada más allá de lo que su aplicación actual realmente necesita. Siempre que llame a las API, asegúrese de verificar que su entrada sea algo que esperaría. En el futuro, las personas mezclarán nuevas versiones de código, por lo que el alcance de los errores y las devoluciones de API cambiarán de lo que es ahora.

Comportamiento indefinido de Elliminate : una gran cantidad de código tiene un comportamiento que evoluciona de la nada. Ciertas combinaciones de entrada conducen a cierta salida que nadie realmente pretendía, pero sucede. Ahora, inevitablemente, alguien dependerá de ese comportamiento, pero nadie lo sabrá ya que no está definido. Cualquiera que intente cambiar el comportamiento en el futuro inadvertidamente romperá las cosas. Utilice las comprobaciones de seguridad ahora e intente eliminar / bloquear todos los usos indefinidos del código.

Conjunto de pruebas automatizadas : estoy seguro de que puede encontrar volúmenes escritos sobre la necesidad de pruebas unitarias. Sin embargo, en referencia a pruebas futuras, este es un punto crítico para permitir que alguien refactorice el código. La refactorización es esencial para mantener un código limpio, pero si falta un buen conjunto de pruebas, no puede refactorizar de manera segura.

Aislamiento y segregación : la encapsulación y la modularización adecuada es un buen principio de diseño, pero debe ir más allá. A menudo encontrará que necesita usar una biblioteca, API o producto, que puede tener un futuro cuestionable. Tal vez debido a problemas de calidad, problemas de licencia o desarrollo continuo por parte de los autores. En estos casos, tome más tiempo para poner una capa entre usted y este código. Reduzca la API a lo que necesita para que el acoplamiento sea muy bajo para permitir un reemplazo más fácil en el futuro.

El código bueno, limpio y bien organizado está preparado para el futuro en el sentido de que hace que los cambios y las adiciones sean más fáciles de implementar correctamente.

"Prueba futura" en el mejor de los casos significa "diseño poco acoplado". El 80% de las veces las personas quieren decir "flexible" cuando dicen "prueba de futuro". A veces lo dicen para intentar sonar bien. Pero al menos están entregando algo a tiempo que funciona.

"Prueba de futuro" en el peor de los casos no tiene sentido. El 20% del tiempo, es una excusa para perder el tiempo investigando tecnologías alternativas en lugar de simplemente entregar algo. No están entregando nada (o lo que están entregando es demasiado complejo para el problema en cuestión).

Hay dos casos de borde.

1. Previsión inagotable. Uno realmente puede predecir el futuro con precisión. En este caso, aplique esta previsión poderosa para probar el código en el futuro. Mejor, aplique la previsión inagotable para predecir las tendencias del mercado y retirarse antes de tiempo y detener la codificación.

2. Una es "conducir" el futuro. Es decir, uno tiene una nueva tecnología lista para implementar en el futuro que requerirá una reescritura de lo que se está entregando en este momento. Es extraño que uno no esté desplegando esta cosa genial del futuro primero.

   Debemos entregar el proyecto "A", sabiendo que el proyecto "B" conducirá a una reescritura inmediata de "A". Solo en este caso, podríamos ser capaces de probar en el futuro "A".

YAGNI = No lo vas a necesitar .

Sus instintos son correctos: su código es superfluo, agrega una carga de mantenimiento y pruebas, y pierde tiempo en cosas que no tienen un valor comercial concreto.

Ver también: chapado en oro .

Ignorando el título de la pregunta, y manteniendo el punto principal sobre "poner cosas porque alguien podría quererlo algún día" ...

La respuesta es no. Nunca. No escriba una puntada de código que no necesita hoy. Este es el por qué:

1. El programa ahora es más complicado de lo que debe ser.
2. Es posible que nunca necesite la función, por lo que ha perdido su tiempo.
3. No sabe cuáles serán los requisitos para la función si alguien lo solicita en el futuro. Por lo tanto, tendrá que resolverlo y modificarlo de todos modos.

Creo que el primer punto es el más importante. Si alguna vez ha trabajado con un sistema que está plagado de códigos genéricos para diferentes clientes, o lleno de funciones con cosas que no necesita, entonces sabe cuánto tiempo y esfuerzo adicionales se necesitan para mantener o ampliar la funcionalidad debido a ese. Así que evítalo a toda costa.