Desarrollar rápido y con errores, luego corregir errores o ser lento, ¿cuidado para cada línea de código? [duplicar]

Esto depende ENTERAMENTE del tipo de trabajo que estás haciendo. Para muchas situaciones, el desarrollo guiado por pruebas, como lo está haciendo actualmente, es definitivamente el camino a seguir. En general, pasará menos tiempo en el proyecto, ya que no tendrá que volver constantemente a corregir errores y solucionar casos que no tuvo en cuenta por primera vez. Con la primera opción, sí, terminarás en un tiempo récord, pero luego pasarás una buena parte del tiempo en volver y corregir todos los errores.

Dicho esto , si está en una situación en la que necesita sacar un producto por la puerta lo más rápido posible (tal vez esté tratando de ganarle) la competencia por la ventaja de "primero en el mercado"), arroje TDD por la ventana y haga que algo funcione y salga a la luz. Una gran cantidad de grandes productos ha sucedido de esta manera. Su producto no lo llevará a ningún lado si está puliendo y arreglando incesantemente errores si un competidor con un producto "suficientemente bueno" se está comiendo su almuerzo.

Considera Facebook. Mark Zuckerberg creó Facebook en su dormitorio con PHP y MySQL, en un momento en el que probablemente otras veinte personas u organizaciones estaban planeando o lanzando sitios de redes sociales. Parte del motivo del éxito de Facebook fue que salió por la puerta apresuradamente y venció a una buena parte de la competencia solo porque fue el primero en el mercado universitario.

Si tienes tiempo: prueba de unidad .

Si estás en una carrera: código , y haz que funcione, preocupate por los errores más adelante.

EDITAR: Obviamente, no puede lanzar un producto que tenga tantos errores que no pueda utilizarse. Cuando utilice el método "out the door", debe darse cuenta de que al buscar y corregir errores adicionales solo se agregará un valor marginal a su producto en comparación con la versión actual.

La segunda forma es mejor, en mi opinión. Se siente más lento, pero la cantidad de reparaciones, reparaciones y nuevas pruebas será mucho menor y, en última instancia, conducirá a un mejor producto. Dice que lleva "semanas" escribir un programa, pero ya sabe que si utiliza el primer método, puede escribir el programa en "días" y luego pasar "semanas" en la etapa "corregir todos los errores posibles".

El único momento en que recomendaría el método # 1 es cuando se usa el código de prueba de concepto que se usa para demostrar una ventana única o una función que funcionará en parámetros muy estrechos.

La única manera de ir rápido es ir bien.

Una vez vi al "tío" Bob Martin hablar sobre esto en una conferencia. Afortunadamente, una cita está en línea.

  

No existe el software rápido y sucio. Sucio significa lento. Sucio significa muerte.

     

El código incorrecto ralentiza a todos. Lo has sentido. Lo he sentido. Todos hemos sido ralentizados por el código malo. Todos hemos sido ralentizados por el código malo que escribimos hace un mes, hace dos semanas, incluso ayer. Hay una cosa segura en el software. Si escribes un código malo, vas a ir lento. Si el código es lo suficientemente malo, puede simplemente detenerse.

     

La única manera de ir rápido es ir bien.

Realizo un desarrollo guiado por pruebas, donde defino todos mis casos de antemano. Esto me permite codificar rápido y suelto, y luego ver lo que me perdí. Luego vuelvo y reformulo lo que arruiné. Mi opinión siempre ha sido, averiguar qué se supone que debe hacer, "dibujarlo" en un papel y averiguar dónde están equivocadas mis suposiciones. Ha habido demasiadas veces que he tratado de hacer algo perfecto la primera vez, solo para darme cuenta de que tengo que volver y rehacerlo debido a una suposición incorrecta de mi parte.

Creo que tu pregunta crea algo así como una falsa dicotomía. En realidad, la decisión no es binaria ("¿Codifico lenta y cuidadosamente, o de manera rápida e imprudente?"), Sino que está en un espectro. Las dos opciones que presentaste están en ambos extremos.

Exactamente en qué parte del espectro desea estar depende mucho del producto en particular en el que esté trabajando y lo que sus clientes esperan de usted. Debe examinar las restricciones con las que está trabajando y luego tomar una decisión inteligente sobre qué tipo de proceso desea utilizar.

Por ejemplo, si está en una posición en la que es muy costoso corregir errores, o donde las fallas son potencialmente catastróficas, desea estar más cerca de la opción # 2. Software integrado, guía de misiles El código y las herramientas médicas son buenos ejemplos. Cuando corregir un error significaría recuperar millones de dólares en hardware, o cuando su error puede provocar la muerte de las personas, debe asegurarse de que funciona correctamente la primera vez.

El otro extremo del espectro es cuando el entorno empresarial exige cambios rápidos de código, pero es fácil corregir errores y las penalizaciones por fallas son bajas. las aplicaciones web a menudo se ajustan a esta descripción. Sus usuarios claman por nuevas características y cambios en la lógica de negocios, y quieren que se implementen ayer. Si se comete un pequeño error en el código, se requieren quince minutos para editar el script ofensivo, hacer que se revise el código de cambio y realizar una revisión. En este caso, siempre que maneje las expectativas de los usuarios de manera adecuada, aprenderá a ignorar el error ocasional siempre que responda a sus necesidades y mantenga un tiempo de respuesta rápido. Por supuesto, incluso al adoptar este enfoque, debe tener implementadas medidas de seguridad para evitar fallas catastróficas: mantener copias de seguridad, hacer revisiones de códigos y asegurarse de que tiene un buen proceso de revisión / revisión.

Creo que la realidad del desarrollo de software es que la mayoría de los proyectos se encuentran en algún lugar entre estos dos extremos. Por lo general, debe ser diligente en la prevención de errores, pero es posible que no desee un ciclo de lanzamiento de un año debido a un proceso de control de calidad engorroso.

Aparte de los factores ambientales que mencioné anteriormente, creo que la mejor manera de averiguar exactamente dónde debería estar es evaluar los comentarios de los usuarios. Si se sienten frustrados por los largos tiempos de espera para nuevas funciones, es posible que desee recortar un poco el proceso de control de calidad para ser más receptivos. Solo asegúrate de que eres extra rápido para corregir cualquier error que puedas introducir. Por otro lado, si exigen una fiabilidad absoluta, entonces asegúrate de tener suficientes medidas de seguridad para satisfacer esa demanda lo mejor que puedas.

Vaya por 2.

Think -> think further -> do a peer discussion, for complex devs -> code -> test -> eventual fix.

Mucho mejor que

Code -> code more -> realize it won't work -> fix -> discover a new bug the first code raised -> go back to scratch

¿Está siguiendo un enfoque de desarrollo guiado por pruebas (TDD)? Después de 1-2 meses de desarrollo con este enfoque, descubrirá que es tan rápido como si estuviera siguiendo 1. y que mantiene la barra de mayor calidad 2. También podrá realizar cambios -factor) sin miedo, ¡piense en ello como ahorrar tiempo en el futuro!

También agregaré que puede optar por la opción 1. si tiene prisa por llegar al mercado o si está haciendo un prototipo. Solo recuerde que la entrega final de ese trabajo debe ser idealmente rm -rf *

Depende. En muchas cosas, pero una cosa que otros han pasado por alto es que depende del tamaño del proyecto. Para grandes proyectos complejos, la depuración puede ser monstruosa y tener profundas ramificaciones. La planificación y la estructura adecuadas pueden ahorrar una cantidad significativa de tiempo. Los pequeños proyectos simples, por otro lado, son más fáciles de depurar. Hay tantas partes móviles.

Cuanto más grande sea el proyecto, más cuidado debes tener para no tener que hacer frente a un gran dolor de cabeza.

Personalmente, hago # 2. No digo que se haga algo a menos que sepa que pasará las pruebas. Sí, esto me lleva a demorar más y con frecuencia repaso mis tiempos asignados en los boletos.

Cuando cierro un ticket, es muy raro que QA me lo envíe. Así que no solo ahorra tiempo, sino que también ahorra tiempo a los equipos de control de calidad, ya que no tienen que volver a realizar pruebas si hay errores.

Mi gerente ha aceptado que por cada hora que voy ahora, es decir, 2 o más horas que no desperdiciamos en las pruebas.

¿Es lento? Ya, a veces. Pero, encuentro que es más rápido a largo plazo. Hacer un esfuerzo extra ahora podría salvarme de trabajar un fin de semana o dos antes de que finalice el proyecto, solucionando todos los defectos. Eso para mí vale la pena. :)

Si tengo que elegir solo entre esos 2, entonces definitivamente el número 1. Pero no elijo entre 2. Desde su descripción, parece que la mayor parte del trabajo que realiza es conceptual. pensando en el código y cómo debería funcionar. Para mí, una parte importante del proceso de desarrollo es ver lo que realmente hace el código cuando se compila. Por supuesto, puedo resolverlo en mi cabeza, pero eso no siempre significa que el compilador lo hará de la manera que creo que lo hará. Lo que hago es, básicamente, un bucle de código, compilación y prueba en el que detecto los errores antes de tiempo sin tener que pasar una hora mirando una línea de código. De esta manera puede producir resultados mucho más rápido y aún así mantener una alta calidad. No estoy en un entorno TDD en este momento, pero estoy trabajando en la implementación de uno.

Hazlo rápido y sucio primero para demostrar tu concepto. Asegúrese de haber probado el concepto que está tratando de probar, luego deséchelo (lo digo en serio, elimínelo).

Ahora hazlo de nuevo, pero esta vez siguiendo el proceso correcto y la programación defensiva. Le tomará mucho menos tiempo de lo que piensa, porque ya sabe lo que está haciendo y su código será mucho mejor que cualquier cosa que pudiera haber pensado haciendo solo rápido y sucio.

Jarrod respondió esto a lo largo de la dimensión de la situación empresarial.

Aunque eso es válido, también creo que la respuesta varía según el tipo de programa, o incluso para diferentes partes o "niveles" del mismo programa grande.

En lo profundo de un "motor" utilizado ampliamente por el programa, valdrá la pena ir lento, constante y cuidadoso. Hacer uso de pruebas. Hágase un favor y defina las interfaces lo suficientemente estrechas para que no necesite pruebas bazillion para cubrir un exceso de permutaciones.

Pero más cerca de los "bordes" del programa, como la interfaz de usuario o las interfaces a las API externas en evolución, probablemente sea más inteligente ir más rápido. Después de todo, los requisitos son más propensos a cambiar. Además, es más probable que encuentre problemas a través de la observación directa de usted y de los evaluadores beta, que de lo que está obteniendo al escribir conjuntos de pruebas elaborados que tienen menos esperanzas de obtener su cobertura completa.

Básicamente, esto es sentido común, descartado de su evaluación de cuán estable o bien definida es una parte determinada del programa.