Feda /dev/ - No Javascript allowed | Página 1806

Soltrac #54151 21 Mar MV Wizard

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

A ver la próxima

Wei-Yu #54152 21 Mar

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

1

isvidal #54153 21 Mar

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 #54154 21 Mar

#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 #54155 21 Mar A toda leche

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

Fyn4r #54156 21 Mar Inocente

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 #54157 21 Mar A toda leche

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

8

Kaledros #54158 21 Mar

#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 #54159 21 Mar Inocente

#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 #54160 21 Mar

#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 #54161 21 Mar

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

1 2 respuestas

Fyn4r #54162 21 Mar Inocente

#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 #54163 21 Mar

#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 #54164 21 Mar

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 #54165 21 Mar Inocente

#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 #54166 21 Mar

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

Ánimo

Seyriuu #54167 21 Mar

#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 #54168 21 Mar

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 #54169 21 Mar

#54165 ¿Pruebas? Eso suena a hacer tests jajajajaj

Tig #54170 22 Mar

#54153 Si no hacen squash al mergear, tiene que ser bonito vuestro git log. Fácil de leer y entender 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 #54171 22 Mar

#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 #54172 22 Mar

#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 #54173 22 Mar

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

Dr_Manhattan #54174 22 Mar

#54172 les dejaré que se lleven la sorpresa xddd

Wei-Yu #54175 22 Mar

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 #54176 22 Mar

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 #54177 22 Mar

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 #54178 22 Mar

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 #54179 22 Mar

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

1 respuesta

pantocreitor #54180 22 Mar

#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

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales