Feda /dev/ - No Javascript allowed

#44911 El primero es el que hice, el segundo es el refactor que se ha cascado sobre el código que ya había (por eso está en rojo.).

Prestad especial atencion a las dos funciones de abajo. Son de trilero.

#44913 Una es un string equals y la otra un startsWith, pese al nombre. Además que los nombres de los parámetros también engañan, se usan para cosas que no son lo que pone en el param name. Hay que prestar mucha atención.
Que extra alloc ? El string ? Nah el performance no es un problema.

Es decir a una le puedes pasar “a”, “a” y te dice que si es un session topic.
Los session topics empiezan por msg/ o por sess/ dependiendo si vienen del broker o del cliente.

Vamos que no hace lo que dice, porque es un a.equals(b)

#44914 cuanto cobra este tipo?

#44909 El primero. El segundo tiene mejor semántica pero mas contras que pros. No hacen exactamente lo mismo, porque en caso de error no lanza el error, lo devuelve igualmente como StandarTopic (line 39) y encima está acoplado a un MqttSession.

El tema de tener el pattern en una static, aparte de ser estática, es que facilita el testeo.

Así hay menos probabilidad de error humano y es más fácil generar tests.

Yo lo hago con los body de los errores por ejemplo. O cosas del estilo. Por ejemplo para el pattern del mensaje de la expecion también estaría bien.

Más allá de eso, de que es java de mierda y del name de la función, tampoco hay mucho más.

Refactor inecesario.

Si tienes:

PATTERN_BODY = "foo/%s/bar"
PATTERN_ERR = "error with method foo, cause; %s"

en tu test puedes hacer:

var bodyToTest = PATTERN_BODY % test
var expectedErr = PATTERN_ERR % "cause"

vs escribir a mano:

var bodyToTest = "foo/test/bar"
var expectedErr = "error with method foo, cause; cause"

pero vamos, detaillito de x10

#44922 Quizá no entendí bien tu post.

En algunos sitios suelen recomendar que no uses constantes del código en los tests sino que las hardcodees. La lógica de esto es que si otra persona cambia esas constantes en el código por accidente puede pasar que los tests que leen esa constante en concreto sí pasen pero que luego las cosas se rompan en preprod y la gente se vuelva loca intentando entender por qué.

Es un argumento algo rebuscado y asumiendo un caso muy concreto de alguien haciendo una cagada muy concreta, pero por poder puede pasar imagino.

#44922 #44924 Si, puedes meter los strings en constantes, pero ya. Lo demás sobra. En los tests si es bueno meter el string entero hardcodeando (el expected). Incluso puedes hacer:

SessionTopic.tryParseClient(clientTopic).orElse(StandardTopic.tryParse(clientTopic).orElse(error)

Pero vamos que tampoco merece la pena.

La historia es que AYER tuvimos una meeting en el que decía el mismo que los redactors tienen que estar justificados, y que el solo los hace cuando algo no funciona o no puede hacer algo.
Me meo, y su historia era de meter tests en otro lado.

Se me olvidó comentar, esas constantes son de otras clases, son static imports.

#44927 yo conozco a una bióloga pasada por bootcamp que sube reels con "tips" para programar en python

#44931 lloron, biologo y fpero.

de mal a peor.

#44927Seal67:

no conozco ningún profesor bueno

Yo.

Ayer estuve ayudando a randoms de Twitch de la categoria programacion.

El mejor canal que conoci fue un ingeniero electronico que hacia cosas asi con hardware muy majo.

https://www.twitch.tv/labgluon

Dentro de toda la porqueria de pinta y colorea alineadivs de Twitch, se agradece ver a gente haciendo algo distinto...

#44912 Y mi pregunta es.....por qué se pierde tiempo en eso? Es que es una puta gilipollez, para subir líneas y que alguien crea que ese tío está trabajando?

#44936 Si entra el manager yo no le puedo lamer el falo en el standup porque después dicen que soy alto trepa. Vos tenés que crear JIRAs con nombres grandilocuentes, de gran propósito. Y si es posible etiquetar incluso al VP de product en un comentario para dejar el claro el impacto de tu cambio. Y ahí reventas el refactor, le cambiás todas las líneas, no una, porque vas a ser hábil refactorizador y te comés un garrón de la gran flauta. Vos estabas en un estado de intraemprendimiento violento y de locura. Lo reventaste a refactors, cambiaste 7 constantes de sitio y aplicaste 3 capítulos del Clean Code al azar, ponés un test insulso más arriba, lo parametrizás para demostrar tu estado de implicación con el test driven development y el agile methodology as a way of life. ¿Me explico? Además tenés que crear un JIRA aparte para el test, lo estimás como un día entero y si tenés tareas de documentación otro y vas al sprint retrospective así… Sos indespedible hermano, en 10 días promocionás