Detector de diseño erróneo

June 15th, 2005

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.

    • posted by tete at 10:53 am & filed under Developing |


    Comments are closed.