Prueba técnica - SSE

He visto tu código por encima y no dista mucho de cualquier implementación de clean code en c#.

No se, no me muevo en estos mundos, no se q tendría que hacer un SSE diferente a ti.

Por otra parte, como no se como son las pruebas técnicas, entiendo que no te piden ningún tipo de seguridad y ese control se hace en otro lado, porque tu implementación carece de cualquier tipo de seguridad.

en un principio iba a pasar del proceso porque me dio mala espina desde el primer email pero como conocía a la empresa dije bueno, malo será

luego ya viendo el percal la dejé por aquí por si alguien quiere comentar algo o si alguien más junior tiene curiosidad y así al menos no lo siento como tiempo perdido

#4

Por otra parte, como no se como son las pruebas técnicas, entiendo que no te piden ningún tipo de seguridad y ese control se hace en otro lado, porque tu implementación carece de cualquier tipo de seguridad.

Es una kata, ese tipo de cosas no las programas en estos escenarios; mil cosas en ese plan que te llevarían horas y horas. En una prueba el scope no es meter usuarios, auth y otras tantas.

#7 y el script lo tendrías que ejecutar desde un dir que sería... el root del proyecto. Que de todas formas lo que dices es un script guarro de 3 líneas bash, tampoco me parece algo útil.

#13 gracias por ojear <3

Si le metes un data store entre conectar y enchufar cosas ya echas más del tiempo que ya eché en toda la prueba sólo para poder decir "metí dos tablas y ahora hago un select real sobre un rdbms".

Con el balance fuera de la cuenta sí que no me quedé muy contento pero no lo metí dentro no tener el problema de mantenerlo sincronizado. Pensándolo dos veces es algo que se lleva la transaccionalidad (que tampoco sale gratis pero eso ya es una micro optimización). No hay order by (que no es barato para nada como señalas), es un top a pelo sobre el identity, que eso sí que es un mojón del quince la verdad. Creo que hay algún engine que sí garantiza (me suena pg? pero creo que ms sql no por ejemplo) el ordering, pero aún así ea información no es algo que deberías tirar a un pozo como ese.

Las queries múltiples por request acaban saliendo sí o sí en prácticamente todos los flujos, aunque sea para reglas simples sobre aggregates de dominio y si es tirando de la PK y tu recurso es pequeño, sin un benchmark de por medio o unas expectativas de volumen de tráfico concreto prefiero tener la semántica porque entre cachés y otras gaitas el footprint debería ser ínfimo.

El texto sobre la race condition sólo son formas de abordarlo, de tener que implementarlo iría por la cola si tuviese sentido (que no lo sé porque no curro en payments y no es lo mismo asincronía de medio segundo que de media hora aún siendo ambas asíncronas). Aún así sigues teniendo la posibilidad de tener dirty reads con el error (otherwise abort), porque es eso o petarte la concurrencia. Cómo resolverías eso application side? Un mutex?

Pues yo veo varias cosas, metes muchas separaciones de proyectos y clases para al final meter toda la lógica en la implementación del repositorio.

No gestionas el race condition que mencionas ni la transaccionalidad de leer un balance y usarlo después para cambiar el siguiente balance (que es obvio es el objetivo de la prueba).

El dominio/problema de las cuentas es un caso perfecto para DDD/EventSourcing, además de ser el típico ejemplo usado. Por ejemplo usando Akka Actors no hubiera costado mucho hacer la prueba.

Además deberías gestionar problemas específicos del dominio como el currency/moneda para dar sensación de seniority.

Al final un mid-level hace lo básico y ya, que es lo que hiciste.

#14 Igual Juanito te puede ayudar más , no tengo ni idea de todo el ecosistema de java ni de actors. Yo soy más de comDB2 por razones obvias. Mutex local no puedes porque diferentes requests pueden ir a multiples instancias de tu servicio(supongo que no te referías a eso).
Supongo que la solución kafka es la obvia, donde todas las mismas ids van al mismo consumer para garantizar orden y luego incrementas el balance. (aunqe aun hay una race)
Si no utilizas queue tienes que hacer una db transaccion para incrementar el balance.

La otra forma es hacerlo "lazy", nunca calcular los balances en insert y 1) los calculas on demand y los insertas cuanto te los piden. 2) tienes un job que los calcula cada X tiempo los que no estaban aun calculados

#16JuAn4k4:

metes muchas separaciones de proyectos y clases

No tengo ni idea de como se hace un proyecto en C#, pero esta es la sensación que me ha dado también, que había un montón de clases para algo que a priori debería ser mucho más sencillo.

De todas formas, no sé en qué iban a ver la seniority en la prueba que te han puesto. Si lo que querían era ver hasta qué punto puedes añadir complejidad y escalabilidad, metiendo Kafka, event-driven y tal, me parece un poco así porque el enunciado no dice nada de eso.