[[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... "