Feda /dev/ - No Javascript allowed

#38434 También puedes usar un .txt XDDD

#38442 en la medida de lo posible intento no refactorizar código que no es mío, si lo rompes pasa a ser problema tuyo. Estas cosas se previenen con buen code review antes de mergear la PR, pero no todas las empresas lo hacen

#38442 I know that feel bro

#38442 En mi caso refactorizar, avisar de que lo voy a hacer y por qué creo que es necesario hacerlo.
También te digo que las 2 veces que me pasó el "culpable" ya no estaba en el equipo asi que fueron cosas de 1 sola vez.
Y si alguien tiene algún problema pues lo apunto en mi máquina de escribir invisible

Es un problema de la cultura de la empresa/equipo, lo que significa que ni lo vas a cambiar tú ni vas a conseguir nada más que cabrearte. Esos proyectos no suelen ir nunca a a ninguna parte y lo mejor que puedes hacer es ir buscando otra cosa.

En mi anterior curro yo pasaba bastante, como mucho iba refactorizando cosas simples para poder leer el código (ej meter early returns para quitarte 5 IFs anidados o mover de contexto unos datos para simplificar checks). Pero la verdad que hasta probaba ideas y dejaba el código más guarro por experimentar, porque total eso era una bola de mierda enorme e inasumible por la cultura que había.

Ahora más o menos como dice juanaka y también estamos pendientes de poder meter bloques de trabajo dedicados explícitamente a ir quitando deuda técnica que vamos metiendo en tickets analizados y estimados en grano gordo.

Lo que me parece super importante es tener un proceso definido para lidiar con deuda técnica (más allá de que en el momento te encuentres algo que está mal concebido). Últimamente he visto a varias empresas usando shape up y se me ha quedado la curiosidad metida en el cuerpo.

#38442 Lo primero paciencia, nunca se sabe por qué alguien acaba haciendo mierda, no siempre tenemos que pensar mal, aunque suela ser el caso...

No hace mucho me encontré con algo similar, la "solución" que surgió en el momento fue, comentarlo en la daily al día siguiente (que llevaría más tiempo del previsto) + propuesta de enviar por adelantado a todo el equipo (un día antes de los PBR) las nuevas tareas listas para estimar para tener un tiempo extra comprobando este tipo de cosas, por ahora parece que más o menos funciona, ver veremos a medio plazo.

También recalcar la importancia de las PR y las reviews que mucha gente, por desgracia se las pasa por el forro, esto suele ser más complicado.

A una mala, si la cosa no mejora, siempre puedes cambiar, dudo que te falten opciones a día de hoy sea cual sea tu stack o tu nivel

Ánimo

#38452Kaledros:

Lo que dice Juan es lo que se debería hacer en un mundo ideal (no va con segundas, me refiero a un trabajo con condiciones ideales). Si funciona pues mira, eso que tenéis ganado todos.

Yep, si el equipo tiene voluntad de hacer autocrítica y mejorar, pues genial. Refactorizar es entretenido y necesario.

Si no... como no es nuestra empresa, tampoco es un drama, te piras a otra menos frustrante y pista.

#38456 vamos, tu solución es convertir al OP en desu

Funcionando.

Lo hablé tranquilamente con el autor y acordamos refactorizarlo. No sin que antes me discutiera un par de principios básicos de programación, me preguntara sobre qué ganábamos no violando el DIP, y tuviera casi que recordarle lo que estudió en la universidad.

Estoy más con los que recomendais cambiar de trabajo, porque es consecuencia directa de una mala cultura de empresa. Esta es una batalla perdida y voy a acabar quemándome innecesariamente.