Tracer Bullet Development

Question

Estoy trabajando en una aplicación de servidor cliente utilizando el enfoque Tracer Bullet defendido en The Pragmatic Programmer y me gustaría obtener algunos consejos. Estoy trabajando en cada caso de uso desde la iniciación en el cliente hasta el servidor y de nuevo al cliente para mostrar el resultado.

puedo ver dos formas de proceder:

1. Cubrir los casos de uso básicos, simplemente escribir código suficiente para satisfacer el caso uso que estoy trabajando, y luego volver y dar cuerpo a todo el manejo de errores posterior.
2. Rellene cada caso de uso tanto como posible, atrapando todas las excepciones y puliendo la interfaz, antes de pasar al caso de uso siguiente .

Me estoy inclinando por la primera opción, pero me da miedo olvidarme de manejar algunas excepciones y hacer que me muerda cuando la aplicación está en producción. O de dejar mensajes de error "trozos" poco claros. Sin embargo, si tomo la segunda opción, creo que terminaré haciendo más cambios más adelante.

Preguntas:
Al usar el desarrollo de balas trazadoras ¿cuál de estos dos enfoques toma y por qué?
O, ¿hay otro enfoque que me falta?

Answer 1

Según tengo entendido, el método de bala trazadora tiene dos objetivos principales

1. abordar los problemas fundamentales tan pronto como sea posible
2. dar al cliente un resultado útil tan pronto como sea posible

Su la motivación para no "pulir" cada caso de uso probablemente sea acelerar 2. más. La pregunta es si al hacerlo pone en peligro a 1. y si el cliente está realmente interesado en los resultados "sin pulir". Incluso si no, ciertamente hay una ventaja en la capacidad de obtener retroalimentación del cliente rápidamente.

yo diría que su idea es aceptable, siempre que

• a asegurarse de que no hay problemas fundamentales que se esconden en las partes "pulir" - esto sin duda podría ocurrir con el manejo de errores
• Realice un seguimiento de todo lo que tenga que "pulir" más adelante en un rastreador de problemas o dejando los TODO en el código fuente, y examine cuidadosamente los que están funcionando.
• Los casos de uso no son tan "sin pulir" que el cliente puede 't/will not give feedback útil sobre ellos

Answer 2

Si toma el enfoque n. ° 1, tendrá el 90% de la funcionalidad trabajando bastante rápido. Sin embargo, su cliente también pensará que está 90% listo y se preguntará por qué le lleva 9 veces más tiempo terminar el trabajo.

Si toma el enfoque n. ° 1, lo llamaría nada más que un prototipo y lo trataría de esa manera. Representarlo como algo más que eso no conducirá a nada más que a problemas posteriores. Los escenarios de Happy Day son solo el 10% del trabajo. El 90% restante es para que los otros escenarios funcionen y el escenario del día feliz para que funcione de manera confiable. Es muy difícil conseguir que los no desarrolladores lo crean.Normalmente hago algo entre # 1 & # 2. Intento hacer un buen trabajo identificando casos de uso y todos los escenarios. Luego intento identificar los escenarios con mayor impacto arquitectónico y trabajar en ellos.

Answer 3

que sugeriría para balas trazadoras se puede utilizar una combinación de casos de prueba positivos + negativas

1. casos positivos de la prueba (éstas se mencionarán en sus historias de usuario/documentos/Especificaciones funcionales)
2. casos negativos de prueba (escenarios negativos comunes que se pueden esperar en un escenario BAU) (escenarios de negocio raras se pueden dejar después de una cuidadosa consideración.)

Estos casos de prueba se corrieron utilizando specflow para automatizar las pruebas.

La inclusión de escenarios Negativos Comunes en sus casos de prueba brinda la suficiente confianza de que se pueden hacer desarrollos sucesivos utilizando el código subyacente.

Compartiendo la experiencia aquí http://softwarecookie.wordpress.com/2013/12/26/tracer-bullet/