Buenas prácticas al programar (con código)

Muchos disfrutan programar y resolver laberintos algorítmicos en su lenguaje favorito, pero lo que a nadie le gusta, es meterse en un código viejo o incluso peor, en un código escrito por otro.
A mí me ha tocado hacerlo ya varias veces, algunas veces ha sido malo, otras veces peor, muchas veces termino y reescribiendo parte del código que me sacan sangre por los ojos, por eso es que he aprendido algunas buenas practicas al momento de programar.

Advertencia: esto viene desde la perspectiva de un Data Scientist, por lo que estos casos en general aplican a ETL y modelos de Machine Learning..

Piensa lo que vas a programar antes de hacerlo

Muchas veces he visto que al recibir una tarea la gente se sienta a programar presionando teclas intentando lograr lo solicitado y eso en general produce muy mal código.
Las líneas de comando escritas, reflejan la lógica con la que el desarrollador resolvió el problema, por lo que si no tiene esta, será un hilo dificil de seguir.
Esto de ayudará a nombrar variables, escribir comentario y dividir el código en partes.

El codigo debe correr secuencialmente

Con la aparición de los lenguajes interactivos, como python R y Julia entre otros, he visto muchas veces scripts que para ejecutarse deben correrse por pedasos, algo asi como : ejecutar desde la linea 10 a las 35, luego ejecutar la linea 1 y 2, luego tomar el resultado de la linea de y pegarlo en la linea 40.
Eso no es programar, es planillar en R o Python.

Si es un ETL, que tenga estructura de ETL

Trata de usar estructuras predefinidas y cuando procesos datos, muchos de esos procesos seran ETL, si es posible sigue los siguientes pasos:
1) Scrip de configuracion de ambiente
2) Librerias
3) Cargar Data
4) manipular data
5) guardar el resultado

Divide el código en partes

Intenta que cada script ejecute una tarea particular guardando el resultado en algún storage para una siguiente etapa, la cual solo tendra en comun que lee la data guardada anteriormente

Dale buenos nombres a las variables

Servirá para retomar el codigo en el futuro:
1) nombra las funciones como verbos que decriben lo que hacen
2) nombra los objetos con sustantivos que los describen
3) si tienes un objeto que representa una manzana grande, nombrala manzana_grande, si no te gusta ese standard usa otro como manzanaGrande, pero se consistente
4) si tienes tablas con 2 columnas que son el bismo valor, póneles el miusmo nombre

No uses simbolos no ASCII

no crees variables con letras como ñ o áéíóú e incluso espacios, en algún minuto sera un problema

Usa control de versiones

no quieres perder todo tu trabajo, o imagina que en algún momento hiciste algo mal y quieres volver atras. respalda tu trabajo en algo como GIT, hay muy buenos cursos online,

Trabaja los datos en formato tidy

Las nuevas herramientas para manipular datos están enfocados en hacerlo con datos en formato tidy o tablas "largas"
https://en.wikipedia.org/wiki/Tidy_data

El formateo de los datos va al final

Lo recomendad es unar los objetos y/o variables en su formato nativo en el lenguaje y dejar para el final el formateo para el ojo humano.
Por ejemplo si trabajas con porcentajes y los quieres mostrar, pasalos de 0.1 a 10% solo antes de mostrarlos.
Otro ejemplo: Si tienes una fecha, que sea un objeto tipo Date, aunque se muestre como AAAA-MM-DD y quieras verlos como DD-MM-AAAA, deja para el final el formateo justo antes de mostrar.

Genera un log de ejecución

Con un try y un catch puedes generar un log, por ejemplo en R:

#!/bin/Rscript
source("/opt/configuracion/init.R") #script que contine funcion de log y varias otras cosas
tryCatch({
  # en general... proceso identificado por tabla de destino
  param = c(
    proc = 'nombre proceso'
  )

  ### aca hace lo necesario....

  write_log(param[['proc']], mensaje = archivo)

},error=function(e) {
  write_log(param[['proc']],exit_code = -1,mensaje = paste(e$message,collapse = " "))
  print(e$message)
  }
)

Los parámetros no van en el código

El código puede tener muchos parámetros, pero los de ejecución, por ejemplo "fecha de ejecución" o ruta de archivo de entrada, es mejor que sean parametricos.
No puede ser que para cambiar un parámetro de ejecución sea necesario modificar el código, estos deben entregarse por la consola o por alguna interfaz web:

solo usando

  args = commandArgs(trailingOnly=TRUE)

O en python

import sys
args = sys.argv[1:]
archivo = args[0]

Lo que si, uede ser mas facil que el tu sftware tome parámetros por defecto en caso de no proveerse uno.

Pregunta final 🙂

Que te pareció? se te ocurre alguno mas?
dejamelo en los comentarios.

Saludos!

Print Friendly, PDF & Email