A todo nivel

sobre los comentarios en el código

2007-06-29T08:41:00.000-04:00

He escuchado muchas veces cómo con vehemencia y con orgullo muchos programadores aseguran no realizar comentarios a su código, esto me ha involucrado en más de una discusión poco productiva, sin embargo una vez tuvo sus efectos cuando conté la siguiente situación:
Recuerdo en la película Volver al futuro III (que protagoniza y dirige Michael J. Fox, una de mis favoritas en el género de comedias) una parte en la que Martin (el protagonista) entra a un bar en la época clásica de pistoleros del lejano oeste y traba una discusión con el pistolero malo, éste, como parte de sus burlas a Martin, hace notar a sus amigos que el chico llevaba ropa interior y él como machote sólo llevaba la que tenia puesta más las pistolas, también hace notar que Martin tenía los dientes limpios como los de una damicela, en contraste con la suya bastante ruda de hombre verdadero con restos de tabaco de mascar incluidos, claro que aparte también hizo mofa de lo "femeninamente" perfumando que estaba Martin en contraste con un macho como ellos.

No puedo evitar asociar esta escena con aquellas en las cuales los programadores dicen No realizar comentarios a sus programas, dicen ser buenos programadores tal cual el macho de la película, que nunca necesitaron ni creen necesitar de esas estúpidas cosas que se ponen entre barritas en los programas de machos.

Luego de un análisis, muchos de estos machos nunca han realizado programas mas allá que "cositas" o "jueguitos" o que nunca han trabajado en un auténtico grupo de desarrolladores para lograr un objetivo común. Es sorprendente sin embargo la vehemencia con la que defiende su posición, tal vez debido a que los únicos expectadores de su código han sido ellos mismos, equivalente a afirmar que los únicos que huelen su camisa cuando se la sacan son ellos y nadie más.

Entre una de las muchas funciones de los comentarios: pueden ser vistos como "etiquetas" que uno pone en los programas para su mejor "ubicación", tal como una secretaria pone etiquetas en los folders para ubicar maás rápidamente lo que busca o conocer el contenido de las mismas sin tener que leer cada documento que se encuentra en ellas. Esta sóla utilidad echa por tierra aquellos argumentos de los negadores de comentarios que dicen no necesitarlos por la claridad e ilumninación con la que ellos escriben el código. otra argumentación a favor es exponer el simple acuerdo o estándar del uso de variables, amén de las operaciones, de otra forma para conocerlas habría que leer todo o gran parte del código, cosas que estoy en total desacuerdo de hacerlas, especialmente si no es mi código.

Podría seguir contando muchas utilidades de los comentarios pero algunas son realmente tediosas, algunos son tan minusiosos que hay que alabar la paciencia y arte que exiben sus comentarios, ese es otro extremo que no comparto en absoluto. Los programas son programas y en estos tiempos no es posible pensar en desarrolladores superhombres que harán todo el software completamente solo. Ya no es tiempo de machotes que se enorgullesen de no necesitar desodorantes ni cepillo dental, vivimos otros tiempos, tiempos de desarrollo en equipo, tiempos de aceptar que no somos expertos en todo o en todas las áreas que quisieramos serlo, tiempos de aceptar que buenas ideas provienen también de otros desarrolladores, de aceptar los pedazos de código de otros e incluirlos en nuestros programas....tiempos ágiles.

Refactoring to databases (book)

2006-05-27T20:54:00.000-04:00

Nuevo (?) libro que tal vez vale la pena tomar en cuenta:

http://www.agiledata.org/essays/databaseRefactoring.html

Sobre el proceso de desarrollo de software

2006-05-23T10:46:00.000-04:00

Recurriendo a una técnica en particular del método estructurado de desarrollo de software se me ocurre una idea sobre como podría verse un proceso de desarrollo de software en general.
Esto es más o menos como realizar un metamodelo de procesos de desarrollo de software, sólo que en este caso centraré más la atención en la funcionalidad o dinamismo mas que en la estructura misma.

Resulta que al realizar DFD's con análisis estructurado, durante el proceso de explosíón de los DFD's, estos NO se los realiza de forma indiscriminada o con el criterio erróneo mayoritario de que se debe realizar la explosión para obtener "procesos mas simples" o para "bajar la complejidad de la trasformación que sufrirá la explosión" (si fuera así, sería de nunca acabar!). En realidad lo que se busca es el "estado" que requieren las transformaciones de datos para poder ser determinísticamente computables. Este estado es hallado en los almacenes de datos, por tanto la explosión de las trasformaciones de datos se debe en resumen a la búsqueda de almacenes que aún no se habian descubierto y que se sospecha de su existencia por la ausencia de algun "estado" que falta para que el computo de la transformación de dato sea deterministica. (uffff...parece dificil pero el concepto es sencillo).
Esta forma de desarrollo, se hace bástante análogo a la forma en que se realiza los procesos de desarrollo de software....los modelos de alto nivel No son deterministicamente computables y abstraen elementos tal que ayudan en la comprensión del problema pero no asi en su cómputo.
La obtención de modelos de menor grado de abstracción debe ser la búsqueda de los estados (en este caso, No se limita a estados, sino tambien a operaciones, colaboraciones, etc) que hacen cada vez más determinístico el cómputo de los modelos de software.
Es decir, podemos ver el proceso de desarrollo de software con una visión funcional tal que cada nivel de abstracción menor es resultado de haber resuelto un nivel superior de una forma precisa y determinística.

---Marcelo

Comentarios sobre MDA (Model Driven Architecture)

2006-05-15T14:04:00.000-04:00

Por ahora es interesante conocer que hay algunos esfuerzos para determinar de forma precisa los conceptos de modelo conceptual y modelo físico, sin embargo, el proceso de abstracción (desabtracción) no es tan discreto como para ser binario, es decir, podría haber planteamientos interesantes que ayuden el proceso de desarrollo de software tal que pueda encontrarse diversos modelos de nivel de grado intermedio de abstracción (y no sólo dos como plantea MDA, o los acostumbrados "conceptual y físico").

Me refiero mas precisamente a tratar de inferir algunos aspectos desde un grado superior con un sistema de deducción formal ( la transformación) tal que la obtención de modelos de grado inferior pueda demostrarse.

Actualmente una de las mayores dificultades con MDA es precisamente esta estructura de dos niveles...si bien es un buen punto esa definición...actualmente es demasiado lo que se tiene que resolver en el paso del primer nivel al segundo.

---Marcelo

Modelaje conceptual con objetos: una entrada de verdad

2006-05-10T11:14:00.000-04:00

Algunas definiciones para comenzar.

Modelo del software: modelo del sistema computacional que se está desarrollando.

Modelo del mundo: modelo del entorno del sistema computacional y que incluye a éste como componente.

Modelo conceptual: modelo del sistema computacional muy abstracto, muy similar a la observación en el modelo del mundo.

Modelo físico: modelo del sistema computacional muy parecido a su implementación (estructuras de programas que lo realizan).

-- Pablo

Tres cuadrados

2006-05-10T10:56:00.000-04:00

Este no es un blog individual. El problema es que no nos damos tiempo para llenar todos los dias este espacio para mantenerlo lo suficientemente interesante. Tal vez entre "tres cuadrados" podamos hacer algo más dinámico. Por lo menos lo intentaremos. -- Pablo

Nace el equipo

2006-05-10T10:07:00.000-04:00

Acabas de tener la única oportunidad de asistir al parto virtual de los Metamodeladores! El bebé está sano y tiene buen peso :-)