pautas para programar

¡que tiempos aquellos!
pues, en esas epocas, usabamos foxpro para hacer aplicaciones pequeñas
(standalone o redes pequeñas de 4 o 5 maquinas). Bueno, eso es lo que
creiamos al principio. Llegaba la solicitud de un departamento, con un
requerimiento X lo implementabamos, y les gustaba tanto que lo
comentaban en otras areas.. entonces estas tambien nos la pedian.
Nosotros muy seguros y confiados, les instalabamos la misma aplicacion...
todo bien, todo perfecto hasta que alguien llamaba y pedia un cambio
"pequeño" , con el tiempo estos cambios "pequeños" se volvian monstruosos...
y la pesadilla continuaba...

luego ya me cambie a desarrollar aplicaciones cliente servidor, con un jefe
de proyectos que tenia las cosas muy claras en cuanto a estandarizacion y
calidad del codigo... muuuuuuuuuuucho mas ordenado.

Cecilia

"Kravek" <rubengARROBAkailea4.net> wrote in message
news:

¿Por qué no empiezas comentando las que usabais en tu empresa? (me refiero

a

todos menos ese personaje de foxpro...;))

y que hay con respecto a la especificacion de requerimientos
Dios bendiga al que invento las herramientas de modelaje...
pienso que con ellas todos los desarrolladores de una misma empresa
se ven forzados a usar un mismo lenguaje...
aunque me he topado con situaciones en las cuales se arman todos los modelos
de especificacion de acuerdo a las necesitades de los usuarios
pero luego el codigo fuente no tiene nada que ver con este... ¡que dolor de
cabeza!
veo un par de razones para que esto ocurra:
1. que los procesos de negocio de los clientes o usuarios cambian
constantemente
2. que las personas que participan en la cadena de suministro de una
aplicacion no hablan el mismo lenguaje entre ellas, es decir
el usuario habla en chino, el analista habla en griego, el diseñador habla
en urdu y el programador habla en c++

lo primero es inevitable... es mas nosotros existimos para "alinear" los
sistemas de informacion a estos cambios
lo segundo... esta en nuestras manos.

cecilia


"Enrique Lima" wrote in message
news:

Cecilia,

Yo creo que en nuestro tiempo ahora vale mucho la pena apegarse a
Metodologias que permiten y que sobretodo se enfocan en planificacion tal
como MSF. Pero no debe quedarse en eso, creo que debe complementarse con
Metodologias que ayudan al desarrollador a tener un concepto de

Reusabilidad

en sus aplicaciones, modulos, etc. Hay algunos ejemplos en el mercado
actualmente, tecnicas como Agile con Scrum, eXtreme con XP y la
incorporacion de sistemas bajo TDD(Test Driven Development) son clave.

en espera de comentarios,

Enrique Lima

"Cecilia Loureiro" wrote in message
news:#
> Durante años trabaje de desarrolladora de software. En mi trabajo

siempre

> buscabamos estandarizar nuestro trabajo asi todos podriamos entender el
> trabajo de los demas. Nunca me voy a olvidar una vez que abro una
> aplicacion en FoxPro si ya se hace siiiiiiiiiiiiiiiiglos y veo

un

> gremlin mutante ahi... lo primero que puedo recordar son los nombres de
las
> variables... a, aa, aaa, a1, a213, mesa, silla, techo, etc, etc ,etc.

los

> nombres de las tablas comp, compu, compu1, compu23, los nombres de los
> campos... los indices... Dios mio.!!
> el payaso que habia escrito ese programa le importaba un pepino que su
> programa sea entendible... la pesadilla que tuve que pasar para

modificar

el
> programa.
> Felizmente los ambientes de desarrollo actuales nos ayudan mucho a crear
> programas entendibles aunque no podemos confiar 100%...
>
> ¿cuales creen que sean las reglas basicas para crear programas que:
> 1. sean eficientes
> 2. sean entendibles
> 3. puedan ser mantenidos sin mucho problemas.?
>
>
> Cecilia
>
>

On Tue, 8 Jun 2004 17:04:14 +0100, "Cecilia Loureiro"
wrote:

¿cuales creen que sean las reglas basicas para crear programas que:
1. sean eficientes
2. sean entendibles
3. puedan ser mantenidos sin mucho problemas.?

La mia es eliminar en todo lo posible la codificación y poder ejecutar
directamente las especificaciones.

La mejor manera de no tener problemas con el código es no tener código
:-)

Saludos
Alfredo

Yo creo que tambien hay que tomar en cuenta que hay
desarrolladores/programadores que no han cambiado su vision en casi 2
decadas.

Mucho tiene que ver el cambio de mentalidad, por ejemplo, desarrollo de
aplicaciones modulares (OOP). Y sobre esto tambien el incluir el concepto
de cambio diario (TDD).


"Cecilia Loureiro" wrote in message
news:

y que hay con respecto a la especificacion de requerimientos
Dios bendiga al que invento las herramientas de modelaje...
pienso que con ellas todos los desarrolladores de una misma empresa
se ven forzados a usar un mismo lenguaje...
aunque me he topado con situaciones en las cuales se arman todos los

modelos

de especificacion de acuerdo a las necesitades de los usuarios
pero luego el codigo fuente no tiene nada que ver con este... ¡que dolor

de

cabeza!
veo un par de razones para que esto ocurra:
1. que los procesos de negocio de los clientes o usuarios cambian
constantemente
2. que las personas que participan en la cadena de suministro de una
aplicacion no hablan el mismo lenguaje entre ellas, es decir
el usuario habla en chino, el analista habla en griego, el diseñador habla
en urdu y el programador habla en c++

lo primero es inevitable... es mas nosotros existimos para "alinear" los
sistemas de informacion a estos cambios
lo segundo... esta en nuestras manos.

cecilia


"Enrique Lima" wrote in message
news:
> Cecilia,
>
> Yo creo que en nuestro tiempo ahora vale mucho la pena apegarse a
> Metodologias que permiten y que sobretodo se enfocan en planificacion

tal

> como MSF. Pero no debe quedarse en eso, creo que debe complementarse

con

> Metodologias que ayudan al desarrollador a tener un concepto de
Reusabilidad
> en sus aplicaciones, modulos, etc. Hay algunos ejemplos en el mercado
> actualmente, tecnicas como Agile con Scrum, eXtreme con XP y la
> incorporacion de sistemas bajo TDD(Test Driven Development) son clave.
>
> en espera de comentarios,
>
> Enrique Lima
>
> "Cecilia Loureiro" wrote in message
> news:#
> > Durante años trabaje de desarrolladora de software. En mi trabajo
siempre
> > buscabamos estandarizar nuestro trabajo asi todos podriamos entender

el

> > trabajo de los demas. Nunca me voy a olvidar una vez que abro una
> > aplicacion en FoxPro si ya se hace siiiiiiiiiiiiiiiiglos y

veo

un
> > gremlin mutante ahi... lo primero que puedo recordar son los nombres

de

> las
> > variables... a, aa, aaa, a1, a213, mesa, silla, techo, etc, etc ,etc.
los
> > nombres de las tablas comp, compu, compu1, compu23, los nombres de los
> > campos... los indices... Dios mio.!!
> > el payaso que habia escrito ese programa le importaba un pepino que su
> > programa sea entendible... la pesadilla que tuve que pasar para
modificar
> el
> > programa.
> > Felizmente los ambientes de desarrollo actuales nos ayudan mucho a

crear

> > programas entendibles aunque no podemos confiar 100%...
> >
> > ¿cuales creen que sean las reglas basicas para crear programas que:
> > 1. sean eficientes
> > 2. sean entendibles
> > 3. puedan ser mantenidos sin mucho problemas.?
> >
> >
> > Cecilia
> >
> >
>
>

On Wed, 9 Jun 2004 09:34:12 +0100, "Cecilia Loureiro"
wrote:

y que hay con respecto a la especificacion de requerimientos
Dios bendiga al que invento las herramientas de modelaje...
pienso que con ellas todos los desarrolladores de una misma empresa
se ven forzados a usar un mismo lenguaje...

El problema es que normalmente es un lenguaje con el que no se puede
decir casi nada.

aunque me he topado con situaciones en las cuales se arman todos los modelos
de especificacion de acuerdo a las necesitades de los usuarios
pero luego el codigo fuente no tiene nada que ver con este... ¡que dolor de
cabeza!
veo un par de razones para que esto ocurra:
1. que los procesos de negocio de los clientes o usuarios cambian
constantemente

Eso pasa siempre. Yo creo que se debe a que los clientes o usuarios
raramente saben bien lo que quieren y cuando les enseñas lo que han
pedido se dan cuenta de que no es lo que ellos querían.

2. que las personas que participan en la cadena de suministro de una
aplicacion no hablan el mismo lenguaje entre ellas, es decir
el usuario habla en chino, el analista habla en griego, el diseñador habla
en urdu y el programador habla en c++

Otra cosa muy normal es la falta de precisión de las especificaciones.
El analista pinta 4 rayas y el programador tiene que adivinar lo que
quiso decir.

Unas especificaciones verdaderamente precisas deberían poder ser
ejecutadas por un ordenador, y así nos ahorraríamos el tener que
codificar.

lo primero es inevitable... es mas nosotros existimos para "alinear" los
sistemas de informacion a estos cambios
lo segundo... esta en nuestras manos.

Lo malo es que las herramientas que tenemos son muy pobres.


Saludos
Alfredo