
¿Te identificas con alguna de estas? 😅👇
- Debug con
System.out.println
en cada esquina
Los JR suelen esparcir println() por todo el código. En lugar de eso, adopta un buen IDE debugger (breakpoints y “step over”) o un framework de logging (SLF4J + Logback) para trazar sin “ensuciar” tu código. - Reinventar la rueda en lugar de usar la API estándar
¿Escribes tu propio método para invertir un String o para un map a list? Antes de codificar, exploraStringBuilder.reverse()
,Collections.reverse()
,Stream
y las utilidades de Apache Commons o Guava. Ahorrarás líneas y mejorarás legibilidad. - Ignorar el manejo de excepciones (o capturarlas todas con
catch(Exception e){}
)
Atrapar la excepción padre sin diferenciar hace que se pierda el contexto. Aprende a usartry-with-resources
, capturar sólo las excepciones que puedes resolver y propagar las demás con sentido (throws). - Abusar de las variables estáticas y del “todo público”
Hacerlo todostatic
opublic
es tentador, pero rompe el encapsulamiento. Practica SOLID: controla la visibilidad de campos/métodos, usaprivate
y expón APIs mínimas. - Streams de Java 8… pero usarlos como bucles tradicionales
Usarstream().forEach()
solo para iterar es un mal síntoma. Dominamap
,filter
,reduce
y combina pipelines de forma declarativa: tu código será más conciso y menos propenso a errores.
❓ ¿Cuál de estas “señales JR” cometías tú al principio?
✍️ ¡Cuéntanos en los comentarios tu anécdota y comparte tu tip para dejar de ser JR de una vez!

👉 Laboratorios Terabyte en Facebook
#Java #JuniorDev #BuenasPrácticas #LaboratoriosTerabyte