Malos
Hábitos que deberíamos Erradicar
Seamos incluyentes
Historia de
la vida real
¿Juguete para
Niño o Niña?
¿A un niña no le puede gustar Transformers?
¿A un niño no le puede gustar My Little Pony?
¿Qué tiene que ver con la industria?
Tenemos una
deuda muy grande en inclusión
...especialmente con las mujeres
¡Pensemos más en cómo podemos ser parte de la solución y no parte del problema!
Métodos largos
"Todos" sabemos
que no debemos
escribir métodos largos
public HttpResponse doResourceBundle(StaplerRequest request) {
String baseName = request.getParameter("baseName");
if (baseName == null) {
return HttpResponses.errorJSON("Mandatory parameter 'baseName' not specified.");
}
String language = request.getParameter("language");
String country = request.getParameter("country");
String variant = request.getParameter("variant");
if (language != null) {
String[] languageTokens = language.split("-|_");
language = languageTokens[0];
if (country == null && languageTokens.length > 1) {
country = languageTokens[1];
if (variant == null && languageTokens.length > 2) {
variant = languageTokens[2];
}
}
}
try {
Locale locale = request.getLocale();
if (language != null && country != null && variant != null) {
locale = new Locale(language, country, variant);
} else if (language != null && country != null) {
locale = new Locale(language, country);
} else if (language != null) {
locale = new Locale(language);
}
return HttpResponses.okJSON(ResourceBundleUtil.getBundle(baseName, locale));
} catch (Exception e) {
return HttpResponses.errorJSON(e.getMessage());
}
}¡Ese código es de una corporación grande!
public ArrayList<T> breadthFirstSearch (T source, T destination) {
ArrayList<T> bfsPath = new ArrayList<>();
Set<T> visited = new HashSet<>();
ArrayList<T> queue = new ArrayList<>();
queue.add(source);
bfsPath.add(source);
visited.add(source);
int flag = 0;
while (! queue.isEmpty()) {
source = queue.get(0);
queue.remove(0);
ArrayList<T> temp = new ArrayList<>();
if (adj.containsKey(source) && adj.get(source).size() > 0) {
temp.addAll(adj.get(source));
}
for (int i = 0; i < temp.size(); i++) {
if (! visited.contains(temp.get(i))) {
bfsPath.add(temp.get(i));
if (temp.get(i).equals(destination)) {
flag = 1;
break;
}
queue.add(temp.get(i));
visited.add(temp.get(i));
}
}
if (flag == 1) {
break;
}
}
if (flag == 0) {
return null;
}
return bfsPath;
}¡Ciertamente código educativo no
debería ser así!
public static boolean solucionar(int [][]tablero) {
int x=0,y=0;
boolean encontrado = false;
for(x = 0;x < 9; x ++) {
for(y = 0;y < 9; y++) {
if(tablero[x][y] == 0) {
encontrado = true;
break;
}
}
if( encontrado ) break;
}
if(!encontrado) return true;
boolean digitos[] = new boolean[11];
for(int i = 0; i < 9; i++) {
digitos[tablero[x][i]] = true;
digitos[tablero[i][y]] = true;
}
int bx = 3 * (x/3), by = 3 * (y/3);
for(int i =0;i<3;i++)
for(int j = 0; j < 3; j++)
digitos[tablero[bx+i][by+j]] = true;
for(int i = 1 ; i <= 9; i++) {
if(!digitos[i] ) {
tablero[x][y] = i;
if(solucionar(tablero))
return true;
tablero[x][y] = 0;
}
}
return false;
}¡Cómo industria, somos malísimos escribiendo métodos "cortos"!
Métodos Cortos
- Tienen menos errores
- Son más fáciles de probar
- Son más fáciles de reutilizar
- El código resultante
es probablemente más legible
Tips sencillos
Todo lo que vaya
dentro de un condicional, podría ser una función
Todo lo que vaya
dentro de un ciclo,
podría ser una función
Todo lo que vaya
dentro de un try,
podría ser una función
¿Se puede ir
demasiado lejos?
boolean esMúltiplo(int a, int b) {
return a % b == 0;
}
boolean esPar(int n) {
return esMúltiplo(n, 2);
}
boolean esImpar(int n) {
return !esPar(n);
}boolean esBisciesto(int año) {
return esMúltiplo(año, 4) &&
(!esMúltiplo(año, 100) ||
esMúltiplo(año, 400));
}Si dentro de un método, varias líneas se usan
para inicializar una sola variable, todo este código podría ser una función
public String foo() {
Map<String, String> properties = getProperties();
String bar = properties.get("fizzbuzz");
FooBar fooBar = new FooBar(bar);
Baz baz = fooBar.getBaz();
return baz.obtenerUnString();
}En vez de
public String foo() {
Baz baz = unBaz();
return baz.obtenerUnString();
}
private Baz unBaz() {
Map<String, String> properties = getProperties();
String bar = properties.get("fizzbuzz");
FooBar fooBar = new FooBar(bar);
return fooBar.getBaz();
}Escribir
Se incrementa exponencialmente si
hay más de una variable
Escribir métodos cortos
es importante así no los escribamos nosotros...
¡Después que el código copiado funciona,
hay que refactorizarlo!
¡Dejemos los métodos largos!
No documentar
lo suficiente
¿Esto suena familiar?
"Carlos está de vacaciones ni idea cómo funciona eso"
"¡Carlos amaneció enfermo!
Él es el que sabe
cómo se hace eso"
"Carlos hizo esa funcionalidad pero
él ya no trabaja
en la compañía"
"¡No tengo ni p*** idea de qué fue lo que yo hice"
Documentar
evita problemas; salva
productos / compañías
Diferentes Tipos
- Código Limpio
- Pruebas Unitarias
- Java Docs
- Escrita tipo Confluence
/**
* Indica si un año es bisciesto o no.
*
* Un año bisciesto es múltiplo de 4 y si
* es múltiplo de 100 también debe serlo de 400.
*
* El año 1000 es múltiplo de 4 y de 100,
* por lo tanto no es bisciesto.
* El año 2000 es múltiplo de 4 y de 100
* pero también de 400 por lo tanto es bisciesto.
* El año 1996 es múltiplo de 4 y no de 100,
* por lo tanto es bisciesto.
*
* @param año un número natural mayor que 1
* @return true si el año es bisciesto,
* false en caso contrario.
*/
public static boolean esBisciesto(int año) {
if (año < 1) {
throw new IllegalArgumentException("Año no puede < 1");
}
return esMúltiplo(año, 4) &&
(!esMúltiplo(año, 100) ||
esMúltiplo(año, 400));
}@Test
public void elAño1996PorSerMúltiploDe4YNoDe100EsBisciesto() {
assertThat(Fechas.esBisciesto(1996), is(true));
}
@Test
public void elAñoMilPorSerMúltiploDe4YDe100NoEsBisciesto() {
assertThat(Fechas.esBisciesto(1000), is(false));
}
@Test
public void elAñoDosMilPorSerMúltiplosDe4yDe400SiEsBisciestos() {
assertThat(Fechas.esBisciesto(2000), is(true));
}En una Wiki podemos dar una vista de alto vuelo de las decisiones y consideraciones de una funcionalidad
Documentar es un poco "mamón", no es "código"
y toma tiempo
Pero el daño de no
hacerlo es muchísimo
más grave que cualquiera de esas excusas
No todo tipo de funcionalidad requiere
el mismo nivel de documentación
¡Empecemos a documentar, más!
Mantente en lo
alto de tu juego
¿Java tiene
pass-by-reference?
void duplicar(int n) {
n *= 2;
}int n = 1;
duplicar(n);
System.out.println(n); // ???class N {
int valor = 1;
}
void duplicar(N x) {
n.x *= 2;
}
N x = new N();
System.out.println(x);N x = new N();
System.out.println(x.valor); // ???void duplicar(N x) {
x.valor *= 2;
}Ni Java, ni JS tienen
pass-by-reference
...pero usan Referencias para manejar variables no-primitivas
¿Qué tanto sabes sobre la JVM?
¿Qué tanto sabes de Java 8, 9, 10 y 11?
¿Cuánto lees?
...libros, blogs, "conferencias", etc.
¿Qué responsabilidad tenemos con nuestro proyecto?
¿Qué responsabilidad tenemos con
nuestra empresa?
¿Qué responsabilidad tenemos con
nuestra industria?
¿Qué responsabilidad tenemos con
nuestros mismos?
No olvidemos el escándalo de VW
¡Vamos a ser la
mejor versión de nosotros mismos!
NULL
¿Qué es NULL?
NULL es el valor de
una referencia, que no refiere aún a un valor
Hoy en día estamos de acuerdo que uno no debe declarar una variable si no sabemos qué valor darle
int x; // mejor espera a
// poderle dar un valorNo hay ninguna buena razón para inicializar una variable en NULL
String s = null;
if (/* una condición */) {
s = /* algo */;
} else {
// mucho código
s = /* algo más */;
}Excusa #1
String s = getS();
* * *
private String getS() {
if (/* una condición */) {
return /* algo */;
} else {
// mucho código
return /* algo más */;
}
}Solución
String s = null;
for (int veces = 1; veces <= total: ++veces) {
s = cosas[i];
// código que usa s
}Excusa #2
for (int veces = 1; veces <= total: ++veces) {
String s = cosas[i];
// código que usa s
}Solución
El compilador optimiza el código
¡No necesitamos
inicializar a NULL!
¿Para qué más
usamos NULL?
Retornamos NULL
para indicar la ausencia
de un valor
Pero NULL nunca fue pensado para ser usado así
¿Qué tan malo puede
ser retornar NULL?
Es muy fácil tratar
una referencia NULL
como si no lo fuera
"Soluciones"
- Operador Elvis
- Null Coalescing
- Anotaciones como @NonNull
esas "soluciones"
distraen de lo esencial...
¡La mejor manera de
evitar problemas con
NULL es nunca usarlo!
"Mi experiencia es que
si sigues una regla
estricta de nunca retornar null, todo tu código se vuelve más limpio y seguro para los usuarios"
-- Stephen Colebourne
¿Qué retornar?
- Optional
- Colecciones vacías
- Null-Objects
Sólo si no podemos cumplir ninguna de esas opciones, entonces retornamos null pero limitamos su alcance
¡Sabemos que NPE es el error del billón de dólares ¿vamos a seguir usándolo?!
No hacer
parámetros configurables
¿Suena familiar?
"Tenemos que hacer todo el software de nuevo porque las tarifas del cobro de parqueadero cambiaron"
"Esta funcionalidad no la podemos probar por que el endpoint está quemado"
Lo único constante
en el desarrollo de
software es el cambio
Vale la pena preguntarnos
¿qué costo tendría hacer
un cambio? ¿qué tan probable es que cambie?
¡Archivos al rescate!
¡Todos los cambios
hechos en un archivo
no necesitan recompilar!
¡Los archivos pueden ser modificados sin necesidad de saber programar!
Usa i18n así no
"esperes" usarla
¡Siempre escribe código pensando
en el cambio!
Clases
mutables
sin razón
Date date = new Date();
foo(date);
System.out.println(date);¿Qué fecha se imprime?
Sin conocer la implementación de foo()
es imposible saberlo
¡A veces la implementación no la podemos conocer!
¡A veces no la
podemos cambiar!
La cantidad de errores
en la industria por culpa
de mutabilidad no
deseada debe ser
cercana al de los NPE's
Así como los miembros
de una función deben
ser lo menos visible
que sea posible
Las clases deben ser lo menos mutables posibles
En Java hay 2 niveles
- Inmutabilidad Débil
- Inmutabilidad Fuerte
Inmutabilidad Débil
- Atributos Final
- Ningún método "mutator"
- Copia de los parámetros
mutables en el constructor - Copia de los atributos
mutables en "accesors"
Inmutabilidad Fuerte
- Inmutabilidad Débil
- Imposibilidad de crear subtipos:
Clase Final o Todos los Constructores Private
¿Y qué tal JS?
¿Por qué no lo hacemos?
La mutabilidad
es por defecto;
mi lenguaje es
muy "verboso"
Java en una futura versión agregará "value types"
Mientras tanto...
¡Incrementemos
el uso de clases inmutables!
No hacer
Code Review
Code Review: pedir a otros miembros del equipo que revisen nuestro código
Ventajas
- Asegura que todo el
código tenga el mismo estilo - Incrementa la
calidad del código - Evita bugs
- Incrementa el conocimiento
del código en el equipo - Es una manera de aprendizaje
"Ese no es mi trabajo", "¿Cómo voy a criticar a alguien?", etc.
En un equipo maduro, la calidad del código es responsabilidad de todos
Así su equipo no utilice formalmente Code Reviews no significa que usted
no pueda pedirlos
Hacerlo a la ligera es
peor que no hacerlo
¡Saquémosle el máximo provecho a los Code Review!
No pedir
ayuda a tiempo
Un caso de la vida real
Alguien perdió todo
un día porque no
entendía por que código similar a este no compilaba
HttpServlet miServlet = new HttpServlet();error: HttpServlet is abstract; cannot be instantiated
¿Por qué tenemos miedo a preguntar? ¿Tenemos miedo de "exponernos"?
No saber algo es aceptable, pero es inaceptable no hacer nada para cambiarlo
Un buen líder sabe
que el tiempo haciendo "mentoring" es tiempo
bien invertido
¡Dejemos de
pensar en el "yo"
y pensemos más
en el "nosotros"!
KISS
Keep It Simple
& Straightforward
"Lo bueno, si breve
¡dos veces bueno!"
La codificación
siempre debería ser
un proceso iterativo
¡TDD ayuda,
pero TDD no
es necesario!
Siempre empecemos
por hacer lo más
sencillo posible
Agregamos nueva funcionalidad, poco a poco
Escribir Código
- Haz que funcione
- Haz que sea limpio
- Haz que sea rápido
YAGNI: You Aren't
Gonna Need It
¡Siempre codificar iterativamente!
No usar más
de un return
Los puristas de la programación abogan
una función debe
tener solo un return
En teoría eso está muy bien, pero si hacemos código más frágil
entonces no está bien
public T foo() {
T t = null;
if (/* algo */) {
t = ...; // El caso trivial
} else {
// mucho código
t = ...;
}
return t;
}Ese código está bien, siempre y cuando el
caso trivial con
el tiempo no mute
public T foo() {
T t = null;
if (/* algo */) {
t = ...; // El caso trivial
// Alguien pone código aquí
// modifica el valor de T,
// introduciendo bugs
} else {
// mucho código
t = ...;
}
return t;
}¡return al rescate!
public T foo() {
if (/* !algo */) {
return ...;
} else {
// varias líneas
// de código
// para calcular
// un valor de retorno
return ...;
}
}La intención del if es mucho más clara ¿no?
"Say what you mean,
mean what you say!"
El primo hermano del código culposo...
public T foo() {
T t = null;
try {
// código
t = ...;
} catch (FiFaiFuException e) {
t = ...; // Valor por defecto
}
return t;
}¡Este es aún más
fácil de romper!
public T foo() {
try {
// código
t = ...;
return t;
} catch (FiFaiFuException e) {
return ...; // Valor por defecto
}
}Algunas herramientas de estilo se quejan cuando
hay "muchos" return
Métodos Cortos
+ Muchos Return
= Buen Código
¡Que lo puristas
no nos quite
lo prácticos!
Código Spaghetti
en Try / Catch
Si un código se ve "raro",
es muy, muy probable que tenga bugs, sea difícil de modificar y de probar
El código Spaghetti usualmente tiene flujos
de ejecución que
no son obvios
¡El código Spaghetti en
un Try / Catch es
mil veces peor
por que maneja errores!
"Quis custodiet
ipsos custodes?"
¿Quién maneja
los errores del código
que maneja los errores?
Código Limpio
- No debe haber nada antes del try
- No debe haber nada
después del último catch - Las sentencias del try deben
ser triviales o invocar a un método
public T foo(/* parámetros */) {
try {
return doFoo(/* (¿otros?) parámetros */);
} catch(UnaExcepción e | OtraExcepción e1) {
// manejo de ambas excepciones
} catch(AlgunaExcepción e) {
// manejo de esta excepción
}
}
private T doFoo(/* some argmuments */) throws AnException,
OtherException, SomeException {
// Clean Code!
Bar bar = foo.do(); // lanza UnaExcepción
bar.baz(); // lanza OtraException
if (bar.isBlitz()) {
bar.platz(); // lanza AlgunaException
}
return bar.doo();
}¿Qué pasa si tengo que usar una variable
dentro del catch?
public void foo() {
T t = ...;
try {
// lógica del método
// puede lanzar una excepción
} catch (MiExcepción e) {
// t sólo es visible si
// está por fuera del try
LOGGER.info("Algo fallo con {}", t);
}
}Podemos crear un método donde t sea un parámetro
public void foo() {
T t = ...;
algoPeligroso(t);
}
private void algoPeligroso(T t) {
try {
// uso t, posiblemente lanza
} catch (MiExcepción e) {
LOGGER.info("Algo fallo con {}", t);
}
}¡El código más limpio debe ser el que maneja errores!
Lanzar Exception Atrapar Exception
En Java hay 2 tipos
de excepciones:
checked y unchecked
Las unchecked evidencian errores de código.
No debería ser atrapadas. ¡Nunca!
¡Las solución a una excepción unchecked es cambiar el código!
Excepciones Unchecked
- NullPointerException
- IndexOutOfBoundsException
- IllegalArgumentException
- etc.
Pero todas las excpeciones, checked o unchecked, comparten un ancestro común: Exception
Si yo atrapo Exception, atrapo todo incluso lo que no debería ser atrapado
Estoy seguro que el 95%
de los errores en producción con NPE se deben a un catch Exception
Si yo lanzo Exception, alguien tiene que
atrapar Exception
Usualmente la gente
lanza y atrapa Exception por pereza
¡Lanza solo que puedes lanzar
y atrapa solo
lo que lanzas!
No darle la importancia que merecen los errores
¡Causa #1 de terminaciones inesperadas de software!
Hacemos mal manejo
de errores porque
no probamos los
flujos de errores
¿De quién es
la responsabilidad
de hacer software
de la mejor calidad?
¡TODOS!
Usamos pruebas
unitarias, usamos
pruebas manuales, hablamos con
los testers, etc.
A veces cuando un error inesperado sucede, preferimos "silenciarlo"
Tratar de manejar un error que "nunca debió suceder" silencia el error
¿Por qué
silenciamos errores?
Por miedo a qué
lleguen a producción
Los errores silenciados, simplemente se manifiestan de otra manera
Manejo de Errores
- Validar Parámetros (IllegalArgument, IllegalState)
- Usar AssertionError
¿Si una variable es
null, qué significa?
public String getDescripción(Map<String, String> data,
String id) {
if (data == null) {
return "";
}
String descripción = data.get(id);
if (descripción == null) {
return "";
}
return descripción;
}
Un usuario que no
puede completar su compra, seguramente
irá a comprar a otro lugar
public String getDescripción(Map<String, String> data,
String id) {
// Puede lanzar NPE
String descripción = data.get(id);
if (StringUtil.isEmpty(descripción)) {
throw new
AssertionError("Descripción vacía para id " + id);
}
return descripción;
}
El desarrollador, el tester,
el PM, el PO, el cliente... ¡alguien lo va a ver antes que un usuario!
Si el usuario lo ve
primero, va a ser muy sencillo encontrar el error
¡Y ya que probamos nuestros errores, escojamos los
mensajes de error!
También en
las pruebas unitarias
¡Hagamos
software resilient!
Usar i para todas las variables de ciclos
Hay 2 tipos de ciclos
- Repetimos un código n veces
- Generamos una secuencia
Hay un caso especial del segundo caso: generar
los índices válidos
de un arreglo
¡Para todo lo demás, hay mejores nombres!
for (int veces = 1; veces <= total; ++veces) {
// para ciclos que repiten instrucciones
}for (int n = 2; n <= total; n += 2) {
// para ciclos que repiten instrucciones
}