Un blog personal donde compartir experiencias e inquietudes relacionadas con internet, tecnología y otros asuntos interesantes
En lo que a desarrollo de software se refiere, como en casi cualquier otra profesión, disponer de un entorno de trabajo adecuado puede marcar la diferencia entre obtener un gran resultado o que nuestro trabajo sea un completo desastre.
Al respecto de esto, uno de los aspectos al que más atención deberemos de prestar es al diseño de los distintos entornos que participan en el ciclo de vida del software y a los procedimientos que definen el flujo de trabajo entre ellos.
Formación, práctica y constancia son tres de los pilares básicos en los que se sustenta la evolución de cada desarrollador. En ocasiones debemos aprender conceptos complejos de asimilar o de aplicar como parte de este proceso. Sin embargo, en otras ocasiones, son sutiles detalles los que nos hacen mejorar.
La elección de los nombres de los distintos elementos que intervienen en la programación es una de esas tareas que si bien no es técnicamente compleja, puede suponer un antes y un después en cuanto a la calidad del código que generamos.
Uno de los aspectos más delicados con respecto a los comentarios es la limpieza. Al contrario de lo que sucede con el propio código fuente, los comentarios no son procesados por el compilador, lo que quiere decir que éste no nos avisará si hay algo incorrecto o poco fiel con respecto a la realidad.
En muchas ocasiones utilizamos los comentarios casi para cualquier cosa, y siendo honestos, es que se prestan a ello y además podemos sacarle mucho partido. El problema es cuando permitimos que los usos alternativos perduren en el tiempo, pues lo único que conseguimos con ello es ensuciar el código.
Son muchos los detalles a los que debemos prestar atención mientras desarrollamos, tantos que en ocasiones relegamos un segundo plano a algunos como pueden ser los comentarios, el estilo del código u otros.
Para el que está acostumbrado a trabajar con redes de equipos Windows acceder a un equipo mediante hostname es algo habitual. Por el contrario, el que suele trabajar con sistemas basados en Linux en una red local sabe que por defecto suele ser un asunto algo más laborioso.
La curiosidad y la predisposición a probar cosas nuevas suelen ser cualidades bastante habituales entre las personas relacionadas con la tecnología, pero existen ciertas situaciones en las que estamos tan acostumbrados a realizar algunas tareas de una determinada forma que no nos cuestionamos el por qué o si es posible hacerlo mejor con algunos cambios.
Aprovechando que acabamos de escribir un artículo tratando los olores del código fuente no podíamos dejar pasar la ocasión para escribir sobre refactorización, un conceptos íntimamente relacionado.
Se dice que el código huele cuando a pesar de que no se ha identificado ningún bug y su funcionamiento es correcto, está escrito sin atender a los principios de diseño del software o haciendo uso de prácticas nada recomendables.
Existen múltiples motivos por los que podemos disponer de código fuente antes de versionarlo: que heredemos un proyecto ya existente, que se nos ocurra una idea y en un impetuoso alarde de entusiasmo vayamos directamente al código, etc. Pero para mi el principal motivo es que es la forma más sencilla de comenzar un proyecto y un repositorio en Git: instalo la aplicación o el framework que necesito, realizo una configuración básica y acto seguido creo el repositorio.
