¿Cuál sería la relación Modularidad/Complejidad que se estaría dispuesto a tolerar?

[[egostar]]

Empezado por AzidRain

Muy entendible no?

Asi es, ya lo veo claro, de hecho yo lo hago asi, genero funciones y procedimientos encapsulando codigo de la forma como lo planteas tu, pero esto mas por sentido practico que por conocimiento.

Salud OS.

[[Lepe]]

Yo siempre uso el inglés (aunque mi lengua materna sea el castellano) lo encuentro mucho más compacto. Nunca recuerdo si he usado el infinitivo o un tiempo verbal (Busca / Buscarrr) en el nombre de un procedimiento. Lo mismo con el singular y plurar, o con los artículos y preposiciones, que son muy incómodos (De, Los, El, etc).

No mezclo jamás inglés con español en el nombre de una función solo con conceptos del propio Software, por ejemplo: IdToAlbaran o IdToFactura.

Por este lado del charco, Grilla es la hembra del Grillo [...] ¿las maquillas y las peinas ?. Yo, personalmente , prefiero algo así como "SetGridHeader"; en español sería "EstablecerCabecerasDelGrid". "Preparar" es abstracto, nunca identifico lo que hace y acabo mirando la función.

Por otro lado, uso propiedades (property) siempre que puedo [...] Pero creo que me estoy saliendo del hilo jejeje.

En cuanto a lo ocurrido con la función "CalculaDuracion" es muy normal. Yo usaba mi función "InsertBreakLine" para romper una cadena larga al llegar a XX caracteres, Ahora recién veo WrapText de la unidad SysUtils en BDS2006 que me hace sonrojar (muy posiblemente también esté en delphi 6... no sé).

Saludos

[PabloTech]

Una pregunta:

¿Todo este debate es por los iniciados? o ¿me perdí de algo?

Empezado por Delphius

...es muy común en los iniciados en declarar funciones que ya estan implementadas.

Es correcto que cuando estemos frente a un problema complejo o enredado lo particionemos en otros más pequeños. Incomprensible sería no hacerlo. Y a todos nos pasa que hacemos algo que ya fue hecho o es nativo del lenguaje. Es parte del aprendizaje. Y cuanto más nos suceda, más conocimiento tendremos y más experiencia.


Decir:

Empezado por Delphius

me abruma un poco el hecho de los círculos viciosos que puede formarse por los encadenamiento de las funciones.

es un sentimiento normal. La duda está; pero en la medida que se pueda, y con el tiempo, uno aprende a evitar esos círculos viciosos (ó prefiero decir fallas).

Empezado por Delphius

...modularización y reuso... Si yo he entendido bien el concepto para lograr una gran reusabilidad es necesario contar con un buen grado de modularización. Y a la inversa: una buena modularización permite un mejor uso.

Yo creo que la modularización siempre ocurre antes que el uso o el reuso. Si separo un módulo es para usarlo posteriormente. Al menos una vez. Si lo uso más de una vez, significa que los estoy reusando. Varias cosas se logran con la modularización: uso, reuso, claridad al momento del desarrollo y claridad al momento del mantenimiento, disminución en el tamaño de código, entre otras.

Empezado por Delphius

Se pregunta: ¿Hasta que punto conviene llegar?

Conviene llegar hasta el punto en que el problema sea legible. Con pocas líneas. Si el problema se torna engorroso hay que particionarlo en módulos que a su vez sean legibles.


El debate si tiene sentido... Gracias Delphius y saludos a todos.

[mamcx]

Eso me recuerda:

The Zen of Python, by Tim Peters


Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!

Relacionado con el tema:

• Lo simple es mejor a lo complejo
• Deberia haber una forma obvia - y solo una - de resolver el problema
• Si la implementacion es dificil de explicar, es una mala idea...

La modularizacion es algo muy complicado, porque hay que entender que cada funcion, clase o unidad *aumenta* el vocabulario de un programa, y todo va sumando:

- El lenguaje +
- El framework basico +
- Componentes de terceros +
- Funciones externas del SO +
- Nuestro propio framework +
- El codigo especifico

Se vuelve muy enruedado. Adicionalmente, en los lenguajes imperativos y compilados no hay mucha flexibilidad y ha veces hay mas codigo del que es realmente necesario. No ayuda el que existan constantemente nuevos paradigmas en pugna que luchan por acaparar nuestro tiempo y atencion (como los zillones de frameworks de acceso a datos).

Actualmente, trato de :

- Si esta en el lenguaje o el framework basico, OK. A veces intento de escribir lineas mas largas - usando solo el lenguaje - que crear nuevas funciones, pero como alguien mas arriba, tambien caigo en tentaciones, como armar mi propio IIF
- Limitar al minimo el # de componentes de terceros, lo que obliga a buscar y buscar el mejor
- Si un componente de terceros no me soluciona ampliamente una necesidad - y es open source - mejor muevo el codigo necesario a mi propio codigo
- Si es un desarrollo de prueba, hago lo que quiera. Si es algo serio, lo pienso mucho
- Hago un esfuerzo por reducir al maximo el numero de clases y funciones, en vez de aumentarlas. Para ello, es muy util las pruebas de unidad. Otro concepto es ver que tareas hay repetitivas, pero mucho, para reducirlas
- De cuando en cuando suplico que le metan cosas mas potentes al lenguaje de Delphi

[[Al González]]

¡Hola a todos!

Empezado por Lepe

...algo así como "SetGridHeader"; en español sería "EstablecerCabecerasDelGrid"...

Rejilla.

Un abrazo sin grilla.

Al González.

[Neftali [Germán.Estévez]]

Empezado por Delphius

De acuerdo a tu experiencia, ¿Cuál sería la relación Modularidad/Complejidad que se estaría dispuesto a tolerar? ¿Qué criterios usas para determinar que tu trabajo está altamente integrado?

El problema para mí, es que no se cómo expresar eso en palabras.
Creo que más o menos todos tenemos en la cabeza las mismas ideas sobre Modularización, pero ¿cómo cuantificarlo?

[[Caral]]

Hola
Despues de toda esta explicacion de los maestros, me gustaria dar una opinion autodidacta.
No todo esta inventado.
No creo que exista la funcion perfecta o ideal para todos los programas (Standard).
De acerdo a esto:

¿Cuál sería la relación Modularidad/Complejidad

Para mi dependeria de la experiencia y del proyecto en si, no creo que se pueda generalizar.
Estoy de acuerdo con seoane en partir el problema para entenderlo mejor, pero mi poca experiencia dice que si no conoces la base no puedes partir nada, entonces partiriamos del conocimiento.
Para mi sencillamente se reduciria a lo dicho, Experiencia y deficinicion del proyecto.
Saludos

[xander]

A como yo veo el asunto, esta muy bien ser organizado y partir los problemas en pedazos que puedan ser reutilizables.

Un problema es el que comenta Mamcx, todo crece en cuanto lo partes... yo veo librerias como la de "interfazGH" de Al Gonzalez y me parece de lo mejor... pequeñas funciones bien separadas en contexto y todo...

Donde yo veo el problema en tener tantas cosas tan chiquitas es que luego no te acuerdas que es lo que tienes y que es lo que no... y si te acuerdas que ya lo tienes, ahora ¿donde quedó al final?... es como tener una caja de herramientas como el dice pero tener cientos de ellas en la caja... cuando tienes muchas encontrar una en específico es bien dificil, y luego a lo mejor resulta que si tenías hecha la funcion pero le pusiste un nombre que en el momento no recordaste y la pasaste por alto y la volviste a hacer... tal como le paso a Lepe con la funcion esa del BDS2006...

La cuestión tambien no es solo partir sino como es que se documenta o se le hace para encontrar lo que se ocupa rápidamente. tampoco es la idea de leerse los encabezados de todas las funciones de la unidad para encontrar la que busco, ahi pierdo el tiempo que pude haberme ahorrado.

[[Delphius]]

Empezado por PabloTech

Cuanto mayor sea la complejidad del problema, mayor será la modularidad aplicada. De tal forma, que el cociente entre ambas, tienda a uno (1).

Yo empleo medidas como esas... me gustan los números y veo de que manera me pueden ayudar.

Empezado por roman

Antes que nada, aclaro que yo en ningún momento me enojé, ¿por qué había de hacerlo? Solo dije que no entendía la pregunta y expresé mi opinión.

Mi intención es a futuro: que no te enojaras... a futuro.
Vale. Entendido... es que ya me ha pasado en otras ocasiones en que nadie me termina entendiendo y puede que en alguna de éstas le "salten los tapones" (espero que nunca suceda) por hacerme sentar cabeza.

Empezado por roman

Yo opiné que eran dos cosas distintas, nunca dije que no estuvieran relacionadas.

Entendido. Vale. Mejor leo bien las cosas..

Empezado por roman

¿Tu duda va en ese sentido?

Casi: a los efectos inmediatos de esto. Tu bien lo resumes: "sólo algo que debe revisarse y evitarse".

Empezado por egostar

yo estoy convencido de que la modularización va de la mano con la experiencia y de las nuevas funciones que te permiten reducir código hasta lograr la optimización.

Pues si. El arte de detectar la modularización y optimización se desarrolla con la experiencia.

Empezado por AzidRain

Código Delphi [-]
  Procedure TMiVentana.EjecutaTarea;
Begin
  AbreTablas;
  PreparaGrillas;
  If ShowModal=mrOK Then
    GuardaDatos;
  CierraTablas;
end;

Si. Se entiende... ahora ¿Cuál es la ganancia que obtuviste?O mejor ¿Cual es el costo asignado para llegar a eso? O ¿La relación entre entendimiento/costo? Ojo... este costo no es simplemente el valor subjetivo del esfuerzo... lleva implícito el valor monetario. Que de última es el precio de nuestro esfuerzo.

Empezado por AzidRain

Claro que tambien depende del estilo o "convenciones" que usemos en el código ya que si nombramos las funciones con nombres que no vienen al caso pues se pierde la utilidad de la atomización y se complica la cosa. En mis inicios en Pascal acostumbraba usar sintaxis en inglés para casi todo, posteriormente empece a revolver inglés con español y ahora solo uso español. A veces ponia nombres como "SeekFileNombres" o "BuscarFiles"...ahora me dan risa.

Lo de sintaxis en inglés, o en castellano, lo dejo a gusto de cada uno. Aunque yo me he acostumbrado a escribir en inglés (excepto al momento de ofrecerle resultados visuales al usuario: labels, edits, menues, etc).

Empezado por PabloTech

¿Todo este debate es por los iniciados? o ¿me perdí de algo?

No pienses que le hecho culpa a los iniciados. Sólo me he limitado a exponer un ejemplo que es típico, usual, común... y por supuesto: mio.

Empezado por PabloTech

Es parte del aprendizaje. Y cuanto más nos suceda, más conocimiento tendremos y más experiencia.

Es cierto... estoy de acuerdo.

Empezado por PabloTech

Conviene llegar hasta el punto en que el problema sea legible. Con pocas líneas. Si el problema se torna engorroso hay que particionarlo en módulos que a su vez sean legibles.

Ya nos vamos acercando a lo que quiero tratar de discutir... ¿A que defines legible?¿Le podrías asginar un valor?

Empezado por PabloTech

El debate si tiene sentido... Gracias Delphius

Gracias, uno más que considera que esto tiene sentido...

Empezado por mamx

Deberia haber una forma obvia - y solo una - de resolver el problema

¡Eso es lo lindo de la ingeniería del software!Es una espada de doble filo... y hay que aprender a usarla. Tiene cosas buenas.. y malas...

Empezado por mamx

- Si esta en el lenguaje o el framework basico, OK. A veces intento de escribir lineas mas largas - usando solo el lenguaje - que crear nuevas funciones, pero como alguien mas arriba, tambien caigo en tentaciones, como armar mi propio IIF
(...)

A tener en cuenta... por lo menos para mi.

[Neftali]
El problema para mí, es que no se cómo expresar eso en palabras.
Creo que más o menos todos tenemos en la cabeza las mismas ideas sobre Modularización, pero ¿cómo cuantificarlo?
[/Neftali]
¡Bingo!

Si bien todos lo han dicho... y yo también... no hay una única manera de responder. Por eso inicié este debate: yo quiero saber ¡hasta que punto le podrían asignar un valor!

Empezado por Caral

Para mi dependeria de la experiencia y del proyecto en si, no creo que se pueda generalizar.

Sabía que tu podrías. Sabía que tu tendrías algo que aportar.

Se puede generalizar... hasta cierto punto. Hay técnicas de inferencia para determinarlo... y como ya se ha dicho... depende de la experiencia.
Veamos, una frase que decimos mucho:
Si se sabe que un producto realizado de una manera es similar a otro... pues... lo resolvemos de la misma manera.

¿Se me entiende a lo que quiero llegar?
Creo que este thead es el má largo que escribí... pero sigamos.
No se de que manera lo harán ustedes, yo por mi parte voy a compartir lo que mi pequeño, novato, e infantil cerebro me ha permitido elaborar:

Por cada función/procedimiento/método:
1. Calculo su complejidad ciclométrica
2. Calculo su complejidad computacional
3. Obtengo su ancho de banda: cantidad de parámetros de entrada y salida
4. Obtengo su ancho de operatividad: cantidad de variables y constantes
5. Obtengo las siguientes métricas:
5.1. Utilización de Banda: relación de banda de entrada respecto al ancho total.
5.2. Utilización procedimental: relación de uso de memoria (1- (Variables/Ancho de operatividad)). Cuanto más alto sea el valor se penaliza. En lo posible, tratar de que sea bajo.
5.3. Razonabilidad operacional: determina la relación de uso de memoria respecto al ancho de banda.

Ro = Ancho de Banda/Ancho de operatividad

Este valor lo utilizo para diagnosticar la cantidad de variables que podrían estar en exceso, o que podrían ser eliminadas. Claro está, que al final es un valor subjetivo... eliminar alguna variable intermedia tal vez dificulte el entendimiento del código. Y en ocasiones no se puede eliminar la/s variable/s.

6. Calculo la productividad:
6.1. Productividad de Banda: que determina el rendimiento de los parámetros con respecto a la complejidad ciclométrica.
6.2. Productividad Operacional: que determina el rendimiento de la memoria interna respecto a la complejidad ciclométrica.
6.3. Productividad General: el promedio entre las dos anteriores.

También se puede calcular la productividad en base a las líneas de código.

Cone esto trato de averiguar que "tanto se usa" los parámetros y las variables durante la ejecución del algoritmo. Trato en lo posible de que tener pocos parámetros y menos uso de memoria con el menor código posible.

7. analizo el diagrama de flujo de la función y determino los casos de prueba. Desarrollo los casos de prueba y determino los posibles errores y defectos que tiene la unidad.
8. Con estos datos, y la cantidad de líneas de código obtengo otras métricas.

9. Cuando finalizo con todas las funciones, saco un valor estimativo (media ponderada) para determinar el valor asociado al módulo. A nivel de módulos calculo un valor de la modularidad prediciendo el valor de cohesión. Una estimación que aplico es determinar la utilización que se da a los parámetros y variables que se "pasan" entre módulos. Aquel tipo que predomine... se le asigno al modulo a estos valores lo pondero entre todos los módulos.
Cuanto más bajo sea... es preferible.

También calculo la razón entre el ancho y largo de la carta de estructura. En lo posible trato de que el valor esté en el medio.

Yo me impongo que mi límite de esfuerzo sea del 80%, de modo que el otro 20% se lo dedicaré al posterior mantenimiento.

Con todos estos valores... los promedio (media ponderada y con pesos obtenidos de otros resultados anteriores) y lo normalizo con respecto al tiempo invertido. Por ejemplo si para toda la actividad me tomo 30 días y el valor ponderado es de 12, tengo que: 80% de 30 = 24. Por tanto: 12/24 = 0,5 o 50%. Este fué mi esfuerzo... podría haber mejorado.

A todos estos valores los voy registrando y haciendo cálculos estadísticos de tendencia y reajusto los pesos de las operaciones... y el ciclo comienza de nuevo.
Calculo otras métricas pero no viene al caso.

Si quieren saber quien tiene la culpa de que la locura por estos números: Roger S. Pressman, Yourdon, Craig Larman, y otros loquitos que andan sueltos. Y claro... yo... por hacerles caso.

Se que puede ser un poco extremo... no se... a veces me asusto a mi mismo por la obseción de saber que tan bien hago mi trabajo... Creo que me hace falta unas buenas vacaciones... bien lejos de una máquina.

Saludos, disculpen por el semejante rollo que me he escrito. Escucho comentarios, incluídos los del tipo: "estas loco man... "

[[Lepe]]

[Lepero] Pa'mi que le dah muchah uuertah ar coco, en er tiempo de analizá to ezo, ya tendríah otro pograma echo[/Lepero]

[[egostar]]

Hola delphius, si que te aventaste un buen rollo y si, puedes estar tranquilo "si estas loco" .

No, ya en serio.

Despues de leer tu exposición, que cabe señalar es interesante, lo que entiendo es que con esas mediciones estas tratando de encontrar el valor de la productividad en base a la simplificación de código, es decir, encontrar la relación esfuerzo/productividad y llegar a la optimizacion de procesos de producción.

Pienso que estas haciendo lo que se llama ciclo de vida del software, todos en este foro lo hemos hecho de una u otra forma, en pequeña o en gran escala. Algunos trabajando en empresas fuertes, otros en pequeñas y otros como yo de forma independiente.

Todos hemos llevado a cabo los pasos de este famoso ciclo de alguna forma

1. Recoleccion de necesidades
2. Analisis
3. Diseño
4. Implementación
5. Pruebas
6. Validación
7. Mantenimiento
8. Mejoramiento

Hasta aquí todo bien, ese es el ideal de cualquier desarrollador que se precie de ser digamos serio.

Ahora, que pasa en la vida real, aqui solo puedo hablar de mi poca experiencia en el desarrollo de sistemas. No se si tú ya has desarrollado algún sistema vendible, no quiero entrar en el terreno de privativo, digamos solo vendible.

En este momento estoy desarrollando un sistema hotelero, llevo 8 meses o un poco mas y ahora ya tengo una versión digamos BETA, el proceso de desarrollo lo he seguido de acuerdo al ciclo de vida que te menciono.

Sesiones de trabajo con la empresa que me solicitó el producto para ver factibilidad y segmento de mercado al cual se desea introducir el mismo.
Definición de las caracteristicas y alcances del producto
Diseño y desarrollo del producto
Pruebas del producto en su fase BETA

Hasta aquí he llegado, ahora estamos en la etapa de implementación donde hemos negociado con un "usuario final" la instalación del producto (GRATIS) bajo el esquema de retroalimentación con el fin de depurar y optimizar el producto.

Si entiendo bien tu conceptualización, hasta aqui podría comenzar a medir la relación esfuerzo/productividad, y que es lo que me va a dar esa medición, pues yo creo que ponerle precio a mi producto, o no?

Salud OS.

[[Delphius]]

Egostar, tengo bien en claro lo del ciclo de vida, USDP, Espiral, Prototipado, etc...
A mi me gusta muchísimo la ingeniería de software. A pesar de que en el examen de esa materia fue bajo (7 por si quieren saber) a comparación con el resto... pero no me quejo.... me puse nervioso.

Trato en todo lo posible de hacer un buen software. Actualmente estoy trabajando sobre mi tesis. Y esto para mi es absoulta seriedad en lo que hago por varios motivos:
1. Tengo un sistema complejo.
2. Según me han notificado las principales autoridades de la facultad de Ingeniería e Informática de la universidad, hasta el momento es el único proyecto en el norte de mi pais que está tratando del tema(¡vaya presión!)
3. Tengo la intensión de venderlo (sin código fuente). Si... a más de uno tal vez no le guste la idea... pero de algo hay que vivir.
4. Es algo que vengo teniendo ganas de aplicar. Me he inspirado en un proyecto que vi en Discovery (creería que era mexicano) y fue llevado en Delphi.
5. Se trata de algo supuestamente "novedoso" en mi pais.

El máximo objetivo es aprender y compartir lo que yo entiendo sobre esto de la ingeniería del software. No se en que medida habrá gente que aplica estos conceptos pero para mi es muy importante.

Saludos,

[[Lepe]]

Ahhh, que es para tu tesis... Ahora comprendo el por qué de tanta teoría [...] Pues quien sabe, quizás algún día, Delphi integre una opción en el menú Project -> "Detectar esfuerzo" gracias a tí.

No sería tan raro, Borland ya adoptó el VirtualTreeView por ser gratutio con fuentes .

Saludos.

[mamcx]

Pues eso es lo que hace starteam y las demas herramientas de ciclo de vida...

Aunque una vez las probe,no me convencen (no me refiero a la herramienta,sino a la utilidad real de medir esas cosas....)

[[cHackAll]]

Desde mi punto de vista la relacion tiene que estar directamente proporcional al asunto de costo/beneficio, si queremos hacer algo por lo que nos pagaran bien, tenemos tiempo, nos gusta o es muy importante entonces (yo), analizo 100 veces mas uno la mejor forma de realizar lo necesitado, pero como ya expuse en otros sitios, la forma mas optima a la que llegarás sera solo con assembler, luego de haber comprobado que el código realizado es mejor a los tres anteriores realizados por tamaño y velocidad.

En lo de la rueda, mientras sea yo quien cree la rueda tendre el control que quiera sobre los sistemas que utilicen mi producto... talvez en este momento estas usando algo con un backdoor, o talvez lo hizo un "tapado" y esta hecho al huevo pero funciona! La decision debe ser (como todas) la mejor que se adecue al caso particular!

[[Delphius]]

Empezado por Lepe

Ahhh, que es para tu tesis... Ahora comprendo el por qué de tanta teoría [...] Pues quien sabe, quizás algún día, Delphi integre una opción en el menú Project -> "Detectar esfuerzo" gracias a tí.

No sería tan raro, Borland ya adoptó el VirtualTreeView por ser gratutio con fuentes .

Saludos.

Acabo de ver, una de las tantas presentaciones sobre Delphi 2007 que hay (si recién ahora las estoy viendo... aprovechando banda ancha) cuando me topé con una que trataba sobre calidad. Ustedes saben como me gusta el tema de UML, métricas, y esos bichos raros

No pude evitar recordar este comentario mientras veía el video... y bueno...
¿Porqué c... llego siempre tarde para las ideas?

Hubiera sido lindo que toda esta charla hubiera sido hecha en el 2006 o el 2005... Podría tener una escusa para decirle a Borland/CodeGear: "Hey... la idea fue de Clubdelphi"

Vine al hilo para sacarme la duda de la fecha en que fue tratado todo esto... pero como podran ver... fue posterior al lanzamiento...

Como que se me subió el ego (Dije ego... no Egostar. Hay que aclarar hoy en dia)... sería maravilloso leer en su acerca de: "Idea Original: Delphius"

Bueno resucité el hilo solo para esto.
Son las 4:15 am en Argentina, quiere agarrarme el sueño. A ver... si esta vez me le adelanto, aunque sea en sueños

Saludos,