Feda /dev/ - No Javascript allowed

Oye pues no es mala idea intentar medir la diferencia de readability en un software que sigue al pie de la letra el “Clean code” vs uno que solo sigue el sentido común.

Mismo problema, coges a 1000 devs, les explicas el problema, les dejas resolverlo a ellos por su cuenta (para que tengan el dominio ya resuelto en su cabeza), les pides hacer un cambio de requisitos en su solución y después les das dos codebases diferentes, en las que le pides hacer el mismo cambio, midiendo el tiempo que pasan leyendo código y cuánto hasta realizar el cambio y que funcione. En ambos casos deben mantener la esencia del código, es decir deben mantener las reglas de clean code en el primero y el sentido común en el segundo.

Da para paper, “Developer performance” at stake.

#45032 el sentido común, es el menos común de los sentidos.

#45032 yo lo hice aqui con @vago_21. le dije pideme cualquier refactor a este codigo. y le demostre porque estoy en el top. el buen codigo no llama la atencion pero es perfectamente moldeable.

a ver si encuentras el bug

andrew kelly pone en una presentacion de zig, a gente que nunca ha visto zig, un ejemplo de metaprogramming y reflection, algo considerado complejo y dificil...

encontrando bugs en la stdlib de python hehe

#45037MTX_Anubis:

Creo que había un metaestudio por ahí entre cientos de empresas y miles de programadores y llegaron a la conclusión de que lo único que hacía mejorar (menos bugs, mayor velocidad de entrega, mayor adaptabilidad a los cambios) eran los ciclos rápidos de desarrollo y tener tests (que es distinto a hacer TDD).

No. Ni eso. No es cierto.

Lo unico demostrado que ayuda a tener menos bugs es tener menos codigo.

Si tu puedes hacer algo en 100 LOC en lugar de 1k vas a tener 1 bug menos.

Cada 1k LOC hay 1 bug.

Por eso George Hotz teine la serie donde hace tinygrad y tinydb y demas, software de menos de 1k LOC.

Y por eso yo soy defensor de delegar las cosas al menor nivel posible, de esta manera reduces el codigo en user space y application > transport por ejemplo.

Porque cuanto menos codigo escribas en tu aplicacion y mejor uses las herramientas, menos codigo hay en total, que mas puede ser optimizado.

#45040 Eso ya lo sé pero no hablo solo de tener menos bugs

#45036 Hombre a ver, si metes un switch statement lo primero que busca la gente es un missing case, un poquito de trampas hizo.

Sobre clean code y tal:
Lo que tampoco entiendo es:
Para que carajo quiero desarrollar yo más rápido si me pego el 98% del tiempo sin escribir código ?
No sería mejor subir el % escribiendo código al 50%, haciendo pairing y quitar reviews, y mierdas de reuniones de ops review, refinements, etc ? Y ya de paso hacemos jornadas de 4h y 4d. Te digo que irías por lo menos 3-4 veces más rápido.

Sobre DDD, madre mía yo lo sufrí y eso es montar un pifostio por montarlo, no vale un carajo. Da más problemas que los que resuelve, que no digo que si defines los bounded context y los eventos bien tenga valor, algún caso de uso tendrá, pero a mi me hicieron el “para todo usamos DDD, pero mal hecho”, y oh my….

Hoy he hecho literal UN PR de 3 líneas que escribí el viernes pasado, y ahora revisaré documentación que tenemos que poner al día para otro equipo haga oncall con nosotros

#45044JuAn4k4:

Sobre DDD, madre mía yo lo sufrí y eso es montar un pifostio por montarlo, no vale un carajo. Da más problemas que los que resuelve, que no digo que si defines los bounded context y los eventos bien tenga valor, algún caso de uso tendrá, pero a mi me hicieron el “para todo usamos DDD, pero mal hecho”, y oh my….

Producto: Chatbot médico, con flujos de casos, preguntas que se pueden hacer, respuestas, clasificaciones de preguntas, imagenes, valoraciones... Siendo la mayor parte de flujos asíncronos (quitando la gestión de usuarios/cuentas y la parte de backoffice).

Era un caso de libro para aplicar DDD. Contexto de médico, de paciente y de cuenta para la gestión de usuarios según el contexto como tal, definición de las reglas de negocio en el dominio (número de preguntas que se pueden hacer en un caso específico en base al tier del usuario, por ejemplo). Todos los flujos gestionados en base a eventos de dominio. Equipos claramente separados por esos contextos. Leías un log y hasta el de customer success podía entender que estaba pasando en base a como estaban escritos los eventos y los agregados que los generaban. Y de rebote los podías usar para sacar métricas de negocio.

Casos de uso para estas cosas hay. Otro tema es que como se pone de moda, voy a usar un CRUD con CQRS; HEXAGONAL en top of a DDD based architecture blablabla y tienes 2000 líneas para algo que se hace en tres ficheros de 10.
Estoy peleandome ahora con una app legacy en la que alguien queriendo demostrar lo listo que era ha abstraido absolutamente todo aunque no haya ni interfaces para abstraer (clases concretas que las inyecta mediante DI y simbolos). En Typescript, con lo que eso además en runtime se va a la mierda y en transpilación no se comprueba porque solo se resuelve en runtime. Que daño ha hecho este sistema de tipos por favor.

#45049 estas violentando gente, hogo kuidhao

Buenas gente, tengo una duda sobre ASP.NET con webforms en VS2022 donde puedo preguntarla? o puedo hacerlo aqui? la he liado un poco y no se como solucionarlo

#45052 webforms....eso existe aún?