Sabes UML?, Sabes Java?.... esas son las preguntas que te hacen normalmente para ingresar a una compañía. Y revisando pensums, experiencias, cursos, seminarios, etc., etc., etc. se diría: “Esas aplicaciones deben salir perfectas”. Pero la cruda verdad es que no es así.
Al parecer todos esos papeles (porque los cursos parecen que no son mas que eso) no sirven para nada si no existe una CULTURA para el desarrollo de software y la calidad que debemos lograr. Se supone que con el nivel de nuestros analistas debemos tener una gran reutilización de componentes y no estar haciendo las mismas cosas cientos de veces para cada aplicación. ¿Pero donde están esos componentes? ¿Donde esta esa reutilización? ¿Porque se esta volviendo a hacer lo que miles de desarrolladores hacen a nivel mundial? (Frameworks).
Creo que el problema se reduce a una sola palabra, CULTURA (dejando a un lado la excusa del cronograma), el problema de las barreras culturales en software es evidente, no existe cultura para investigar y atreverse a mejorar (porque no es aprender, es mejorar) el desarrollo, no existe cultura para documentar lo que hemos hecho, no existe cultura para reutilizar.
Hace varios años trabajaba en una empresa donde un analista se jactaba de ser el mejor por haber hecho un pool de conexiones, pero realmente era el mejor? Mi respuesta es la siguiente, tal vez era el mejor escribiendo líneas de código, pero el mejor es aquel que tiene la capacidad de visionar cuando utilizar lo que ya se ha hecho antes, no perder tiempo (y aquí tumbo la excusa del cronograma) reinventando la rueda, y teniendo la capacidad de crear una aplicación que pueda servir como base para otras aplicaciones.
Aquí está el beneficio de una arquitectura basada en componentes, una arquitectura orientada a la reutilización, no solo basta con saber Java o UML, es tener una CULTURA que nos permita saber cuando reutilizar, cuando hacer componentes reutilizables, cuando usar un framework. ¿Que crees tú?
posted by Unknown @ 2:58 p. m.
0 comments
