Saltar para trabajar en diferentes funciones cuando te quedas atascado, ¿es una fuente de fallas en el proyecto?

En proyectos personales (o de trabajo), si uno se atasca en un problema, o espera encontrar una solución al problema, si salta a otra sección de su código, ¿no cree que será una buena razón para que su aplicación será defectuoso o peor pero nunca se completará?

Suponiendo que no esté usando git y codifique cada función en una rama específica, las cosas pueden salirse de control ya que tiene 3 funciones diferentes en las que está trabajando y tiene problemas no resueltos en cada una.

Entonces, cuando terminas de trabajar, te estresas porque tienes estos problemas pendientes y el código a medias persiste.

¿Cuál es la mejor manera de evitar este problema? (si lo tienes)

Supongo que usar algo como git y crear una rama por función es la forma más segura de evitar este mal hábito.

¿Cualquier otra sugerencia?

Esto no es un problema. Alejarse temporalmente de un problema desconcertante es una de las mejores formas de lograr un avance en ese problema (ya sea más tarde cuando lo esté pensando o la próxima vez que se siente con una perspectiva / mente fresca).

Asegúrese siempre de utilizar la ramificación de control de fuente correctamente y no tendrá que preocuparse por las medias soluciones en el código. Algunas personas nunca cometen descansos, pero eso es solo una elección personal. Sin embargo, nunca deberías impulsar descansos para compartir con otros.

Como mencionó smp7d , saltar puede darle un buen descanso mental del problema en cuestión. Sin embargo, es importante no olvidar que el código en el que estaba trabajando todavía está incompleto. Asegúrese de saber dónde lo dejó.

Como se mencionó en smp7d, el control de origen y la ramificación es una excelente manera de dividir su nuevo código de función y ver cómo difiere de la base del código principal.

Una sugerencia que tengo es que si está trabajando en un método en particular, asegúrese de que haya una prueba de unidad bien nombrada en torno a ese método. De esa manera, cuando trabaje en ese código el próximo día / semana / mes / año, debería poder decir claramente qué se supone que debe hacer el método , incluso si actualmente no pasa la prueba.

¿Es un problema? No cuando se te ocurre el 10% de las características que estás intentando implementar. A veces tienes la mente más clara cuando haces algo diferente primero.

Obviamente, es un problema cuando te quedas atascado por el 90% de las características que intentas implementar; entonces, o necesitas ayuda de otros, o un ligero golpe de tu jefe para terminar lo que has comenzado (por supuesto, este último lo hará). ser contraproducente si se atascó debido a problemas técnicos reales).

La mejor opción para este caso a menudo es tratar de dividir la característica en la que está trabajando en subcaracterísticas más pequeñas o "sectores de características", que se pueden implementar, probar y depurar uno por uno. Para mí, es útil escribir esos segmentos de características, temas abiertos, partes que se deben hacer en una lista, darles prioridades (A, B, C es suficiente) y trabajar primero en las cosas con mayor prioridad.

Según mi experiencia, "saltar" o, más claramente, "saltar al azar" es un síntoma de un problema más urgente, uno de los objetivos mal establecidos.

Si tiene una idea muy clara, por escrito, si las notas post-it en el lateral de su monitor o en las especificaciones formales adjuntas al rastreador de su elección, casi siempre sabe exactamente en qué trabajar a continuación . Si siempre está trabajando en una de esas siguientes cosas, entonces tendrá una buena oportunidad de tener éxito con el proyecto.

Si, por otro lado, su idea de cuál es la próxima cosa más importante es confusa, es mucho más difícil encontrar algo en lo que trabajar que realmente aborde el problema que su proyecto pretende resolver, o más específicamente, es mucho menos complejo. y seco al decidir que este cambio en particular está completo y resuelve un problema en particular.

Si tiene un objetivo como "hacer que la interfaz de usuario sea más fácil de usar", bueno, es casi imposible decir cuál será la próxima solución, o cuando haya terminado de "arreglar la interfaz de usuario" y pueda pasar a otra cosa. Si, por otro lado, tiene un objetivo como "combinar estos menús desplegables en un campo de búsqueda con autocompletar" y "'foo' debería completarse automáticamente en 'Fooly Brand Baring'", es totalmente obvio cuando haya solucionado ese problema.

No escriba ningún código hasta que tenga una idea muy clara de cuándo parar , y si no tiene ideas claras, trabaje para obtener una de ellas en lugar de comenzar otra rama para alguna característica general.

Si tienes una buena especificación de trabajo (incluso para proyectos personales), entonces "saltar" es totalmente bueno, seguro y útil.

Si bien alejarse de un problema puede ayudarlo a resolverlo, tenga en cuenta que cambiar los contextos tiene un costo. Debe intentar hacerlo solo cuando esté realmente atascado o cuando surja una tarea de misión crítica (por ejemplo, un cliente está inactivo).

Si cambia constantemente de una tarea a otra, puede terminar con varias características a medio terminar y mucho tiempo perdido. Es por eso que prácticas como kan-ban lo alientan a establecer un límite de trabajo en progreso. De esta manera, puede concentrarse en completar, a lo sumo, solo unas pocas tareas a la vez, lo que aumenta el rendimiento.

A veces puede ser útil limitar la cantidad de características que se implementan en paralelo. Negarse a comenzar a implementar una característica adicional si ese límite se excedería hasta que se termine otra característica. Este enfoque se llama Kanban