Cómo (no) perder el tiempo planificando un proyecto
Por favor, si crees que planificar un proyecto es una pérdida de tiempo y no merece la pena, concédeme la lectura de los dos primeros párrafos antes de sacar conclusiones. Muchas gracias.
Tras topar con los debates de "Comentar o no comentar el código, esa es la cuestión" y "spaghetti code" creo que ha llegado la hora de arrojar cierta luz sobre los métodos más útiles para planificar un proyecto/código/página web o cualquier nombre que queráis usar.
En este blog se ha hablado de lo divertido que puede resultar programar (y yo soy el primero al que le gusta "ensuciarse las manos" tecleando conforme me surgen las ideas) pero lo que voy a comentar aquí no es una censura de este comportamiento, sino una manera de enfocarlo acertadamente para que además de disfrutar de la programación, obtengamos un beneficio (que no tiene por qué ser económico).
Para conseguir esto sólo tienes que asumir las siguientes verdades y empezar a practicar.
Planificar no es documentar, es dibujar código
El primer error que puede darse, es la creencia de que la planificación es lo mismo que la documentación que se publicará posteriormente, y que hay que explicar detallada y limpiamente cada detalle sin alterar nuestras ideas.
En realidad la belleza de planificar un programa reside en justamente lo opuesto: hacer diagramas de flujo o storyboards nos da el poder de cambiar cualquier idea de la forma más sencilla posible sin tener que estar pendientes de minucias como nombres de ficheros, codificación, etc... Es este grado de libertad (que a priori se cree inexistente) el que hace que planificar sea tan divertido.
Un programa puede escribirse en diagramas
Con este segundo punto quiero clarificar dos conceptos: la profundidad que puede llegar a tener una planificación y la aplicación práctica directa de éste.
En lo que se refiere a la profundidad, hablo de que muchas decisiones como la nomenclatura pueden (y deben) ser tomadas en esta etapa para que la siguiente sea lo menos engorrosa posible. Si nos ceñimos a una norma tan sencilla como "Si se tarda menos de 5 minutos para completar una tarea, hazlo ahora" lograremos saltar sobre todo este engorro para que programar acabe siendo aún más divertido.
Hablando de la segunda parte, se pueden destacar los llamados "generadores de código", los cuales no nos dan en absoluto el programa final pero hacen cosas como crear la estructura de ficheros y las cabeceras de las funciones (comentarios incluidos) por nosotros mismos. Hay herramientas tremendamente potentes para realizar esta tarea como Visual Paradigm y otros también muy efectivos (además de libres y gratuitos) como Dia. Probad a usarlos una vez y no volveréis a escribir una cabecera innecesariamente.
Los algoritmos son los diamantes de la computación
Este último punto tan sólo hace referencia a algo que todo buen programador debe saber: todo programa está basado en un algoritmo que lo resume y generaliza, lo que es lo mismo que decir que si nos preocupamos más de la estructura básica de éste y no de cuestiones de un lenguaje concreto, tendremos algo usable en infinitos casos y fácil de evaluar y mejorar en un futuro cercano o lejano.