Aquí estoy de nuevo con una nueva entrada en el blog, para hablar acerca de los errores que hice como programador junior cuando empecé a trabajar y que algunos de ellos aún sigo cometiendo, a pesar de trabajar en hábitos para mejorar mi manera de llevar a cabo mi trabajo como programador.
Antes de nada, me gustaría aclarar una cosa, para programadores principiantes. Este artículo no es una guía de cómo se debería de hacer ni hacerte sentir que no estás haciendo bien tu trabajo. Simplemente me gustaría enseñarte los fallos que cometí y enseñarte cómo detectar algunos de ellos y algunos pasos para evitarlos. Me gustaría remarcar, especialmente uno de ellos, que el no usar git, uno de los primeros pasos que hay que hacer es configurar la cuenta de git en la consola.
Yo mismo he cometido estos errores y he aprendido, o he tratado de aprender, de cada uno de ellos. He trabajado duro para formar hábitos de programación para ayudarme a evitarlos en lo máximo posible y te voy a dar algunos consejos para que tú lo hagas también.
A continuación voy a comenzar con ellos …
Escribir código sin un planning previo
A escribir código de calidad no se aprende en un día. Requiere de experiencia, preparación y estudio del código que se va a llevar a cabo. Esto es aplicable a cualquier programa o web que vayas a codificar, el software más simple o el software más delicado.
Uno de los errores más grandes que he cometido, y aún a veces cometo, cuando era principiante fue comenzar a escribir código inmediatamente sin pensar mucho ni investigar en otras posibles soluciones más eficaces.
Es lo mismo que cuando a veces antes de hablar es conveniente pensar lo que se va a decir antes de decir algo de lo que arrepentirse más adelante, con el código pasa lo mismo, digamos que es como una forma de comunicar nuestros pensamientos a través de líneas de código.
Escribir código de calidad es un proceso iterativo que requiere de varias etapas y de crear un hábito para seguirlo. El proceso consta de lo siguiente:
- Pensar en la solución
- Investigar acerca de la solución
- Planificar los pasos para llevarla a cabo
- Escribir el código
- Comprobar que soluciona el problema
- Refactorizar
Estos son a mi humilde entender los 6 pasos que hay que llevar a cabo para escribir un buen código. Para ello se necesita crear un hábito como he dicho anteriormente.
Algunas veces no será fácil, ya sea por presiones del cliente, por confianza en uno mismo … por lo que sea a veces nos saltamos el plan.
¿Cómo llevar a cabo estos pasos de una manera natural?
Lo que yo hago, es dejar el código y al día siguiente revisar si pudiera hacerlo de una manera más clara y eficiente. Y en su caso, contar hasta 10 antes de refactorizar una sola línea de código.
La programación se trata principalmente de leer el código existente, investigar qué se necesita y cómo se ajustaría dentro del sistema actual, y planificar la escritura del nuevo código con pequeños incrementos comprobables y testeables. La escritura real de nuevas líneas de código es probablemente solo el 10% de todo el proceso.
La programación es una actividad creativa que como toda actividad creativa necesita estimulación continua.
Planificar demasiado sin escribir una línea de código
Sí, aunque no lo parezca, planificar demasiado y a largo plazo es contraproducente. No se puede buscar la planificación perfecta, porque los objetivos cambian y lo que hoy es blanco mañana puede ser negro. Resumiendo, planificar a muy largo plazo es una gran pérdida de tiempo.
Mi traza ideal es planificar tareas, bien pensadas y estudiadas, pero una tarea simplemente.
¡¡¡ Planificar todas tus tareas, es algo que debería de ser ilegal !!!
Lo ideal sería, hacer una mezcla entre desarrollo ágil y en cascada.
Planificando en cascada (sistema líneal) para cada tarea, y teniendo la gestión, y la planificación de tus tareas usando una adaptación ágil. Además, esto nos permite organizar nuestras tareas en ramas de git.
Es el plan ideal, para mí, cuando decides hacer algo lo planificas y tratas de llevar tu plan paso a paso. Pero no puedes pensar en el después, después, después … siempre van a surgir bugs, cosas que hoy necesitas mañana no, nuevos desarrollos o nuevas peticiones de los clientes, etc …
Siempre hay que planificar en detalle lo próximo y más cercano. Pensando en la calidad del código, eso es algo que siempre hay que tratar de alcanzar la excelencia en la calidad del código.
Escribir comentarios sin sentido
Estoy aprendido, y aún me cuesta, que mientras menos comentarios, más fácil se entiende el código.
Un ejemplo podía ser el siguiente trozo de código con comentarios muy obvios.
// Start the curl handler. $ch = curl_init(); // Set the URL curl_setopt($ch, CURLOPT_URL, $url); // Set the header of the request curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
¡No seas ese tipo de programador! Si encuentras código como ese, por favor … ¡¡¡ Elimina esos comentarios!!!
Si tus compañer@s hacen esos comentarios, por favor, habla con ellos y explica que son comentarios inútiles. En mis inicios, la mayor parte de comentarios indicaban qué estaba haciendo cuando el uso de comentarios debería de ser para saber el porqué se está haciendo.
Este código sería igual sin comentarios y todo el mundo lo entendería.
$ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
Simplemente el uso de nombres descriptivos para variables y funciones eliminaría más del 75 % de comentarios de código, piensa sobre ello y verás como es así.
A continuación otro ejemplo de ello.
private function sumArray($array)
{
// Acumulator
$t = 0;
// Sum each number
foreach ($array as $key => $n) {
$t = $t + $n;
}
// Return the total of sum
return $t;
}Este código sería equivalente y más fácil de entender y de mantener.
private function sumArray($numbers)
{
$sum = 0;
foreach ($numbers as => $number) {
$sum += $number;
}
return $sum;
}Todos hemos cometido esos errores, pero cada día que revisemos nuestro código mejorémoslo y refactoricemos.
Hagamos un código mejor para todo el mundo.
No usar herramientas para control de versiones
Sí, GIT o algún software similar … como me arrepiento de no haberlo usado en la universidad … la de horas que me hubiera ahorrado de reescribir código. Y más aún, si cuando empecé hubiera tenido mi chuletario de alias de git.
Un sistema de control de versiones no se trata simplemente de subir y compartir tus cambios de código con tus compañer@s.
Te permite conocer qué has hecho, qué pasos has seguido para llegar a la solución actual, y te dará la solución a preguntas que de otra manera sería muy difícil saber por qué se hizo así.
Usando mensajes descriptivos cuando hacemos un ‘commit’ es otro canal de información, que tenemos a nuestra disposición que también ayudaran en el futuro a mantener el código y optimizarlo.
Hay que acostumbrarse a hacer ‘commit’ a menudo y de manera coherente. Usando verbos en presente y siendo detallados en los mensajes. Si necesitamos más de una línea en la descripción necesitamos hacer un resumen breve y conciso de los cambios.
Puede ser una señal de que nuestro commit es muy largo, además puede significar que estamos haciendo en un único ‘commit’ más de lo necesario.
Una vez que tenemos nuestra tarea completada, lo ideal es rebasear todos los commit en uno solo, el tener un único comentario descriptivo de lo que hace la tarea nos ayuda a tener el historial de git limpio y ordenado. Lo cual agradeceremos a la larga.
Ventajas de usar un Sistema de Control de código fuente
Los sistemas de control de código fuente tratan de detectar cosas, es su principal función aunque no lo parezca. Algunos ejemplos son:
- Vemos una función que no sabemos que hace ahí, podemos buscar el commit, ver por qué está ahí y qué solución aportaba.
- Observamos código erroneo, GIT nos da la posibilidad de buscar por commit y ver qué código es el que está produciendo el error y en qué commit fue añadido.
- Tenemos muchos commit asociados a una tarea, hagamos rebase y dejemos un commit único con la información relevante de los cambios.
Esto son solo algunos ejemplos de la potencia y la funcionalidad que GIT nos ofrece, pero hay mucho más.
Aprender a usar GIT te hace ser más experto. Mientras más comandos y más uses GIT mejor y más experto programador te harás. Además, si usas alias para las órdenes más comunes de git también serás más eficiente.
Hacer código spaguetti (Spaguetti Code)
Y por último, hacer código espaguetti casi sin darse cuenta. Es algo que se aprende con el tiempo.
Spaguetti code
Pues esto ha sido una especie de primera parte de errores que he cometido. Todo basado en mi experiencia personal.
Espero que os sirva y ayude a mejorar a hacer entre todos un código limpio y mejor.