Muy pocos desarrollos parten de cero; lo normal es usar componentes de partida, bibliotecas, includes ajenos, linkar, etc. Si tienes la suerte de no contar con más de un candidato para hacer una determinada tarea ahí acaban tus problemas. En muchos casos el diseño del resto del soft se verá condicionado para girar alrededor de este componente único.
Pero, ¿qué pasa cuando tienes varias opciones? Tienes que elegir. Te da más libertad y más opciones, aparentemente todo genial. Pero luego, vas al barro, estás desarrollando y …
Síntomas: (escoger unos cuantos de la siguiente lista)
Has decidido ampliar el interfaz de control de una de las bibliotecas que tienes en tu proyecto
Has descubierto varios errores en el diseño fundamental de los componentes de OTROS
Acometer una accción específica exige 3 ó 4 llamadas a tus APIS
Tu frase favorita es: vaya truño de documentación. Además los ejemplos de los componentes no te compilan, o van demasiado lentos.
Te has planteado -. seriamente .- embeber el código de tus componentes en el tuyo propio
Causas:
No se ha comprendido para qué vale el componente específico. Estás usando un martillo para abrir una lata de sardinas.
Puede sonar jodido pero no es la primera vez que nos ha pasado. Aquí algunas soluciones preventivas:
Leer el manual no es de lúsers
No entender el manual a la primera no es de lúsers
Además del manual, léete el código de los ejemplos (y de paso los tutoriales y howtos)
Si otros proyectos emplean el mismo componente, ¿cómo lo hacen? Quizá otros puedan ayudarte a elegir ya que eligieron primero.
This entry was posted on Wednesday, June 15th, 2005 at 10:53 am and is filed under Developing.
You can follow any responses to this entry through the RSS 2.0 feed.
Responses are currently closed, but you can trackback from your own site.
