- ¿Qué es una base de datos? - noviembre 7, 2020
- ¿Es la programación una profesión para ti? - septiembre 3, 2020
- Temporada 2020-2021 - julio 15, 2020
Introducción
Todos sabemos que un programa software es un conjunto de instrucciones que son dadas a un ordenador, pero… existen infinidad de formas de escribir estas instrucciones por parte de los programadores.
Una vez los programas son escritos por los desarrolladores, pasará un tiempo hasta que vuelva a ser modificado el código fuente, lo normal es que sea modificado por los mismos desarrolladores que lo escribieron la primera vez, pero también es muy normal que sea modificado por otros desarrolladores diferentes a los primeros que escribieron dicho código fuente.
Una de las primeras preguntas que se nos viene normalmente a la cabeza a las personas que nos dedicamos al desarrollo de software cuando vemos por primera vez el código fuente de otro compañero es: ¿Por qué lo has hecho así? Vaya jaleo de código… yo lo hubiera hecho de forma diferente.
En este post voy enseñarte el por qué debes de escribir código fuente de calidad y sencillo.
Calidad del código fuente
Cuando un programador se encuentra desarrollando un programa no hay nada entre el programa que está escribiendo y él, por lo que, el resultado exitoso del desarrollo de dicho programa dependerá en gran medida de la calidad del código fuente que escriba.
¿Cómo mediría yo la calidad del código fuente? Lo tengo claro. Para mí, un código fuente con calidad es aquel que, además de hacer lo que tiene que hacer en términos funcionales, es fácil de comprender y modificar por otros programadores, básicamente que puedas leerlo como si de una novela se tratara.
Un código fuente con calidad te va a permitir reutilizarlo, extenderlo y mantenerlo de forma fácil, y no únicamente a ti, a cualquier persona que utilice tu código fuente.
Desde mi punto de vista, en el entorno del desarrollo de software existe la creencia, dentro de los desarrolladores, de que cuanto más complicado es un código fuente y más tenemos que explicárselo a otros desarrolladores, mejores desarrolladores somos y más sabemos. Estoy completamente en desacuerdo con esta creencia, el codigo fuente tiene que ser simple, que no necesite explicación y documentación más allá de la funcional.
Resumiendo, un programador debería hacer todo lo posible para que el código fuente que escribe sea fácil de usar y de entender por otros programadores, que el mantra que marque sus desarrollos sea la simplicidad.
¿Qué disminuye la calidad?
Voy a ser muy directo en ésto, por lo que, iré al grano…
No escribas código innecesario
No escribas código fuente hasta que realmente lo necesites, no lo escribas pensando que en un futuro lo vas a necesitar… a día de hoy, el futuro no puedes predecirlo, por lo que existen muchas probabilidades de que tengas que cambiar su funcionamiento.
Regla 1: No escribas código hasta que lo necesites y elimina todo el código que no está siendo usado.
Parte siempre de la base de que es imposible desarrollar un sistema que no cambie nunca, un sistema siempre cambiará mientras continúe teniendo usuarios.
Estarás conmigo en que los desarrolladores solemos añadir funcionalidades extra que no piden los clientes y código fuente para «por si acaso me piden ésto pues ya lo tengo hecho y así tardo menos en hacerlo luego», evita todos estos malos hábitos si quieres aumentar la calidad y simplicidad de tu código fuente.
No escribas código difícil de cambiar
Como desarrolladores debemos de evitar que el código fuente que escribimos sea totalmente dependiente de la operativa para la que ha sido solicitado.
Voy a ponerte un ejemplo: Piensa en un proyecto a X años vista, el primer día te entregan los requisitos funcionales del desarrollo y te pones a trabajar. Una vez acabas el desarrollo, la operativa funcional del cliente ha cambiado y te solicita ciertos cambios a la hora de ejecutar diversos procesos solicitados anteriormente. El impacto que tienen los cambios solicitados en el proyecto debería de ser el menor posible, y estará directamente relacionado con la calidad del software que has escrito.
Regla 2: No escribas código fuente pensando en que los requisitos funcionales no pueden cambiar.
Es cierto que existen metodologías de desarrollo software cercanas al cliente que te permitirán saber si algún requisito funcional va cambiando, pero, independiente de la metodología que utilices, tus desarrollos no pueden ser cerrados para un único funcionamiento.
No seas demasiado genérico
Hay que tener cuidado con el punto anterior, muchos desarrolladores generalizan tanto el desarrollo que lo llevan hasta el punto conocido como «overengineering», traducido al castellano, demasiado diseño y desarrollo. Es decir, en ciertas ocasiones diseñamos y desarrollamos demasiado un sistema, llegando a perder el norte intentando hacerlo lo más genérico posible para que valga para el mayor abanico posible de funcionamientos.
Los problemas que acarrea el «overengineering» son:
- No puedes predecir el futuro, por lo que la solución genérica que diseñes y desarrolles nunca será lo suficientemente genérica para satisfaccer los requisitos actuales y futuros.
- Desde el punto de vista del usuario final el software tiene que ser específico, no debes de satisfaccer requisitos funcionales específicos con funcionamiento genérico, ya que la experiencia de usuario disminuirá.
- Escribir código genérico implica que vas a escribir código innecesario. (Regla 1).
Regla 3: Escribe código genérico con los elementos correctos y de la forma correcta, y únicamente en aquello en lo que necesites hacerlo.
Es muy importante evitar el «overengineering», ya que cuando caes en este hábito estás diseñando para hacer el código fuente más difícil en lugar de simplificarlo.
Conclusiones
Existen muchas formas de mejorar la calidad del software que escribes, y dentro de todas esas formas, te he presentado las tres más básicas que puedes aplicar directamente en tus desarrollos:
- No escribas código hasta que lo necesites y elimina todo el código que no está siendo usado.
- No escribas código fuente pensando en que los requisitos funcionales no pueden cambiar.
- Escribe código genérico con los elementos correctos y de la forma correcta, y únicamente en aquello en lo que necesites hacerlo.
La programación de calidad se basa en los hábitos y buenas prácticas que aplicas al desarrollo de software que realizas, por lo que te animo a que empieces a aplicar éstas tres primeras reglas que te he explicado en el artículo. En próximos artículos voy a seguir adentrándome en este tema, ya que lo considero esencial para todos los programadores.