Category: Teoría


Buenas Prácticas

Sobre como el concepto de buenas prácticas se desmorona sobre sí mismo (en inglés)
 

¿ABM o ABCC?

La sigla ABM viene de los términos Alta, Baja y Modificación. Y se refiere a las acciones que podemos hacer sobre una lista de objetos. Es decir, Imaginemos que tenemos un programa en el cual podemos ver un catálogo de productos. Sobre este catálogo normalmente podemos Agregar, Borrar o Modificar un elemento.

Hasta acá todo parece bastante simple. Pero me gustaría centrarme un poco en la parte de la modificación. Una modificación es un término ambiguo. ¿Qué implicaría modificar uno de estos artículos? Bueno. Quiere decir dos cosas distintas. Y ningún usuario les va a pedir esto de forma suficientemente explícita.

Sigamos con el ejemplo y asumamos que un usuario quiere cambiar el precio. Una pregunta que la mayoría no hace es si lo quiere cambiar porque se equivocó al cargarlo o porque la inflación requiere que nuestros productos cuesten más a partir de este momento. Y lo que implica esta diferencia es abismal.

Mirando el producto no vamos a notar la diferencia, pero si miramos también todas las facturas generadas hasta el momento se empieza a ver la brecha. En un caso los cambios son retroactivos. En el otro no.

Tal vez las facturas no sean el mejor ejemplo, porque seguramente en las mismas se guarda también una copia del precio y el monto, junto con cotizaciones y otros valores que afectan el total. Así que por las dudas veamos otro ejemplo. Uno con el que yo sufrí en persona.

  1. Tenemos una lista de personas. Uno de los atributos de esta persona es su categoría (Empleado de planta, Administrativo, Gerente, Invitado, Asesor externo, etc.)
  2. Y tenemos también una lista de entradas y salidas a la empresa.
  3. Me piden que una persona debía ser modificable, es decir que, entre otras cosas, su categoría podía cambiar.
  4. Luego de varios meses de usar el programa un asesor externo se modificó para ser un administrativo.
  5. Un par de días después recursos humanos estaba verificando un reporte de entradas y salidas y noto que esta persona figuraba como si siempre hubiera sido un administrativo.
  6. Yo tuve que rediseñar mi programa para que los cambios se aplicaran de ahora en más y no fuera una simple modificación del registro de la tabla.
  7. Un tiempo después Recursos humanos corrige el número de documento de otra persona que estaba mal. Pero verificando los listados nota que el cambio solo se aplica desde el momento en que se corrigió y no desde el principio…
  8. Pienso en como corregir esto y llego a la conclusión de que implicaría deshacer el último cambio que hice.
  9. Agarro la escopeta doble caño y me dirijo a RRHH. (No, mentira. Pero ganas no me faltaron)
  10. Finalmente entendí que estábamos hablando de dos conceptos diferentes.

Estos dos conceptos di en llamarlos Corregir y Cambiar.

Esto es a lo que quería llegar ABCC es Alta, Baja, Corrección y Cambio.

La mayoría de las veces se van a encontrar con este dilema y se les va a escapar por debajo de las narices hasta que sea muy tarde.

Recuerden. No existe tal cosa como la modificación. Existe más de un concepto bajo la misma palabra. Traten de averiguar a cual se están enfrentando.

¿Compacto o explícito?

Ese es el gran dilema. Cuando escribimos un programa deberíamos tratar de ser claros para beneficio otros programadores o compactos para beneficio del programa. Muchas veces me encontré con algo así:

If a = True Then 
   b = True 
Else 
   b = False
End If

En este caso se me ocurren muchas optimizaciones que podemos llevar a cabo. Por empezar por el hecho de que comparar una variable a True o False no tiene sentido. Por qué decir If x = True cuando podemos decir If x.
Pero en definitiva este bloque se puede resumir en algo así

b = a

El gran problema es que un código tan simple como ese, la mayoría de las veces viene tan disfrazado que nos cuesta reconocerlo. Miren esto:

IF Objeto.Propiedad = False Then
  Lista.Items.Add(new Item("Alguna Descripcion", True))
Else
  Lista.Items.Add(new Item("Alguna Descripcion", False))
End If

Cuántos de Ustedes se darían cuenta de que esto es un:

Lista.Items.Add(new Item("Alguna Descripcion", Not Objeto.Propiedad))

Esta es otra forma clásica del mismo problema:

If a = b Then
  return True
Else
  Return False
End If

Cuando esto podría escribirse tan fácil como:

Return (a = b)

Para terminar me gustaría hacer referencia al operador ternario. Esta instrucción que existe en casi todos los lenguajes de programación nos hace la vida más compacta a los programadores (aunque también tiene sus detractores). Último Ejemplo:

If a = b
  Return "Hola"
Else
  Return "Chau"
End If

Si bien puede parecer que no hay forma de comprimir este algoritmo, la hay. Con el operador ternario lo podríamos expresar así:

Return IIF(a = b, "Hola", "Chau")

Esta función toma tres parámetros. Evalúa el primero. Si el resultado es verdadero devuelve el segundo parámetro, en caso contrario devuelve el tercero.

Todos estos cambios no tienen como único objetivo hacer más corto el código. También sirven para acelerarlo. Recuerden que ahorrarse un par de ciclos de procesador no es la gran cosa, pero… ¿Qué pasa si un algoritmo así se usase para calcular el color de un pixel en alguna aplicación gráfica? Esto implica que este algoritmo se ejecutaría al menos 1.000.000 de veces por cada imagen llevada a la pantalla. Imagínense eso unas 20 veces por segundo. Cambios tan simples como estos pueden ser la diferencia entre el éxito o fracaso de una aplicación. Pero bueno. Si la claridad del código es tan importante…