Algunas recomendaciones sobre la creación de software

En los últimos días he tenido muchos libros como "Clean code", todos deberíamos hacerle caso para no tener que reescribir o refactorizar paquetes desde el inicio, otras fuentes que tengo para hacer esta entrada son "Análisis y diseño de sistemas", "Desarrollo de software basado en reutilización" y por ultimo "Conceptos avanzados en desarrollo de software libre".

Primero tengo que abordar el método que la mayoría de programadores me recomendaron sobre la creación de software, ya que nadie por más artista que sea será capaz de crear cosas sin inspiración y motivación, a fin de cuentas el software tiene al menos un objetivo y es necesario a pesar de no tener un objetivo propio, siempre mantener la practica y programar de vez en cuando, para facilitar la lectura voy a intentar resumir todo lo que he aprendido en puntos clave:

1-Plantear las ideas: Es necesario que todo esté planteado, incluso antes de empezar a programarlo el software debe estar en fase "beta cerebral",  esto quiere decir conceptual mente terminado y de acuerdo a la experiencia adquirida durante años cada idea debe ser totalmente realizable, obviamente la experiencia de años no se adquiere en minutos de tal manera que para empezar a tomar experiencia es necesario repetir una y otra vez el proceso de desarrollo de software, llegado a este punto puedo asegurar que la mejor idea que podemos tener es hacer cosas muy pequeñas y normalmente planteadas por un programador con experiencia o profesor, se pueden encontrar muchas web con problemas planteados y resueltos, Solearn es una excelente opción para aprender un lenguaje y al mismo tiempo relacionarse con cientos de programadores, este proyecto de aprendizaje empezó como un curso online gratuito con titulación incluida y poco a poco se ha convertido en una serie de cursos gratuitos con una red social integrada para programadores.

2-Hacer cosas bajo pedido: Me gusta trabajar cuando tengo una idea por que el proyecto estará completo mucho mas rápido, pero siempre vamos a terminar trabajando para otros, entonces tiene mucho sentido programar ideas ajenas, esto lo hago normalmente buscando en internet o alguna entrada de foro, hago mi solución al problema, aunque esto signifique hacerle la tarea a algún programador, siempre será de provecho como practica.

3-Módulos pequeños de un software grande: Cuando estamos pensando en algún proyecto muy grande lo único que vamos a tener es frustración, para evitar problemas de estrés y traumas mi solución así como la de todos los programadores a los que les pregunté, es crear pequeños módulos que funcionen por si mismos, aparte de tomar práctica en hacer proyectos reutilizarles en el tiempo, ayuda mucho a dar por finalizados los detalles que se encuentran entre el inicio y el final del proyecto, se adelantan cosas importantes o al menos necesarias para crear el gran proyecto final, entonces el estrés desaparece y los pequeños logros ayudan a mantener la motivación.

4-Diseño incremental: Esto es un concepto de desarrollo de software como tal, significa iterar en el desarrollo del programa hasta que todas las funcionalidades estén implementadas, significa repasar el código hasta que se nos acaben la lista de tareas que teníamos como deuda en el planteamiento, es necesario empezar solo con una tarea, una vez terminada y probada se procede a introducir la siguiente, cuando todo está funcionando y no quedan funciones por implementar podemos decir que proyecto está terminado, no es posible programar sin errores, pero al menos los errores no serán conocidos, al menos dentro de las posibilidades, el programa funcionará muy bien.

5-Comentarios, siempre y en todo lugar: De los anteriores puntos creo que este es el más importante ya que la mayoría de cosas se entienden con el tiempo, pero esto debe ser una práctica que se haga desde el principio, una vez en medio de un examen encontré un error bastante fuerte que era motivado por no identificar correctamente cual llave (estas son llaves { } también llamados corchetes ) correspondía a que cosa dentro del programa, el proyecto era en java y como es bien sabido en java, C++ y C# los corchetes son la división entre métodos, selecciones y bucles, por tanto pueden dar muchos mas problemas que un simple punto y coma, desde ese momento he puesto un comentario en cada llave que dice exactamente que cosa está cerrando, luego de ello me resulta mucho mas fácil organizar los corchetes que de una u otra forma siempre pueden moverse, también un comentario bien hecho es capaz de dejarnos en claro el orden, razón o funcionamiento de una linea de código especifica, tiendo a comentar mucho y cada comentario lo reviso dos o tres veces hasta que cualquiera pueda entenderlo, me parece que es mucho mejor tener un código fuente exageradamente comentado antes de tener que adivinar el orden o función de ese código hecho hace dos meses del cual ya no recuerdo nada.

Creo que esta entrada deja de por si mucho contenido bastante fácil de asimilar pero muy complejo de aplicar a la vida real, dice la gente que "del dicho al hecho, hay mucho trecho", sobre todo en software, le agregaría yo, al inicio los proyectos son muy distintos a la idea original, una vez nos acostumbramos a los procesos se vuelve mucho mas fácil calcular la forma final de un proyecto y el planteamiento se vuelve no solo un papel con ideas básicas, sino una maqueta completa sobre todo el proceso de desarrollo y con algo más de práctica puede convertirse en una guía para la gestión de proyectos, el limite de esta utilidad reside en el programador y en cuanto tiempo tenga de estar haciendo prácticas al respecto.

Para finalizar siempre dejo una frase, me parece una buena manera de fijar como recuerdo permanente una lectura, así que voy a recurrir a la constante del desarrollador, muy temida y conocida, descrita por Mosher, esta cita está reconocida como la ley de Mosher sobre la ingeniería de Software:

"No te preocupes si no funciona bien. 

Si todo estuviera correcto, serías despedido de tu trabajo."