Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Soltrac

El otro día hablando de inversiones, hoy de rutinas.

A ver la próxima

Wei-Yu

hoy toca hablar de bebés, cómo va el tuyo @isvidal ?

1
isvidal

ya que me invocas vengo a ragear un poco de las politicas nazis de commits y MR de mi empresa.

Estoy OK en que los MR tengan que ser de menos de 250 lineas.

Pero amoh a ver, un puto banner de una linea de texto, entre traducciones y tests pues se va a 200~ lineas, de las cuales como 30 son "codigo de """"verdad""""", el resto traducciones + tests copy paste y scaffolding.

All good direis, pues no, porque ese puto banner con 3 getters i 1 if de una linea se tiene que partir en 6 commits para facilitar mas las tarea de review.

Lo que es mejor, es que no se hace squash, entonces, si divido ese puto banner en commits, hay commits en master en que literalmente el banner esta roto o no renderiza lo esperado.

Mira, comedme el nabo, luego la code base es una mierda apestosa con codigo para tirarse de un puente, pero hey, tu puto MR de un banner tiene 6 commits

2 respuestas
Kaledros
#54153isvidal:

hay commits en master en que literalmente el banner esta roto

A nosotros nos pasa igual. Como esta gente hace trunk based mal, se suben cosas a master porque eso lanza el deploy a QA y se puede hacer test manual, así que como venga alguien y despliegue tu servicio sin preguntarte va a llevar a producción un cambio que rompe cosas. Muy guay todo.

Lecherito

Donde estoy ahora si no pones imports estáticos te lo ponen como nit, todas las veces que haga falta XDDDDDDDDDDDD AHAHAHAHAAH

Fyn4r

Yo tengo una queja similar pero en el extremo opuesto. Una PR de 8 líneas en total, 2 commits, uno para cambiar unos valores en una template de config y 1 if de una línea.
La review: Es que igual habría que tener un modelo de nosequé más acorde a la respuesta del servicio, es que tal función debería estar en un context manager.
Pero sois gilipollas?

3 respuestas
Lecherito

#54156 el meme de: de una review de 4 líneas y veré 5 fallos. Dame una de 400 y todo ok

8
Kaledros
#54156Fyn4r:

Es que igual habría que tener un modelo de nosequé más acorde a la respuesta del servicio

Respuesta: "buena idea, pero se sale del scope. Abre Jira y asígnatelo, si eres tan amable".

1 1 respuesta
Fyn4r

#54158 Esa es exactamente la respuesta a ambos comentarios. El restultado está siendo un /ignore por ahora, pero como mañana me voy de vacaciones pues lo voy a ignorar hasta abril xDDD

1 respuesta
Kaledros

#54159 A mis brazos, yo mañana me piro hasta el día 1 y ayer me llegó la PS5 con el Bloodborne :DDDD

JuAn4k4

#54156 No, es para ver si lo haces tú y no ellos

1 2 respuestas
Fyn4r

#54161 Eso es lo peor, que esa PR es un "primer paso" para hacer funcionar una movida que quedó a medias el año pasado y de la cual ahora soy "owner". Osea que lo iba a hacer yo igual xd
Mi teoría es que como se acerca el período de revisiones / ascensos la gente está intentando hacerse notar para justificar que su trabajo tiene mucho impacto, o algo xd

Kaledros

#54161 Por eso una de las soft skills que hay que cultivar más es el "estoy de acuerdo, pero lo vas a hacer tú y va a parecer que ha sido idea tuya".

Seyriuu

Vengo a contaros una incidencia que he tenido hoy. Por cosas no relacionadas hemos modificado un módulo cuya última versión era del 2007 y ha dejado de funcionar en producción, tras investigarlo, resulta que al principio de todo tiene este if:

IF ¬(VALIDAR_ENTRADA) THEN RETURN;

Esto lo que hace es que si en el validar entrada hay un error, te cascan un return('0'b), se cumple el IF, y la ejecución del módulo termina.
El problema es que no tiene puesto que si todo va bien return('1'b).
En la compilación de 2007 este procedimiento devuelve por defecto un '1'b y hace el funcionamiento pretendido, pero ahora, en 2024, devuelve un '0'b y siempre se sale del módulo sin hacer nada.

Me imagino a que se deberá a algún cambio de versión del compilador, ahora el banco le ha cobrado de menos en ciertos contratos a sus clientes y tendrá el marrón de pedirles de buena fe que les paguen la diferencia.

1 respuesta
GaN2

#54164

ahora el banco le ha cobrado de menos en ciertos contratos a sus clientes y tendrá el marrón de pedirles de buena fe que les paguen la diferencia.

Buena suerte jajajaja

Entiendo que si se ha actualizado la versión del compilador se habrá probado en preproduccion? Porque me da a mí que alguien se ha fumado las pruebas

2 respuestas
Dr_Manhattan

Hostias, he vivido incidencias del tipo y me vienen feelings de lo que se siente.

Ánimo

Seyriuu

#54165 El tema es que cuando cambias algo en concreto, en las pruebas te fijas muy bien, pero en este caso se dieron un montón de circunstancias que relato en spoiler por si te interesa

spoiler

Total que nos hemos quedado con que se han subido operativas cogiendo el cambio sin querer, no se ha revisado bien porque nadie se lo esperaba, no podemos deshacer los cambios porque podríamos cargarnos las transferencias, y no podemos subir la solución arreglada (que es ultra fácil, literalmente una línea de código).

1
JuAn4k4

Yo el otro día arreglé un bug, que le estábamos permitiendo a clientes usar más de lo que debían, al arreglarlo empezó a limitar a ciertos clientes y al final incidencia SEV3 y a crear documentos, PIR, RFO y mucha mierda por arreglar un bug y tuvimos que hacer rollback del bug fix y permitir que usen de más a todos.

Lifecasi0

#54165 ¿Pruebas? Eso suena a hacer tests jajajajaj

Tig

#54153 Si no hacen squash al mergear, tiene que ser bonito vuestro git log. Fácil de leer y entender :smile: Y cojonudo que no puedas ir a cualquier commit de main y esperar que funcione.

Los demás, ¿en vuestras empresas hacen git squash, o los commits entran a pelo?

Es bonito pensar en commtis pequeños, pero cuando haces un refactor mínimamente serio en un repo grande, es difícil no tener que tocar muchos ficheros.

2 respuestas
Dr_Manhattan

#54170 en el anterior proyecto git squash a través de PR, en el nuevo de ahora me entran ganas de llorar, gente que no se fía de git y hace un zip antes por si pasa algo, commits directos a development y master etc etc

1 respuesta
Kaledros
#54171Dr_Manhattan:

gente que no se fía de git y hace un zip antes por si pasa algo

Viviendo en 2004 les vendría bien saber que en cuatro años se les viene una crisis encima.

5 1 respuesta
aren-pulid0

#54170 squash siempre, como dice Vidal puede haber commits que no funcionen y si hay que hacer rollback...

Dr_Manhattan

#54172 les dejaré que se lleven la sorpresa xddd

Wei-Yu

si quieres el historial de microcommits vas a la PR y au, la gente que no hace squash está asalvajada y si lo intentan racionalizar y no se dan cuenta de la tontería que están diciendo probablemente estén a un paso de degenerar en primate

1
desu

No hacer squash es de imbéciles.

En master 1 commit = 1 PR = 1 deploy a prod.

Eso de pensar en commits chicos para que sean fácil de revisar es la bobada padre. Si el commit es grande es porque el cambio mínimo requiere ser grande subnormal. Si no te lo puedes mirar en diagonal 5 minutos pues te toca estarte 50 minutos revisándolo, o lo que haga falta, hazte un checkout al PR y haz tu puto trabajo anormal.

Si tienes un commit grande y lo partes, quizás no los revisa la misma persona y se pierde información contextual de porque se estaba haciendo todo. Quizás no quieres desplegar por separado o requiere meter flags. Todo porque un vago, seguramente programador de JAVA y CLEAN CODER no quería revisar la PR.

Es que no entiendo como os pueden surgir estos problemas en el día a día... dejar de trabajar con anormales.

Kaledros

Imagina creer que un commit llamado "fix" y que arregla una ç que se te ha colado y rompe la build es relevante para algo.

pantocreitor

Feature x, con 4 lineas, todo ok
Feature y, cosa gorda en la que se tocan mil cosas, no es posible??? xD

1 respuesta
Kaledros

#54178 Lo normal es que partas la feature X en N PRs que se puedan mergear sin romper nada.

1 respuesta
pantocreitor

#54179 Pero para no romper nada va a haber muchos casos en los que tengas que tocar bastante código, si hay que tocar mucho para no romperlo y no puedo dividirlo en commits funcionales... Se anula la feature? xD

2 respuestas