¿Cómo puedo aprender el enfoque correcto para implementar la mitad de una característica? [cerrado]

12

Dirijo un equipo de desarrollo y deseo lanzar nuestro producto tan a menudo como sea posible (Entrega continua).

En muchos casos, tenemos que implementar una función que demora más en implementarse que el tiempo entre versiones. Todavía quiero que las personas confirmen su código a diario (Integración continua).

Muchas veces, la implementación de una nueva característica requiere que la característica existente se cambie y, por supuesto, las características existentes aún deben funcionar, incluso si la nueva característica aún no está terminada.

Si el desarrollador utiliza el enfoque correcto , puede ajustar las características existentes con cuidado y todo lo anterior no es un problema.

Sin embargo, ¿cuál es el enfoque correcto en realidad? Mi propia mente adaptada a la programación me dice qué hacer para cada caso individual, pero necesito aprender más y necesito material de lectura que pueda leer y recomendar a los miembros del equipo para que lean. O cualquier otro método para aprender la manera correcta de aprender este enfoque será suficiente.

Así que esa es la pregunta. ¿Cómo me aseguro de que los miembros del equipo aprendan el enfoque correcto para implementar la mitad de una función?

He buscado personas que afirman tener estrategias con respecto a esto, pero no las he encontrado todavía, excepto personas que escriben algunos pensamientos aleatorios sobre el tema. Quizás no esté usando las palabras de búsqueda adecuadas o tal vez nadie haya hecho ninguna guía autorizada al respecto.

    
pregunta Niels Brinch 10.09.2013 - 10:00

4 respuestas

14

Ya tengo una vista diferente de las otras respuestas aquí. Estoy de acuerdo con usted en que desea integrar los cambios de los desarrolladores lo antes posible y seguir probando la combinación de códigos combinados.

Sin embargo, no estoy de acuerdo con que su derecho a enviar el código de envío se haya desarrollado esta mañana, solo porque estamos lanzando esta tarde. Esa es una receta para clientes decepcionados.

La solución es tener sucursales en su árbol de control de versiones, y que tenga un proceso separado para promover los deltas verificados desde la rama de desarrollo a la rama de lanzamiento.

De esa manera obtienes lo mejor de ambos mundos. Usted tiene desarrolladores que realizan una integración continua y las ventajas que aporta, tiene un código estable que se envía al cliente con regularidad, y tiene un nuevo proceso que prueba las características completadas en la rama del desarrollador, y si pasan las pruebas, las hacen parte del producto lanzado. .

Hay dos herramientas que conozco que soportan bien este tipo de procesos. Si su estructura de desarrollo es simple, entonces git, con git-flow implementa una buena estructura de bifurcación que funciona bien en equipos pequeños y medianos (quizás 20 desarrolladores).

Para equipos de desarrollo más grandes, o donde se necesita una estrategia de bifurcación más compleja para admitir múltiples 'giros' de su producto, la precisión es lo mejor que hay. Los desarrolladores que no participan en la gestión de los cambios se quejarán de que es más difícil que una sub-versión, etc ... pero que admite entornos de desarrollo complejos.

    
respondido por el Michael Shaw 10.09.2013 - 16:48
6

Aquí hay dos problemas: uno está implementando la mitad de una función; el otro es mantener el producto de envío funcionando durante el desarrollo continuo.

Implementando la mitad de una función

Un diseño general fuerte ayudará con esto. Esto le permite implementar la función con sus límites claramente definidos, por ejemplo, las API a los bits de código adyacentes, las expectativas sobre las estructuras de datos y una comprensión de cómo y cuándo se llamará al código implementado.

Las pruebas pueden incluir versiones simuladas del código para las otras partes de la función; esto ayuda a facilitar la transición cuando se va a implementar la segunda mitad.

Manteniendo el producto de envío funcionando

Aquí hay un puñado de opciones:

  1. Desactiva la función en el producto enviado. El hecho de que el código esté en el producto no significa que deba ejecutarse o presentarse a los usuarios. El inconveniente es que no entregará un valor incremental a sus usuarios y no obtendrá comentarios.
  2. Revele los bordes de la función a sus usuarios. Muestra lo que tienes y proporciona alguna indicación de lo que vendrá.
  3. Permite a los usuarios cambiar entre la funcionalidad nueva y la antigua. Esto a veces requiere mantener dos rutas de código listas para el usuario final.

Finalmente, si tiene problemas con alguna de estas soluciones, considere si ha dividido la función en los límites correctos. Si dividieras las cosas de una manera diferente, ¿sería más fácil separarlas?

    
respondido por el Alex Feinman 10.09.2013 - 15:06
1
  

¿Cómo me aseguro de que los miembros del equipo aprendan el enfoque correcto para implementar la mitad de una función?

Al enseñarles. (duh)

El aprendizaje implicará una iteración: probar algo, ver cómo funciona y luego modificar su enfoque para lograr mejores resultados. Para este tipo de cosas, recomendaría revisiones de diseño / código. Puedes ver cómo se diseña / implementa la media característica y tienes la oportunidad de dar tu opinión. "Esto y eso no funcionará porque romperán nuestro IC; ¿qué hay de XYZ?", "Buen trabajo, eso está muy limpio".

Hacer las revisiones en equipo ayudará a todos a aprender lo que ya sabes de manera intuitiva.

    
respondido por el Telastyn 10.09.2013 - 15:33
1

Lo más importante que te ayudará aquí es tener una buena separación de inquietudes para que, en la medida de lo posible, un área de código no interfiera con otra.

Este es un lugar donde el uso de la inyección de dependencias y la programación en la interfaz realmente ayudan, de modo que puede tener su implementación actual de ISupportingFeature en el sitio y luego, cuando necesita crear INewFeature que depende de una implementación diferente, puede Desarrolle con la nueva implementación y mantenga la existente en producción hasta que esté bien probada y lista para funcionar. Suponiendo que tenga su DI trabajando con un sistema de configuración de algún tipo, esto le permitirá tener el mismo código en paralelo en su sistema y utilizar un código estable en todo momento.

De hecho, este enfoque de configuración es descrito por Martin Fowler como un Alternador de funciones.

Por supuesto, el problema solo surge si está implementando todos del código todos de la época. Este es precisamente el tipo de escenario para el que se diseñaron las sucursales de características y, aunque reconozco que el Sr. Fowler frunce el ceño, no sé que sean tan malos, especialmente si se crean y utilizan de forma planificada y pensada. a través del camino.

    
respondido por el glenatron 10.09.2013 - 10:55