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

[[seoane]]

Empezado por Neftali

Creo que la Modularidad a la larga añade complejidad (en el sentido de llamadas como las que comenta Seoane), pero aporta otras cosas.

Por curiosidad, ¿que llamadas comente?.

Por otro lado, ya que me meto, dejo mi opinion. Yo tenia un profesor que decia que si no puedes ver todas las lineas de una funcion sin usar el scroll es hora de partila en funciones mas pequeñas

Yo personalmente cuando estoy desarrollando un algoritmo complicado encuentro muy útil usar funciones para dividirlo en problemas mas sencillos y poder resolver cada uno por separado.

[[Caral]]

Hola
Yo ni opino.
Nada mas veo y aprendo.
Si no digo algo no me llega por correo.
Cuando los maestros se reunen hay que estar presente.
Saludos

[roman]

Estoy de acuerdo con seoane, el maestro de seoane y también con Al González; pero, como dije antes, no hay tampoco que caer en la pulverización del código y separar en una función cada simple paso de la función original.

// Saludos

[[Lepe]]

Empezado por Caral

Si no digo algo no me llega por correo.

Debajo del boton Responder, en el menú herramientas, tienes la opción "suscribirse a este hilo", pero claro, si lo usas.... no aumentas tu contador de mensajes

Saludos

[[Delphius]]

Empezado por Neftali

Bueno, yo en esta cuestión soy bastante "básico"; Si ya se ha "inventado la rueda" y la fuente del invento es fiable, no hay porqué reinventarla.
Considero el código de Borland como muy fiable; Puede ser que haya alguna función que no esté optimizada al máximo, pero seguro que el 98% del código puede ser tan fiable y eficiente que el que pueda hacer yo.

Creo que la Modularidad a la larga añade complejidad (en el sentido de llamadas como las que comenta Seoane), pero aporta otras cosas.
Es la discusión de siempre;

Neftali, no discuto el hecho de que hay que reinventar la rueda o no. Yo sólo estaba comentado que es muy común en los iniciados en declarar funciones que ya estan implementadas (y vamos... que no es por ignorancia... sólo es porque desconocían su implementación).
Un iniciado, por conseguir una buena modularidad empieza a repartir las funciones en módulos... y llega a cosas como:
A -> B -> C -> D -> E ->....

Es correcto lo que hace... pero uno llega a preguntarse: ¿Hasta que punto sería fiable? Hay métricas que determinan un valor en base al juicio del desarrollador, pero también existe un "grado de duda" al momento de estar diseñando.

No discuto de que sean fiables... de seguro que si. Creo en que lo que realizó Borland es un producto espectacular. Pero... me abruma un poco el hecho de los círculos viciosos que puede formarse por los encadenamiento de las funciones.

Totalmente de acuerdo que estos encadenamiento pueden añadir complejidad... pero también reconozco que tiene sus ventajas.

Empezado por Roman

Yo es que no entiendo esta pregunta. Me parece que se están mezclando dos cosas: modularización y reuso.

En el caso del año bisiesto el problema es que se crea una modularización innecesaria debido el reuso incorrecto de funciones.

Disculpa roman si no me entiendes la pregunta... debí formularla de otra forma. No te enojes pero no coincido contigo en lo de modularización y reuso.
Si bien son dos palabras diferentes... son dos palabras que vienen mucho de la mano. 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. No se puede separar ambos conceptos totalmente, hay una línea delgada que los mantiene unido. Y creo que encontrar esa línea delgada es lo más complicado de hallar. Si estoy equivocado, avisenme... porque llevaría años equivocado.

Como tu comentas... es cierto que se consigue una modularización innecesaria por hacer uso de las funciones "incorrectas". Pero... volvamos al caso del novato (por ejemplo... yo). Un novato... declara y declara funciones... que ya vienen incorporadas... No se da cuenta de que puede evitar este comportamiento (no por ser ignorante... las buscó pero no bien). Le funciona... Por lo tanto sigue con su trabajo. Obedeciendo su instinto de que desea hacer un buen trabajo separa bien los módulos... y sigue haciendo su trabajo... al estilo del problema del año bisiesto. ¿Lo está haciendo mal? Si y No. Podría hacerlo mejor... si. No es una persona cerrada y empieza a armar un diseño rápido de todos los módulos... saca una cuantas hojas sábanas y arma una linda carta de estructura (por poner un ejemplo) y nota un gran despliegue de módulos.
Se pregunta: ¿Hasta que punto conviene llegar?
Y vamos.. que esto no sólo se consigue con las funciones "innecesarias", aún con las correctas se puede armar un buen lío.

Empezado por egostar

Yo también no estoy del todo convencido con este debate y por una simple razón.

Todo depende del tiempo y de las circunstancias, (siempre me ha gustado esta frase ), bueno, quiero decir que depende mucho de quien se este hablando porque no es lo mismo mi estilo de programar (por cierto considero que no lo hago nada bien, pero intento hacerlo) y el estilo de roman o de seoane, neftali, etc que son muy diestros para hacerlo.

Para esto también hay niveles de conceptualización muy personal.

Sin embargo, si puedo decir que lo mejor es lo que dijo Neftali, no tratar de inventar la rueda pero agrego que si podemos intentar mejorarla.

Es cierto que esto es un tema subjetivo. No hay un único dictamen y es por ello que armo este debate. Quisiera ver sus opiniones en el asunto.
Pero también existen herramientas que la ingeniería del software han venido aportando. Hay métricas que permiten ofrecer una medida de lo bien que se tiene modularizado... se sabe que no es un valor rígido y que hay que obedecer pero es buen estimativo.

A ver... la pregunta que debí haber formulado sería algo así:
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?

Al, yo también soy partidario a particionar el código. Yo dentro de mi esquema de trabajo impongo esa actividad... pero tal como dicen otros... tampoco hay que decaer en el extremo (que ya me pasado) de partir una función en muchos pedazos que poco o nada hacían por si mismo.

Empezado por seoane

Yo tenia un profesor que decia que si no puedes ver todas las lineas de una funcion sin usar el scroll es hora de partila en funciones mas pequeñas

Es buen criterio... yo como amante de las métricas me armé (aparte de usar la ya existentes) un juego de métricas y estimadores para decidir hasta que punto es recomendable.

Empezado por Caral

Hola
Yo ni opino.
Nada mas veo y aprendo.
Si no digo algo no me llega por correo.
Cuando los maestros se reunen hay que estar presente.

Pero Caral, hombre, te invito a que dejes tu opinión en el tema. Que tienes experiencia, y puede ser enriquecedor tu aporte.

Bueno para finalizar... repito:
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?

Disculpen si el debate no tiene sentido... pero me pareció una buena idea, ver los aportes de grandes de estos foros. Yo lo hacía con el fin de aprender y comparar mi modo de entedimiento de lo que es este mundillo de la ingeniería del software.

Saludos,

[[Al González]]

¡Hola a todos!

Empezado por Delphius

...Al, yo también soy partidario a particionar el código. Yo dentro de mi esquema de trabajo impongo esa actividad... pero tal como dicen otros... tampoco hay que decaer en el extremo...

Hubo un tiempo en que solía caer en el extremo y hasta pena me da ver algo de ese antiguo código. Pero, como empirista que soy, hube de llegar al extremo (tocar fondo) para apreciar las desventajas y entonces atomizar el código sin rebasar esa delgada línea donde un If se convierte en un IIf sin gran ahorro de código ni ganancia de inteligibilidad.

Insisto en que pongamos un ejemplo de función Delphi de más de 20 líneas de código nativo y hagamos el ejercicio de atomizarla. Nos permitiría acercar criterios en esta materia y establecer una norma teórica.

Un largo abrazo.

Al González.

[[Lepe]]

Empezado por Al González

Insisto en que pongamos un ejemplo de función Delphi de más de 20 líneas de código nativo y hagamos el ejercicio de atomizarla. Nos permitiría acercar criterios en esta materia y establecer una norma teórica.

Puesto que tienes la experiencia... ¿quien mejor que tú para buscar un ejemplo?.

Saludos insistentes

[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

[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?

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

Empezado por seoane

Por curiosidad, ¿que llamadas comente?.

Perdón, me refería a este tipo de llamadas:
A -> B -> C -> D ->....

...y fue Delphius quien la comentó...
(raise TIncorrectQuote.Create('Se equivoicó de persona')

[PabloTech]

Hola a todos.
Estoy de acuerdo con seoane y su profesor:

Empezado por seoane

Yo tenia un profesor que decia que si no puedes ver todas las lineas de una funcion sin usar el scroll es hora de partila en funciones mas pequeñas.

Aunque no soy tan drástico al respecto. Yo también tengo bloques de programa un poco mas extensos que eso. Pero, por lo general, trato de resumir los algoritmos para aclarar mi panorama. A los módulos trato de darles nombres bien significativos. Siempre trato de usar parámetros, pero en poca cantidad. Y casi siempre reviso en forma rápida el código completo.
En conclusión ( y es mi modesta opinión):

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

chau...

[Ñuño Martínez]

Empezado por Julio Caesar

Divide et vincere

Yo intento aplicar esta máxima en la programación porque, como dice seoane (más o menos) al dividir un problema grande en problemas más pequeños y fáciles de solucionar, el problema grande se hace más fácil de solucionar.

Aun así, cuando programo en C suelo unir esas rutinas pequeñas en una única más grande que después optimizo, pero antes he escrito y comprobado el sistema "atomizado".

[roman]

Empezado por Delphius

Disculpa roman si no me entiendes la pregunta... debí formularla de otra forma. No te enojes pero no coincido contigo en lo de modularización y reuso.

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.

Ahora, estoy completamente de acuerdo con este párrafo tuyo:

Empezado por Delphius

Si bien son dos palabras diferentes... son dos palabras que vienen mucho de la mano. 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. No se puede separar ambos conceptos totalmente, hay una línea delgada que los mantiene unido. Y creo que encontrar esa línea delgada es lo más complicado de hallar. Si estoy equivocado, avisenme... porque llevaría años equivocado.

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

Pero sigo sin entender el sentido de tu duda.

Creo que todos tenemos más o menos claro y estamos de acuerdo en ello, en que la modularización promueve el reuso y sólo hay que tener cuidado de no caer en la pulverización de código, tal como sintetiza Al:

Empezado por Al González

donde un If se convierte en un IIf

Sin embargo, si tal modularización produce llamadas en cadena

A->B->C->D-> ... ->A'

donde A' hace lo mismo que A, creo que todos concordaremos en que es incorrecto.

¿Es esto culpa de la modularización? ¿Tu duda va en ese sentido?

Quizá en algunos caso lo sea, pero eso no es óbice para modularizar, es sólo algo que debe revisarse y evitarse.

// Saludos

[[egostar]]

Coincido con todos en general, pero si hablamos como ya lo mencione de los estilos de programar y haciendo uso de lo dicho por Al

y hasta pena me da ver algo de ese antiguo código

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.

Empezado por AL González

Insisto en que pongamos un ejemplo de función Delphi de más de 20 líneas de código nativo y hagamos el ejercicio de atomizarla. Nos permitiría acercar criterios en esta materia y establecer una norma teórica.

Les pondré un ejemplo de lo que hacia con Delphi 16 bits y lo que hago ahora con Turbo Delphi y aún creo que no es lo óptmo.

En uno de mis sistemas y que desarrolle su primera versión hace ya algunos años, requiero de calcular la duración desde dos variables de tipo string de fecha y dos variables de tipo string conteniendo la hora.

con Delphi 16 bits

Código Delphi [-]
Function TLector.CalculaDuracion(FI,FF:String10;HI,MI,SI,HF,MF,SF:String2):String8;
Begin
  FIDate := StrToDate(FI);
  FFDate := StrToDate(FF);
  If FFDate = FIDate Then
     begin
       val(HI,HT,Code);
       val(MI,MT,Code);
       val(SI,ST,Code);
       DurIni   := CalculaSegundos(HT,MT,ST);
       val(HF,HT,Code);
       val(MF,MT,Code);
       val(SF,ST,Code);
       DurFin   := CalculaSegundos(HT,MT,ST);
       DurTotal := DurFin - DurIni;
       ConvDuracion;
       CalculaDuracion := DurHrsS+':'+DurMinS+':'+DurSegS;
     end
  Else If (FFDate - FIDate) = 1 then
          begin
            val(HI,HT,Code);
            val(MI,MT,Code);
            val(SI,ST,Code);
            DurIni   := CalculaSegundos(HT,MT,ST);
            DurIni   := 86400 - DurIni;
            val(HF,HT,Code);
            val(MF,MT,Code);
            val(SF,ST,Code);
            DurFin   := CalculaSegundos(HT,MT,ST);
            DurTotal := DurFin + DurIni;
            ConvDuracion;
            CalculaDuracion := DurHrsS+':'+DurMinS+':'+DurSegS;
          end;
End;

con Turbo Delphi

Código Delphi [-]
function CalculaDuracion(FI,FF,HI,HF:String):String;
Var
   FechaHora : TDateTime;
begin
   if TryStrtoTime(TimetoStr(StrtoDateTime(FF+HF)-StrtoDateTime(FI+HI)),
              FechaHora) then Result := TimeToStr(FechaHora);
end;

Que pasó, bueno, resulta que mi inexperiencia me dictó en ese momento que así lo tenía que hacer y me bastaba, ahora con TD encontré que todo ese rollo lo podía resolver en una sola línea, yo me imagino que hay algo mejor que eso, pero siendo sinceros me falta mucho para poder optimizarlo.

Yo me declaro inconpetente en hablar o discutir eso de atomización, ni siquiera entiendo el concepto aún, pero vamos, la idea principal que quiero expresar es como determinar lo que Delphius inicia como debate.

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?

Mi sentido común me dice Tolerancia CERO entre Modularidad y Complejidad, mi experiencia (o mi inexperiencia) no puedo medirla, eso es lo que hoy se, el día de mañana y sobre todo aqui en el club me dira otra cosa.

Salud OS.

[[AzidRain]]

Yo creo que la atomizacion del código simplifica en mucho el mantenimiento poterior ya que a todos nos pasa que despues de cierto tiempo se nos olvida un poco como iba el algoritmo sobre el que trabajamos para hacer x cosa. >Con código atomizado podemos llegar a tener cosas como esta:

  Procedure TMiVentana.EjecutaTarea;
Begin
  AbreTablas;
  PreparaGrillas;
  If ShowModal=mrOK Then
    GuardaDatos;
  CierraTablas;
end;

Muy entendible no?
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.

Otra práctica que de repente uso es la de hacer todo sucio y rápido y luego irlo partiendo, asi pues llego a tener funciones muy grandes que luego voy dividiendo y optimizando, asi por lo menos mis aplicaciones funcionan a a primera y las voy mejorando..

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