Basándome en la premisa de "pensar que cosas hacer en vez de como hacerlas", es que debemos tener cuidado al momento de diseñar o presentar ciertas recomendaciones.
Dado que, de acuerdo a lo que debe hacerse, se plantea un esquema de construcción, y luego de priorizar dichas actividades uno debería tener ya en cuenta que las funcionalidades van por delante del código/librerías a construir/implementar. Y que, dicho sea de paso, las funcionalidades determinan los contratos "mínimo/suficientes" que deben considerarse para determinar el cumplimiento de los requerimientos.
Con estas funcionalidades transformadas en contratos es que se tienen que trabajar los conocidos casos de prueba (me parece es que David estaba hablando de pruebas en su ultimo post?) desde el inicio del proyecto, ya que a mi parecer, estos casos se van enriqueciendo con el pasar de los días. De ser asi, por que esperar hasta terminar el desarrollo para tener listo todo el set de pruebas?
Que si es posible lo contrario? creanme que he experimentado situaciones en las que no consideraban la construcción de casos de pruebas desde el inicio.
En si, las pruebas, independientemente de la manera en que sean ejecutadas (el cual es un tema largo de conversación) deben en primer lugar, enfocarse en los resultados y cumplimiento de estos contratos "mínimo/suficientes". Dado a que, en resumidas cuentas, nuestro trabajo es reconocido por si el producto funciona. Si no es asi, favor corrijanme si es que al usuario no todo le parece transparente.
He notado que en la mayoría de situaciones es menos probable encontrar la explotación y seguimiento de resultados de casos de prueba, puesto que, principalmente es el código que le preocupa a cada desarrollador.
Pero que sucede con el caso del resto de componentes? es decir:
- Librerías de la compañía (Librerias de uso comun, como acceso a datos o correo)
- Librerías especializadas-externas (Proveedoras de controles/componentes/etc.)
- Librerias Open Source
Lo que debe tomarse ya como cierto es que no tenemos que caer en el juego de "lo necesito, lo construyo". Dado a que, tiempo es dinero y ese dinero es el que estamos ahorrando para disminuir costos, a corto o largo plazo.
Considero que a pesar de ello debe tenerse bastante cuidado con las librerias con las que se decida trabajar. La importancia con la que se maneje tal situación determinará el cumplimiento del objetivo de "no reinventar la rueda"
Y porque digo esto?
***Caso: Librerias de la compañía
Creo que en cierto punto, casi todos hemos pasado por la situación de haber construido un componente que "a nuestro entender" puede convertirse en algo de uso común.
El problema viene cuando dicho componente/librería/control/piece of code, no está del todo documentado o peor aun, luego de algunas pruebas llegamos al punto de "ese caso no nos ha pasado, pero no debería caerse".
Esto en vez de aportar al proyecto puede convertirse en un cuello de botella.
Pues que solución? Entre tantas, creo con un poco de Gestión de la Configuración y algo de compromiso de parte del Gestor o responsable para que al liberar versiones de componentes de construcción, estos se mantengan estables, documentados o en todo caso, autosostenibles que permitan el correcto uso de las funcionalidades que brindan.
Creo que tambien ayuda un poco menos de ego, no les parece?
***Caso: Librerías especializadas-externas
Este tema es mas que conversable, pues estamos hablando de pagar por librerías de uso comprobado.
El problema está en que muchas veces nos dejamos llevar por las propagandas o animaciones que podemos encontrar en la red. Creanme, que a veces es asi.
El caso es similar si es que hablamos de complejidad de uso, documentación, ejemplos y lo mas importante, costos de soporte. En algunas situaciones, este deja de ser gratuito (muchos de mis amigos me dicen que alli radica el negocio, o no?)
Pues que solución? Evaluacion directa de las alternativas de compra, asi como tambien la revisión de la actividad pública de los foros de usos de la librería y de la rapidez de respuesta y aportes brindados por el soporte de la empresa.
Como punto adicional, algo que debe considerarse en la evaluación, es la periodicidad de fixes/patchs liberados, la compatibilidad hacia atras, y ademas claro, de la caducidad del contrato.
En mi caso he pasado por estos procesos de evaluación. Sinceramente es algo tedioso, ya que no estamos hablando de un juguete para navidad, esto es algo serio!
***Caso: Librerías Open Source
Este aspecto es de por si delicado, ya que ademas de la estabilidad, documentación o ejemplos de uso, debemos considerar aspectos como el nivel de aporte brindado por la comunidad (se de un caso en que el proyecto fue cerrado porque el unico que desarrollaba era el dueño de la idea, asi que un día se cansó y dejó de hacerlo).
En si, los riesgos o problemas identificables en este aspecto son similares a los encontrados en el caso de las librerías especializadas, pero bajo la premisa que la empresa de terceros es ahora una comunidad abierta y algunas veces, volatil.
Pues que solución? En las evaluaciones debe considerarse el aporte de la comunidad en lo que desarrollos se trata, ademas de la periodicidad de releases y compatibilidad con nuestras plataformas de trabajo.
Si hemos llegado aqui, debemos coincidir en un punto medio, ya que tampoco conviene estar actualizando constantemente las librerias.
Lo que no debe olvidarse de que las ideas Open Source no dejarán de ser buenas ideas, pero que muchas veces caemos en trabajos de entusiastas (esto claro, sin animo de ofender a nadie) que -muchas veces- cubren el trabajo bajo la idea de "primero que funcione luego ya veo".
Asi que, debemos atenernos al riesgo de encontrar disparidad de estándares, manejo de memoria, falta de ejemplos, etc.
En resumen. De por si son demasiados los aspectos que debemos considerar en nuestras preocupaciones sobre que parte de código probar o no, pero muchas veces olvidamos darle cierta importancia a algunos empaquetados que "se supone" deberían funcionar correctamente.
Creanme, somos humanos, existe aún código por probar.
Nota: Les recomiendo el libro "
Code Leader", al escribir este post recordé claramente algunas recomendaciones que pude resumir brevemente, creo que el capítulo se llamaba "Buy or not buy code".
Saludos[at]Cama
