Calidad de c´ odigo

Si bien este proyecto tuvo una fecha de entrega, el cliente tiene pensado seguir trabajando en el desarrollo del mismo. Esto hace que sea de gran importancia de que el producto est´e desarrollado siguiendo buenos est´andares y pr´acticas de codificaci´on.

Por este motivo el equipo de desarrollo tom´o ciertas decisiones para garantizar este requerimiento no funcional.

7.3.1.1 Typescript

Typescript es un lenguaje de programaci´on “superconjunto” del lenguaje JavaS- cript, al cual es compilado. Ofrece una multitud de beneficios para los desarrolla- dores como pueden ser el tipado est´atico a la hora de definir variables, funciones y par´ametros, lo que hace que se puedan detectar y prevenir errores de en tiempo de compilaci´on en lugar de tiempo de ejecuci´on. Adem´as, esta funcionalidad del tipado facilita la legibilidad del c´odigo ya que de antemano se puede saber qu´e par´ametros toma una funci´on y qu´e tipo retorna.

Con este y otros beneficios hace que un proyecto que utilize TypeScript sea, en opini´on del equipo, mucho mas mantenible, facilitando el trabajo en equipo gracias a la claridad y legibilidad del c´odigo y por lo tanto haciendo que los desarrolladores trabajen de forma m´as eficiente. Al comenzar, el equipo de desarrollo contaba con muy poca experiencia con TypeScript por lo que en las primeras etapas se not´o

una dificultad adicional al momento de implementar nuevas funcionalidades. Sin embargo los beneficios de utilizar TypeScript fueron r´apidamente visibles y como retrospectiva utilizar este lenguaje fue la decisi´on correcta.

7.3.1.2 Est´ andares de nomenclatura

Los est´andares de nomenclatura son reglas y convenciones que se establecen para nombrar variables, funciones, clases y otros elementos del c´odigo fuente en un proyecto de software. Estas reglas incluyen la longitud m´axima del nombre, el uso de may´usculas y min´usculas, la separaci´on de palabras, el uso de prefijos y sufijos, entre otros. Es importante, a la hora de escribir c´odigo, dejar de lado las preferencias personales de cada uno y tomar un lineamiento de equipo. Esto hace que la base de c´odigo sea consistente, lo que una vez m´as, quita carga cognitiva de los integrantes del equipo al tener que leer c´odigo. Por esto el equipo decidi´o crear su propio est´andar basado en ya existentes a la hora de nombrar diferentes elementos de las piezas de software.

Nombres de archivos

Todo el c´odigo de Fidelite, por el momento se encuentra escrito en TypeScript (a excepci´on de la consola que fue escrita en JavaScript). El equipo decidi´o que si fuera posible, los nombres de los archivos declararan la raz´on de ser del mismo, que cada nombre declarara su intenci´on. Los siguientes son algunos ejemplos de estos:

Como se puede apreciar en la imagen, cada nombre de archivo est´a escrito en kebab-case: usando min´usculas y con las palabras se separan por el car´acter “-”. En algunos casos se declara el tipo del archivo, si es una prueba unitaria tienen el prefijo

“.test”, si son tipos de entrada o salida tienen el prefijo “.input” o “output”.

Nombres de funciones y variables

Para nombrar funciones y variables nos apoyamos en la literatura de Robert

Figura 7.2: Ejemplo de nombre de archivos

Martin “The Clean Coder” [58] en la cual el autor presenta el caso por tener fun- ciones y variables, de la misma manera que hicimos con los archivos, que muestren intenci´on.

Por ejemplo, si consideramos el c´odigoconst p = new Person(); el nombre de la variable “p” no cumple con nuestra especificaci´on ya que este nombre no especifica qu´e es o su motivo de existencia. Para que cumpla nuestro est´andar debe ser llamada por ejemploconst createdPerson = new Person();.

A diferencia que con los archivos, las funciones y variables deben utilizar “camel case”, el cual utiliza letras min´usculas a excepci´on de la primer letra de cada palabra (menos la primera) la cual va en may´usculas.

Nombres de Tipos

Al momento de nombrar tipos el equipo opt´o por declarar su intenci´on en su

nombre, por ejemplo la funci´on “createCustomer” recibe como par´ametro un da- ta transfer object del tipo “CreateCustomerInputDTO”. De esta forma se declara correctamente la intenci´on de este tipo.

Existen algunas excepciones, por ejemplo para los tipos gen´ericos del dominio como lo sonCustomer oCompany, etc.

Nombres de Columnas de Base de datos

Las columnas en nuestras bases de datos, ya sean relacionales o no deben ser escritas con snake case (min´usculas separadas del s´ımbolo “ ”). La raz´on para la misma es que PostgreSQL, nuestro motor de base de datos, requiere su uso (por defecto no distingue may´usculas y min´usculas y genera nombres con este estilo). Y al tener una restricci´on para uno de nuestros motores, decidimos extender la restricci´on a DynamoDB y mantener un esquema de nombres homog´eneo para nuestros datos.

7.3.1.3 Est´ andares de codificaci´ on

El equipo de desarrollo decidi´o utilizar ESLint [59] la cual es una herramienta de linting de c´odigo para JavaScript y TypeScript. Esta hace cumplir diferentes

“reglas” de estilo acordadas por el equipo y tiene el efecto de que el c´odigo sea m´as heterog´eneo de leer, not´andose en menor manera las preferencias individuales de cada programador. Esta herramienta tambi´en fomenta buenas pr´acticas de c´odigo, detectando“code smells”[60] y proveyendo formas de solucionarlos.

Entre las funcionalidades de ESLint se encuentran la capacidad de detectar erro- res de sintaxis, detectar variables no utilizadas, aplicar convenciones de codificaci´on espec´ıficas, y m´as. Adem´as, se puede configurar para que se ajuste a las necesidades espec´ıficas de cada proyecto mediante la personalizaci´on de las reglas.

Para el caso de este proyecto el equipo opt´o por utilizar un conjunto de reglas las cuales es una de las m´as populares, que es el conjunto de reglas dise˜nado por

la empresa AirBnB [61]. Estas reglas de ESLint deben ser cumplidas a la hora de integrar c´odigo a las ramas principales, estas son, “master” y “develop”, por lo que siempre se asegura que el c´odigo cumpla con los est´andares de codificaci´on.

A´un as´ı no es suficiente para garantizar una buena calidad de c´odigo, por lo que el equipo de desarrollo le di´o especial ´enfasis a algunos de los puntos mencionados en el libro “Clean Code” de Robert Martin [58]. A continuaci´on se desarrollan algunos puntos que tuvieron en cuenta el equipo de desarrollo:

Nombres significativos: Los nombres de las variables, funciones, clases, m´odulos y otros elementos del c´odigo deben ser descriptivos y significativos para facilitar la comprensi´on del c´odigo.

Funciones: Las funciones deben ser peque˜nas, hacer una sola cosa y hacerlo bien. Adem´as, deben tener nombres descriptivos y los par´ametros deben ser pocos y significativos.

Comentarios: Los comentarios deben usarse con moderaci´on y solo cuando sean necesarios para explicar un concepto complejo o una soluci´on espec´ıfica.

Pruebas y refactorizaci´on: El libro hace hincapi´e en la importancia de las pruebas automatizadas para garantizar que el c´odigo funcione correctamente y la refactorizaci´on para mantener el c´odigo limpio y legible.

7.3.1.4 Pruebas unitarias

Uno de los requerimientos no funcionales es el de la cobertura de c´odigo de un 70 % en pruebas unitarias. Alcanzar altos niveles de cobertura de c´odigo es ´util para mejorar la calidad del mismo ya que facilita la identificaci´on de posibles errores pasados por alto por otros m´etodos de prueba. Adem´as es importante si se quiere trabajar con el c´odigo a largo plazo y con distintos grupos de desarrolladores, lo que es el caso para este proyecto.

Para cumplir este requerimiento el equipo de desarrollo implement´o pruebas unitarias para las distintas partes del software como puede ser la l´ogica de negocio y el motor de reglas. Como resultado se alcanz´o un 72 % de cobertura de c´odigo (statements) para estas partes del software (ver figura 7.4.1 debajo).