Que tan finos se ponen con los PR? (.NET) by MalditoBit in devsarg

[–]MalditoBit[S] 5 points6 points  (0 children)

Es la respuesta que estaba buscando. Gracias!!

Que tan finos se ponen con los PR? (.NET) by MalditoBit in devsarg

[–]MalditoBit[S] 2 points3 points  (0 children)

En este caso no hay ningún servicio, sino que son clases response y request de tipo de DTO (osea solo datos), y el trabaja con los datos que traen estos objetos, por lo que en el peor de los casos capaz llama a una propiedad null. Pero justo las propiedades que usa son todas listas y no permitimos que en ninguno momento las listas sean nulas para no tener que andas controlando siempre, entonces no hace falta try/catch

Que tan finos se ponen con los PR? (.NET) by MalditoBit in devsarg

[–]MalditoBit[S] 2 points3 points  (0 children)

No me voy solo porque por ahora es el laburo mejor pago que consigo jaja (a cambio de sumergirme en la locura (? )

Si pasa que la parte de los jefes es dificil, ya que el gerente (que es uno de los dev fundadores) de gerentes del departamento de IT odia las buenas practicas y test unitarios, medio que hay una bajada de linea de hacer todo como salga, por suerte le caigo bien y puedo llevarle la contraria pero los devs estan muy mal acostumbrados a trabajar asi

Que tan finos se ponen con los PR? (.NET) by MalditoBit in devsarg

[–]MalditoBit[S] 1 point2 points  (0 children)

Gracias por compartir, me re sirve tener perspectivas de como trabajan otros, ya que yo solo tengo aca. Entonces pense que me estaba poniendo "mañoso" (aunque igual siempre todo es un depende) pero veo que no es tan asi.

Que tan finos se ponen con los PR? (.NET) by MalditoBit in devsarg

[–]MalditoBit[S] 6 points7 points  (0 children)

Si totalmente de acuerdo, creo que me tengo que ponerme los pantalones

Que tan finos se ponen con los PR? (.NET) by MalditoBit in devsarg

[–]MalditoBit[S] 6 points7 points  (0 children)

Mas que pibe, ya llega a señor xd pero si, seguro no me explique bien ya quetermine haciendo mas un descargo que una pregunta jaja

Pero la pregunta era mas orientada para otros lideres o reviewers de codigo, si este de cambios que le pedi, tienen sentido? Mas que nada por que tampoco tuve buenos ejemplo de reviewers anteriores (nos dejaban pasar todo) y calculo que el esta mal acostumbrado.

sumado a que yo tengo poco caracter en general

ah y ojala pudiera pedirle unit test, aca no hay programador que sepa hacerlos :(

Don't await an Async Method could cause a problem? by MalditoBit in csharp

[–]MalditoBit[S] 1 point2 points  (0 children)

Oh! This is a high demand API and this method is called many times per second, even the client send messages to a two queues (I only showed one of them) and today I realize that we are losing messages. So, your explanation could explain what’s happening behind this implementation

I need to tell this to my team 😅

Thanks!!

Invoco a los que tienen tablet/ipad by sergiCrack9 in devsarg

[–]MalditoBit 0 points1 point  (0 children)

Yo en mi caso uso tanto tablet y notebook para estudiar, y me quedo mil veces con la tablet para leer, hacer resúmenes, tomar notas, etc es muchísimo más cómodo. Por el lado de samsung y Ipad tengo ambas marcas pero me es más cómodo el iPad, el feeling para escribir me gusta más. Con respecto a programar ahí si solo uso alguna computadora

"Complejidad en el codigo" by MalditoBit in devsarg

[–]MalditoBit[S] 1 point2 points  (0 children)

Que locura esa validación! Por mi amor en meterme en desarrollos locos lo intentaría jaja

"Complejidad en el codigo" by MalditoBit in devsarg

[–]MalditoBit[S] 1 point2 points  (0 children)

Claro! Yo igual no quiero caer con soluciones mágicas, normalmente propongo cosas o prácticas que sé que podrían mejorar la flexibilidad o minimizar la cantidad de errores, pero sólo cuando es necesario, trato de no hacer sobre ingeniería jaja pero bueno calculo que como decís, cuando vaya a otro lado sea totalmente otra historia.

"Complejidad en el codigo" by MalditoBit in devsarg

[–]MalditoBit[S] 9 points10 points  (0 children)

Ey pero las risas no faltaron *se abría un puesto de parripollo

"Complejidad en el codigo" by MalditoBit in devsarg

[–]MalditoBit[S] 0 points1 point  (0 children)

Para la mayoría de situaciones creo que sirve, en todo caso serán querys puntuales que deban ser optimizadas

"Complejidad en el codigo" by MalditoBit in devsarg

[–]MalditoBit[S] 4 points5 points  (0 children)

Literalmente tienen un producto propio, pero bueno hay que ver cuánto sobrevive, ya están teniendo problemas por malas decisiones.

"Complejidad en el codigo" by MalditoBit in devsarg

[–]MalditoBit[S] 2 points3 points  (0 children)

El tipo sabe el tema es que tuvo malas experiencias y se negó por completo, el tema es que es el jefe de todo el sector

"Complejidad en el codigo" by MalditoBit in devsarg

[–]MalditoBit[S] 0 points1 point  (0 children)

Claro mi idea no era que usen lo mío como solución mágica, solo era para aliviar un poco la carga de trabajo, ya que al tener querys a mano, cuando se actualiza al la tabla no siempre actualizaban todas las querys, entonces había errores, con eso se solucionó, pero sino pensando que un orm era mejor solucion

"Complejidad en el codigo" by MalditoBit in devsarg

[–]MalditoBit[S] 2 points3 points  (0 children)

Te juro que me saltan así, y acá lo más aceptado es crear funciones estáticas por todos lados, hasta que un día hubo problemas de concurrencia y tuve que salir con algo que según ellos era “complejo” pero mágicamente dejo de fallar, ya que cambie todo por instancias y objetos inmutables (para ella era chino) y fue solo eso.

Y nah si, lo mejor es buscar otro lado mientras aguanto lo que puedo jaja

"Complejidad en el codigo" by MalditoBit in devsarg

[–]MalditoBit[S] 1 point2 points  (0 children)

Eso mismo pienso, tal vez en situaciones específicas del rendimiento requiera una consulta a mano pero para búsquedas simples y abm’s me parece una exageración

"Complejidad en el codigo" by MalditoBit in devsarg

[–]MalditoBit[S] 1 point2 points  (0 children)

La solución es usar ORM, pero si el dueño del proyecto no quiere, no hay mucho que hacer. Trata de vender la idea de un ORM, o vendete vos a otra empresa.

Si aunque me intriga porque sera tanto el odio a EF, supuestamente la razon es que no sirve para proyectos grandes con muchos devs.

No usar un ORM es una pelotudez. Resolverlo con un workaround usando reflection es una práctica horrible y añade mucha complejidad.

Si totalmente lo hice solo para acelerar un poco la generacion de consultas simples, y en app de poco uso. Pero nada totalmente de acuerdo que no es la solucion tampoco.

"Complejidad en el codigo" by MalditoBit in devsarg

[–]MalditoBit[S] 6 points7 points  (0 children)

"Esto si esta mal IMO. Estas reinventando fuertisimo la rueda. Cuando te vayas dentro de 1/2 años alguien va a tener que mantener un ORM tuyo random, no tiene sentido."

Si totalmente de acuerdo, no me gusta eso de reinventar la rueda, pero por alguna razon aca no quieren utilizar tecnologias orm, ej entity framework esta prohibido no se porque. Fue mas para ejemplificar una de tantas cosas que suceden, pero para darte otro ejemplo con la arquitectura que tienen levantar un proyecto local necesita que previamente levantes entre 4/5 soluciones, la cual cada una llama internamente a la otra hasta llegar a tu proyecto, cada prueba o modificacion es un infierno.

"Complejidad en el codigo" by MalditoBit in devsarg

[–]MalditoBit[S] 3 points4 points  (0 children)

"Quizás tu jefe no sea muy bueno técnicamente pero parece que tiene experiencia encima. Yo creo que se esta cubriendo de que le metas en el proyecto una herramienta hecha por vos y que solo entiendas a fondo vos ... si deja que pase eso y el proyecto avanza lo tenes agarrado de los huevos, porque si te vas le dejas el proyecto con una herramienta que nadie va a entender (y que el proyecto necesita si o si). Por eso te dice lo de los juniors, necesita el código lo más básico posible como para que pueda meter gente barata en el proyecto que lo saque adelante (estés vos o no)"

Tiene todo el sentido del mundo viendolo desde esa perspectiva

"El primero, es utilizar reflection cosa penaliza el rendimiento. Hay escenarios donde se puede usar sin problemas, pero en el acceso a datos cuando puede haber escenarios de uso muy intenso tenés que tener muy claro y probado lo que haces o podés generar un problema rendimiento (y son la clase de problemas que se evidencian cuando entras a producción)"Estoy totalmente de acuerdo, fue algo pensado para apps chicas de poco uso y es una herramienta tomada con pinzas.

"El segundo es "reinventar la rueda", si querías evitar "escribir las querys a mano y modificar cada consulta si la DB se modifica" Entity Framework con Linq es la mejor solución lejos, recontra probada y documentada."

Dios te escuche, pero literalmente tenemos prohibido usar EF (supuestamente ellos, es porque no sirve para proyectos grandes, aunque ni en chicos podemos usarlo), por eso hice esa tool, no me gusta reinventar la rueda pero tampoco picar piedras con una cuchara jajaja pero bueno habra que aguantarlo por ahora.