Feda /dev/ - No Javascript allowed

#57061 no se... ya veremos

abro y sigo con el debate, tema interesante.

tema autónomo en españa:

aun no estoy dado de alta, pero seguramente me meteré de autónomo si me quedo en Europa, ver ultimo punto.

lo normal es cobrar de USA, incluso si es una empresa "Europea" porque usan LLC para dar de alta las empresas alta, y poder pagar a todo el mundo donde sea fácilmente sin IVAs ni cosas así que meten los gobiernos. Ademas con la LLC y los dividendos hacen ingeniería fiscal los que ganan pasta...

Si me doy de alta pues iba a mirar un gestor que me cubriese y ya

Lo malo del autónomo es que pierdes seguro privado y guarderías y demas, para los que teneis críos... que ahi depende de vuestra situación. Yo haciendo números, con unos 5k netos al mes, siendo casa papis como soy, estoy cómodo, no me da aun para irme de casa... pero quizás empiezo a ahorrar para ello.

tema trabajos remote y como esta el mercado:

salario que manejo en las entrevistas, lo típico para un informático en remoto, 100-200k euros... Si la oferta esta en dólares +10k convertir a euro rápidamente) y también planteo el doble curro (a tiempo parcial obviamente) asi puedo buscar cositas mas accesibles de 80k euros y 80k euros hacen 160k euros.

ya dije que el tema esta paradillo pero vuelven a haber muchas ofertas y veo que hay startups quemando dinero como siempre... tansolo es cuestión de tiempo... antes en 3 semanas tenias curro nuevo, ahora son 3 meses... si no eres un mano rota endeudado y tienes ahorro nada que deba suponerte un problema

tema largarte de españa:

estuve mirando de irme a Portugal y estuve en Lisboa como sabéis de vacaciones y mirando zonas para vivir, pero ya no se puede ser NHR y pagar 20% desde justo el 2024! que putada tios, se han cargado los políticos a todos los americanos viviendo en Lisboa jajaja

lo bueno es que lo tengo hecho de tal manera que si quiero irme de españa este año puedo hacerlo ya sin problemas con hacienda... pero si no es Portugal, que era mi prioridad, para irme a Chipre o Georgia por ahorrarme 10-20k al año... menuda tontería no?

antes me voy a Hong Kong donde pagas 17%, ganando unos 100k euros brutos al año, para que os hagáis una idea, cualquiera de vosotros ahorraría netos +40k euros al año... viviendo como nunca habéis vivido en vuestra puta vida porque nunca habéis estado en faaaaking China... masajes cada dia, comer fuera todo cada dia, chofer privado, asistenta, absolutamente todos los lujos que os imagináis.

china es el mejor pais del mundo, ya no es la tierra de oportunidades para hacerte Billonario, con B, como hace 20 años, pero aun sigue siendo el mejor sitio para hacerte Millonario, con M, en 2-3 años facil.

si quiero irme de españa este año puedo hacerlo ya sin problemas con hacienda

Me alegro de que hayas saldado tu cuenta con la justicia.

#57075 Me recuerda a un sitio en el que estuve que teníamos que rellenar las ocho horas con tiempo trabajado en tickets. Es decir, que todo el tiempo que imputaras en cada ticket a lo largo del día tenía que sumar ocho horas. Y lo mismo, si un ticket se alargaba demasiado ya te estaba soplando en la nuca el lead para ver qué estaba pasando aunque llevaras tres días diciendo en la daily que todo iba bien pero que te iba a llevar más tiempo de lo normal.

No he vuelto a imputar horas separadas por ticket desde entonces y creo que es una de las peores red flags junto con "buscamos a gente comprometida".

#57077 Cada vez llevo peor el micromanagement, de verdad, no sé si me hago viejo y aguanto menos tonterías o qué, pero es de lo que más me jode.

Alguien hace TDD en su equipo realmente? Lo pregunto porque es algo que veo muy idealizado, pero personalmente no conozco a nadie que trabaje así en su equipo (incluso colegas que trabajan con tecnologías mas edge y buenas prácticas exigentes)

#57085r2d2rigo:

he acabado con 25 unit test.

El objetivo es tener 0 unit tests, y que todos esos edge case terminen siendo de integración.

De esta manera el contrato se respetara entre servicios y lo podrás correr en tus entornos de QA/DEV/PRE y PRO antes de desplegar.

Los unit tests son mala practica porque te hacen perder el tiempo en desarrollo, tienes tests repetidos, crean falsa sensación de seguridad, incrementan el Test Code Coverage, usas mocks.

Imagina que estas haciendo un controles de una API que es un /ping y tiene que devolver "pong".

• Si haces un unit test, tendras un codigo que si llamas ese endpoint devuelva "pong".
• Necesitas un test de integración, cuando el servicio este corriendo si llamas /ping te devolverá "pong", por tanto, el test unitario es redundante e innecesario.

Mucha gente como tiene tests unitarios, nunca desarrolla el de integración y termina pasando, que este endpoint no debería de devolver "pong" sino "fpero", y como esto esta testado unitariamente no lo detectas, como tus tests de integración no comprueban el valor de la string y que es un 200, nunca te das cuenta.

De nuevo, tests unitarios, mala practica, no aconsejables, fomentan malas decisiones de arquitectura y codigo mal estructurado. Si te cuesta convertir tus unit tests a tests de integración es porque tu codigo está mal.

Todos los tests unitarios solo sirven para los programadores, para documentar mediante tests la funcionalidad del codigo interno, pero la implementación interna no es nada que deba estar escrito en piedra, es algo que debería poder cambiarse fácilmente, por tanto estos tests se pueden borrar siempre.

El problema es que un fpero ha leído que debe tener unit testada todo, llega a un proyecto nuevo que no se conoce, no sabe que esta testado en integracion, los flujos de aceptante en los entornos de dev/pre... Cuando tiene que tocar algo, no QUIERE, porque le han explicado que NO PUEDE, romper los unit tests. Si rompes un unit tests, estas haciendo algo mal le han dicho los "super seniors arquitects". El resultado es que este chaval que no sabe programar, hace una chapuza en lugar de re-escribir todo el codigo interno de la mejor manera posible. Lo que NO se debe romper nunca son los contratos de integración Y SI estos se rompen es que estas haciendo un BREAKING CHANGE.

Por todo esto concluyo, que en un equipo de PROFESIONALES, que SABEN PROGRAMAR, los tests unitarios no deben existir, y si existen, se pueden borrar siempre... No contribuyen al test Coverage, porque todo esta testado con integración, es decir son tests redundantes q sirven de documentación a otros programadores,

#57087 un validador que trabaja en su propio contexto es un validador mal diseñado, no valida nada... exactamente vienes a confirmar lo que he escrito.

explicame ese validador que valida y que contexto mas o menos y a ver porque no se puede hacer test de "integracion".... xq TODO el codigo que funciona se puede testar... porque funciona en prod no? existe un path para llegar a el...

¿Por qué no deberíamos escribir tests unitarios?

En el mundo del desarrollo de software, hacer TDD (Test Driven Development) puede ser una práctica común, pero aquí se argumenta que hay mejores formas de asegurarse de que el código funcione correctamente.

Problemas con el TDD

• Desconocimiento del producto: Si no entiendes bien el producto que estás desarrollando, el problema radica en la gestión. Esto indica que tienes un mal manager.
• Falta de habilidades técnicas: Si no sabes cómo implementar las soluciones, significa que necesitas mejorar tus habilidades como programador. Ambas situaciones son desfavorables.

La única utilidad de escribir tests primero

El único escenario donde tiene sentido escribir tests antes que el código es para crear un test de integración que funcione como contrato para los requerimientos del producto. Los tests de integración aseguran que los diferentes componentes del sistema trabajen juntos de manera correcta.

Por qué los tests unitarios son una mala práctica

Escribir tests unitarios se considera una pérdida de tiempo y un indicador de mal desarrollo porque:

• Tiempo desperdiciado: Desarrollar tests unitarios consume tiempo que podría ser mejor invertido en otros aspectos del desarrollo.
• Redundancia y falsa seguridad: Los tests unitarios suelen ser repetitivos y pueden crear una falsa sensación de seguridad.
• Cobertura de código inflada: Incrementan artificialmente el Test Code Coverage sin aportar valor real.
• Uso de mocks: Dependencia en mocks que no reflejan el comportamiento real del sistema.

Ejemplo práctico

Imagina que estás desarrollando una API con un endpoint /ping que debe devolver "pong".

• Si escribes un test unitario, solo comprobarás que una llamada al endpoint devuelva "pong" en un contexto controlado.
• Sin embargo, un test de integración comprobará que, con el servicio en funcionamiento, una llamada a /ping efectivamente devuelve "pong".

Este ejemplo muestra cómo un test unitario puede ser redundante e innecesario. Muchas veces, los desarrolladores que confían en los tests unitarios pasan por alto los tests de integración, lo que lleva a errores no detectados, como que el endpoint debería devolver "fpero" en lugar de "pong". Este tipo de problemas no se detectan porque los tests unitarios no cubren el comportamiento en un entorno real.

Consecuencias de los tests unitarios

• Arquitectura y código mal estructurados: Los tests unitarios fomentan malas decisiones de arquitectura y estructura de código.
• Dificultad en la transición: Si es difícil convertir tus unit tests en tests de integración, es una señal de que tu código necesita mejoras.
• Documentación interna: Los tests unitarios solo documentan la funcionalidad interna, que debería ser flexible y fácil de cambiar. Por tanto, estos tests pueden ser eliminados sin problemas.

Problemas en equipos con tests unitarios

Un desarrollador que llega a un proyecto nuevo puede encontrarse con una situación confusa si el proyecto está saturado de tests unitarios. Este programador puede:

• No conocer qué está probado en los tests de integración.
• No querer modificar nada por temor a romper los unit tests, lo que le han enseñado que es incorrecto.
• Terminar haciendo parches en lugar de reescribir el código de manera óptima, siguiendo las indicaciones de los "super seniors architects".

Conclusión

En un equipo de profesionales que realmente saben programar, los tests unitarios no deberían existir. Si existen, pueden ser eliminados sin problemas porque no contribuyen significativamente al Test Code Coverage, ya que todo está cubierto por los tests de integración. En resumen, los tests unitarios son redundantes y solo sirven como documentación para otros programadores.