También me gustaría describir esto como elegante, pero quisiera agregar el problema, si se le perdona mi intromisión.
Sé que hay son muy caros paquetes de software para el trabajo a través de situaciones como esta, pero en la empresa que yo trabajo en el que no podemos pagar el costo a menos que esté seguro de que no lo necesitamos.
Test Driven Development(TDD) es uno de los mejores sistemas que he escuchado de desarrollo, y la disfruto, pero los problemas que tomar mi tiempo son normalmente causadas por el complejo de interrupción de hardware y eventos que muchos denominan fallos. Parece una cosa de menor importancia de tener un problema cada 2 horas cuando las estrellas se alinean, pero si su teléfono sólo se congeló una vez a la semana,que iba a maldecir a los ingenieros de nombre. En nuestro caso, hemos de investigar en un feed lot cuando las cosas realmente se rompa, lo que, como puedes imaginar, me gustaría evitar.
He visto muy de soluciones inteligentes para la comprobación de la funcionalidad de los subsistemas, que, si se implementan adecuadamente, probablemente me salve de 3 horas de un 50 horas a la semana, pero si hay una forma inteligente de encontrar glitch situaciones me ahorraría semanas de trabajo en busca de la "bug" que sucede en el campo de vez en cuando bajo carga pesada.
Este post probablemente no ayuda a una gran cantidad, pero me parece que traer todo a la luz hace que todo sea más fácil de resolver. Si hubo un TDD método para encontrar glitch situaciones, podría tener a 10s de miles asignados a pagar por ello.
-Max
