
¿Te identificas con alguna de estas? 😅👇
- Debug con
System.out.printlnen 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(),Streamy 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 todostaticopublices tentador, pero rompe el encapsulamiento. Practica SOLID: controla la visibilidad de campos/métodos, usaprivatey 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,reducey 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