Alguna vez les ha ocurrido que tienen un amigo, conocido o compañero de trabajo (o vamos, nosotros mismos!) que antes de comenzar sus actividades de programación/documentación (o incluso modelamiento) nos viene con una pregunta como:
”no tienes algun ejemplo o modelo para …? lo necesito para guiarme.”
Cada vez que escucho ese tipo de consultas o comentarios me pongo a pensar en los posibles entregables que se generarían a raíz de este modelo, ejemplo o plantilla.
Cuando se trata de documentos me he topado por lo menos con el mismo indice, lo cual no tiene nada de malo si el contenido viene con el trabajo tal como debe hacerse. Pero tambien existe esa alternativa que no nos gusta, ese documento que casi siempre tiene errores de redacción y peor aún, de revisión, ese documento que muchas veces termina mostrando información del proyecto anterior, con fechas y empresas que no tienen nada que ver con el nuevo documento!
Si revisamos un diseño y nos encontramos por ejemplo con títulos que dicen DDD por todos lados, mucho cuidado si les pides algo de detalle o peor aun, les preguntas, qué es el dominio?
Si la respuesta no los convence, posiblemente ese diseño tuvo origen en algun libro, proyecto o tiene demasiadas buenas intenciones y poco fundamento… es decir, fue tomado como base y de eso no pasó.
En programación el indice aumenta, ya que con el internet podemos preguntarle a muchas personas si tienen un ejemplo, modelo o guía. De esto peor si estamos en la época en la que no conocemos mucho y nos apegamos (literalmente) a copiar y pegar y si ya funciona, pues dejalo asi.
Es por eso que cuando revisamos el código encontramos algunos bloques comentados, variables o campos que no comprendemos y tenemos incluso comentarios en otro idioma :D
Acaso no les ha pasado que necesitan una función javascript y terminan modificando un ejemplo que está a medio terminar?
Estas características son las que me recuerdan a la escuela del copiar y pegar, escuela del CPDD o Copy Paste Driven Development, la cual debemos evitar a toda costa!
Con esto no quiero que piensen que estoy en contra de pedir ejemplos, modelos, usar guías de terceros o bases de proyectos pasados (vamos, que la mejora contínua existe y debemos aplicarla!) pero creo que siempre debemos tomar en cuenta algunas consideraciones:
– Si estamos comenzando en este mundo loco de la programación, un modelo se debe tomar tal como viene. Al menos la primera vez.
– Si hablamos de un documento en particular, no me refiero a que tomemos como base al documento completo! lo que nos debe interesar es la estructura del mismo, osea el indice 🙂
– Si fuera un modelo de programación, de buenas a primeras no podemos cambiar -por ejemplo- una estructura de capas simplemente porque nos gustaría poner una capa “solo para probar” o “para mejorar” además “malogrando se aprende”
– Para implementar mejoras al modelo que estemos usando (documental o de programación), uno debe ponerse en los zapatos del que inició la idea y continuar con alguna modificación siguiendo por lo menos una línea acorde a la original.
– Si nos avocamos a ser partícipes de esta escuela, hay que tener mucho cuidado con el nivel de mantenibilidad que brinden nuestros entregables, tengamos en cuenta que en algún momento nos preguntarán “¿por qué hiciste eso?”
– Mucho cuidado con lo que encontremos en internet, ya que gracias a esta gran red, es muy facil ser gurú y a veces uno se topa con soluciones muy interesantes pero tambien están otras soluciones de personas que como nosotros, también están aprendiendo y con ese riesgo latente podríamos estar copiando una mala práctica, una buena intención o un… “me salió luego de varios intentos asi que mejor no lo toco”
Los invito a que cada vez que se necesite o se tenga una solución a la mano, consideremos ser más estrictos en revisar las fuentes, además claro de comprenderlas, pues de esa manera nos estaremos alejando de la escuela del copiar y pegar, de esa escuela que con el tiempo nos genera problemas interminables, que ademas de hacernos esclavos de malas prácticas, nos podría convertir en esclavos de nuestros errores :(
Asi que ya saben, no seamos esclavos del Copy Paste Driven Development!
Un abrazo
@Jersson
PD: Copiar y pegar no es malo, lo malo es no conocer lo que copiamos y pegamos 🙂