BlackPaper Es

Libro Negro Auler

Copyright (C) 2015 Redhuan D. Oon ESTA ES UNA PUBLICACIÓN ESPECIAL DE IROSES* SOLO CON OBJETIVOS ACADÉMICOS Y DE INVESTIGACIÓN. SU LIBRE DISTRIBUCIÓN ES PERMITIDA SIEMPRE Y CUANDO SE INDIQUEN LOS CREDITOS Y SE OBTENGA UNA APROBACIÓN ESCRITA POR EL AUTOR.

Traducción: Eduardo Gil ( [email protected] )

Arturo Pérez ( [email protected] [email protected] )

Original: http://red1.org/BlackPaper.pdf

iROSES Libro Negro Auler

of 27 Copyright (C) 2015 Redhuan D. Oon

Libro Negro Auler* Estudio del daño causado a un proyecto de software en curso.

Por:

Redhuan D. Oon

Lider fundador de ADempiere y lider de la comunidad de iDempiere

(Documento creado en su mayoría mientras me encontraba en Tokyo, JAPÓN)

Bajo el auspicio del cliente usuario:

A

Por sufrir un desastre generado por:

B

(nombres removidos para proteger a los culpables e inocentes)

July 15, 2015 version 0.5 (Revisión inicial)

*iROSES es una nueva e.V que he estado tratando de configurar y A esta ahora ayudándome a lograr.

*Auler es una palabra alemana que significa luz, algo que A ha visto finalmente. Que el Karma bendiga a A. Pero no puedo hablar sobre el fallo de B de quien espero que se arrepienta y devuelva algo del dinero a A. Y entonces su karma le sea restituido.

Este documento es llamado Libro Negro (Black Paper) en oposición al Libro Blanco (White paper) donde las mentes comerciales mienten. En lugar de eso este Libro Negro dice la verdad, no me creas, lee y compruébalo por ti mismo.



Índice

Cómo comenzó todo 4

Antecedentes Técnicos 7

Modificación de Código 7

Mejores Prácticas 8

Framework OSGi 9

Cambios en Plugins 9

El Código Modificado 11

Clases PO del Núcleo Duro (Hard Core) 14

Reemplazo del Núcleo 16

Validadores de Eventos (Event Validators) 16

Llamadas Externas (Callouts) 16

Modelo Extendido 17

Cambios en el Modelo del Núcleo 18

MOrder 18

MOrderLine 19

Ampliando 20

Ventana con Múltiples Pestañas 21

Máximas Importantes 24



Cómo comenzó todo Un día en mayo de este año recibí la llamada del cliente A, con el propósito de

recuperar, y analizar el trabajo hecho por el anterior contratista de IT aquí ya

referenciado como B. El cliente consideró a B más o menos a mediados de 2012, luego

de que B se presentó a sí mismo como un experto para implementar sus requerimientos

en el software ERP de nombre ADempiere (bifurcación de Compiere) el cual es de

fuente abierta y de dominio público bajo las condiciones de la licencia GPL.

Yo fui contactado previamente y de forma separada por B a mediados de 2013 para un

asesoramiento debido a mi role activo en iDempiere (bifurcación de Adempiere) porque

B quería saber cómo cambiarse a iDempiere y yo lo hice amigablemente sin ser

consciente de quien exactamente era el cliente. B no me solicitó participar sin embargo

unos meses después a través de algunos mensajes de texto y correos electrónicos

solicitando solo un limitado asesoramiento técnico. Fue una sorpresa para mí cuando

finamente A me contacta acerca de este caso. Me tomó algún tiempo asimilar todo

acerca de esto. Esto abre una oportunidad para mí, para registrar de una vez por todas,

una prueba documentada de lo que he tratado de explicar como el más grande

problema con las implementaciones de los ERP, el cual es que es altamente

dependiente de la gente y sus habilidades las cuales no son gratuitas. Cuando se hace

erróneamente puede costar más.

A me puso al día sobre todos los detalles del proyecto, solicitándome una opinión

alternativa sobre si él estaba o no en lo correcto acerca de que B no era experto en su

trabajo, el cual sentía estaba muy por debajo del promedio y no de las competencias y

expectativas de ellos. Como la relación con B eventualmente fue finalizada a finales del

año pasado, luego de varios intentos de obtener los servicios y otros aspectos del

proyecto, que también fallaron, finalmente llegaron a mí. Yo acepté su oferta porque

odio la telerrealidad (reality TV).

Según el cliente, su percepción negativa es originada porque reclama que:

1. El software tiene nuevos bugs introducidos dentro de la base por el trabajo de B que

no estaban ahí antes, pero que no es admitido por B.

2. El software modificado no fue entregado a tiempo sino mucho tiempo después, con

muy poco espacio para la preparación de los usuarios finales

3. La entrega final para la instalación del sistema en la ubicación del cliente finalmente

estaba llena de bugs que tuvieron que ser indicados por A a B quienes no tenían la

menor idea de que los causaba. A además tuvo que invertir mucho de su tiempo

para resolver estos requerimientos.

4. B incurrió en una seria de excesos en tiempo y costo que este facturó y cobró a A de

acerca de EURXXX,XXX (seis dígitos), los cuales sobrepasaron el presupuesto

inicial estimado. Todavía el proyecto no estaba operando en su totalidad, inclusive

con módulos importantes que ni siquiera funcionaban.



5. Las operaciones del día a día de la versión modificada de iDempiere 1.0c del cliente,

son aún un parchado continuo y arduos trabajos por parte del ingeniero de software

interno tales como insuficiencia de memoria donde el servidor es reiniciado

automáticamente a la medianoche de todos los días.

Yo solicite y obtuve del cliente:

A. El código fuente que B le dijo que había modificado. B. Los cambios en la base de datos que B realizó. C. Discusión previa, contrato y minutas de reuniones con B para poder dar un análisis

preliminar sobre si es un caso "a primera vista" (prima facie) en vista de mera

opinión que hay que emitir.

Mis observaciones están basadas directamente en tales fuentes entregados por el

cliente y discutidos con él. El código fuente tiene información cronológicamente logeada

que me permite examinar de manera exacta los cambios en el código en el curso de su

trabajo en relación al código base original del sistema. La información logueada además

me indica quien realizó dichos cambios y que más se ha cambiado durante su ciclo de

vida. Así que es fácil inclusive mostrar el impacto real de un mal trabajo.

El cliente ha sido muy amable y cooperativo y me ha suministrado detalles como Quién

exactamente modifico qué así como cuando el desarrollador propio del cliente tuvo que

intervenir cuando las cosas se volvieron críticas y luego de perder los servicios de B,

tuvo que manejar las cosas por él mismo. Yo tengo al menos dos casos para comparar.

La prueba siempre está en evidencia y la evidencia aquí es simplemente código.

Durante mi investigación inicial, en los siguientes días, pude dibujar una prematura pero

razonable conclusión que no solo coincide con su posición, que los cambios en el

software fueron mal hechos, pero contienen un gran número de flagrantes malas

prácticas que pueden resultar en problemas adicionales de funcionamiento,

mantenimiento e inclusive la pérdida de sus características como una aplicación de

fuente abierta.

Yo entonces procedí a encauzarlo en como debía reparar los daños, mientras estudiaba

más ampliamente estos cambios, para decidir si era mejor abandonarlos o hacerlos de

nuevo para asegurarse que el software comenzará a ser mas usable y efectivo en

cumplir las necesidades y expectativas del cliente. Después de otro mes más trabajando

en esto, he notado muchos más ejemplos de errores en el código-base y en el diseño de

la base de datos. En este punto coyuntural, ya soy capaz de emitir un reporte

substancial de como mis hallazgos son tanto para que A tenga un recurso legal así

como para mis propósitos académicos.

Este documento es mi esfuerzo profesional basado en mi experiencia personal con

exactamente este proyecto de software y no puede ser aplicado a una industria distinta

a la de los ERP usando otro tipo de software.



El cliente además ha expresado su intención de usar esto para justificar acciones

legales para reclamar costos incurridos como un resultado de una mala implementación

en su caso. No espero que este satisfecho ya que este episodio es parcialmente su

culpa por ser crédulo. Esto es además otra falla de un proyecto. B pudo pagar a la

sociedad e.V de Adempiere en Berlin una cuota más alta de patrocinio para ser

registrado ahí y dar la impresión de que eran implementadores capaces sin otros

requerimientos adicionales. ¿Cómo prospectos como A deberían saber? Ok no es culpa

de A. Nosotros somos parte del problema. Entonces cómo como comunidad nosotros

colectivamente ayudamos a traer a estos bebés al mundo, entonces tenemos que ser

parte de la solución.

Yo estoy altamente interesado en proveer argumentos técnicos en la manera más

completo y objetiva posible pero simple para el doble propósito de educar y ayudar a

prevenir que estas fallas ocurran de nuevo.

Yo veo las fallas más como la norma que como la excepción que muchos están

avocados a tratar de reversar. Mis viajes alrededor del mundo a más de 35 países me

han dado un sin número de historias de horror y referencias y entendimiento de lo

bueno, lo malo y horrible de las implementaciones de ERP tanto en Adempiere como en

iDempiere.

Yo estoy publicando esto como parte de mi esfuerzo en iRoses como una nueva

organización global que provea buenas consejos a muchos usuarios de ERP para

evitarles costosas desventuras. Uno de mis principales intereses con iRoses es proveer

un conjunto de referencias claras y recursos para la implementación correcta,

profesional y exitosa de un ERP.

Este reporte asume que el lector está familiarizado con la terminología básica en la industrias de las TIC particularmente en el desarrollo y la implementación de ERP.

Cualquier comentario o sugerencia acerca del contenido de este material puede se

enviado por correo a mu persona a [email protected] o [email protected].

mailto:[email protected]

mailto:[email protected].!



Antecedentes Técnicos

Un proyecto de software de fuente abierta satisfactorio tiene la siguiente importancia:

1. Existe la posibilidad de acceder y modificar el código-base para ajustarlo a las

necesidades de los usuarios del cliente.

2. Las modificaciones deben ir de acuerdo a las mejores prácticas de la industria de la

ingeniería de software para asegurar el mejor rendimiento.

Modificación de Código

Existen un gran número de partes del software abierto a modificaciones:

1. Cambiando partes relevantes de código binaro a nivel de código fuente. El código fuente está

ubicado en http:// bitbucket.org/idempiere/idempiere. Aquí puedes encontrar todo el código

fuente necesario para operar la aplicación desde cualquier sistema operativo como Linux,

Unix, Mac OSX, y Microsoft Windows. Está basado en Java, scripts SQL y archivos de

configuración. Todos están abiertos a modificación.

2. Cambiando la metadata que define la estructura de la aplicación. Esta se encuentra en la

base de datos que puede ser PostgreSQL y Oracle. Está también abierta a cambios. Una

entrega sobre la metadata puede ser accesada aquí: http://red1.org/DocBook/.

Sin embargo cuando alguien hace cambios de alguno de los dos tipos de código base,

usualmente se gestiona:

1. Rastreando la historia de los cambios en los archivos fuentes, que son compilados en jars o plugins.

2. Scripts de migración en el lenguaje SQL aplicables a la base de datos únicamente.

Es importante destacar que la industria del software es:

A. Cambiante rápidamente y el software en sí mismo sufre grandes trastornos en el paradigma

técnico, contextual o en el ambiente de progreso, en el enfoque del desarrollo así como en el

estilo de código. Es como tratar de comprender la industria de las aerolíneas desde su

comienzo hace 120 años en el espacio de una década.

B. El software ERP es altamente complejo ya que trata de integrar muchos procesos de

negocios centrales en una organización y más allá de sus paredes. En comparación, 85% de

los proyectos de IT fallan pero el 92% de los proyectos de ERP IT suelen fallar.

Yo haré referencia a esas prácticas relevantes que observé como el legado de un estilo

anticuado y porque las fallas al cambiar al enfoque moderno resultó en un indeseada y drástica

disminución en el rendimiento del software inclusive con riesgo de pérdida de integridad en los

datos. En resumen este es otro ejemplo clásico que se encuentra dentro de la estadística del

92%.

http://red1.org/DocBook/



Mejores prácticas

Es importante notar que el carácter del software puede tornarse en código cerrado o inefectivo si

los siguientes aspectos ocurren:

1. El código base es modificado sin estar en concordancia con las mejores prácticas resultando en,

2. Separarse del proyecto central, es decir, 3. Ser incapaz de aceptar nuevas funcionalidades que ocurren el proyecto principal dentro del

código base modificado. 4. Dificultad de mantener porque los cambios ahora son bifurcados de forma privada o cerrados

definitivamente. 5. No compatible con otros softwares que continúan cambiando rápidamente.

Esto significará un incremento en costos en lugar de una reducción de los costos de propiedad

como se requiere por parte del cliente y de los consultores que implementarán el proyecto

basados en software de código abierto.

Esto es precisamente lo que estaba ocurriendo con el cliente y los consultores que tenia cada

día más retrasos, bugs terribles y la rapidez del tiempo forzó a un circulo vicioso de más errores

y mala preparación para afrontar inclusive tareas más importantes como probar el estado del

producto antes de poner el sistema en producción.

Para asegurarnos que el proyecto sobrevive por sobre su ciclo de vida y ciclo de uso de

aproximadamente 5 a 8 años, debe ser establecido:

1. Documentación adecuada para la administración del diseño y los cambios. 2. Separación de los cambios del núcleo en módulos plugins que se puedan incorporar y

desincorporar de forma compatible con los cambios de terceros.

3. Unidad, integridad y pruebas regresivas.

Aunque el trabajo se haya completado parcialmente para el punto 1, ha fallado miserablemente en los puntos 2 y 3.

El impacto del punto 2 es además una cuestión de desempeño y escalabilidad. Las excelentes

propiedades de un software empresarial como iDempiere son convertidas en inútiles cuando

cambios innecesario y excesivos en el código son introducidos en el corazón del modelo de

diseño al azar en lugar de manejarlos de acuerdo a las mejores prácticas de separación del

núcleo, en un ambiente apropiado de versión y prueba.

En las siguientes secciones, debo examinar exactamente la construcción de los cambios en

código para impartir plenamente lo que es referido aquí y el remedio correcto como una

alternativa. Además también tenemos la oportunidad de demostrar que las mejores prácticas

recomendadas actualmente funcionan y mejoran o restauran la instancia del código base del

cliente a una condición de alto rendimiento.

Pero primero una cosa más sobre el ultimo desorden de tecnología en el uso de iDempiere que

puede explicar la dificultad o necesidad de experiencia competente de sus promotores.



Framework OSGi

Aunque este término, framework OSGI es familiar para los desarrolladores de Java

contemporáneos, es relativamente nuevo en la disciplina de prácticas apropiadas. OSGi

es el acrónimo de Iniciativa de Incorporacion de Servicios Abiertos (Por sus siglas en

inglés) el cual básicamente se refiere a un común pero avanzada interface estándar

para que el código se cree en forma de bundles o componentes que interactúan juntos

como una aplicación común pero con una limpia y clara separación del enredo de las

dependencias. Esto es conseguido a través de una conjunto de reglas que gobiernan

como cada componente es expuesto o toman algo entre ellos. Expertos en la industria

han descrito al concepto de OSGI como el primer verdadero estilo de componentes que

Java ha estado esperando.

El concepto OSGI es parecido al sistema de cables eléctricos de tu casa. Si solamente

usas cables y no interruptores, con toma corrientes o extensiones podrías alumbrar toda

tu casa. Pero imagina cuando una bombilla o foco se rompe o cuando deseas arreglar

algunas.

Esto en organizaciones grandes y complejas del mundo de la programación orientada a

objetos, es el santo grial donde los desarrolladores desean encontrar una alta agilidad

para realizar cambios robustos, estandarización, eficiencia y mantenibilidad. El mundo

de los ERP sirve para mantenerlo estable. No sería sano regresar a puros cables

eléctricos todos revueltos y constantemente volver a cablear cosas como definiciones,

requerimientos y cambios en el entorno.

El proyecto Compiere fue creado alrededor de 1999 cuando Java estaba todavía en su

adolescencia. La bifurcación Adempiere hasta 2011 todavía usaba el viejo modelo de un

solo cable con una pila de jars que en el mundo de la programación se refieren como el

infierno Jar. Iniciando en 2009 algunos desarrolladores con grandes habilidades en

conjunto con una comunidad se iniciaron a explorar el uso del framework OSGi,

resultando en la primera versión beta en 2011 y eventualmente su primera versión

estable en el 2013. Durante la primera creación de código modificado a un cliente a

finales de 2013, la versión en uso de ese momento era 1.0c.

Cambios en Plugins

La practica subyacente de usar OSGI en iDempiere persigue el aspecto descrito

anteriormente el cual permite que cualquier cambio al código base resida

completamente fuera del código base en forma de plugins que están apartados pero

altamente cohesionados. Estos pueden ser "eliminados" del la aplicación de software

mientras la aplicación se encuentra corriendo sin tener impacto alguno en la pila del

núcleo de la aplicación.

Un desarrollador nuevo o no iniciado puede todavía programar estos cambios de la

forma anticuada la cual es introducir en la pila del núcleo sus procesos sin considerar la

necesidad de plugins. Esta práctica haría el framework OSGi de iDempiere sin sentido y

redundante. El código base perderá en ese punto todos los beneficios descritos.



Como he mencionado anteriormente, cualquier intento de mejora por la comunidad

abierta, la cual es otra gran bondad de usar software de fuente abierta es además hecha

tremendamente difícil debido a que cada cambio exterior podría ahora impactar el

cambio local adaptado con el mismo núcleo.

Los cambios en plugins son mas fáciles de leer y administrar. Pero, lo contrario es

verdad, el abandono de los plugins para cambiar directamente el núcleo es difícil de

rastrear y administrar.

Los plugins tienen servicios declarados y puntos de extensión para lo que es conocido

como Callouts, Procesos, cambios en las bases de datos, sobreescritura de código y

validadores de eventos. Como en 2014, el proyecto en comparación con sus

predecesores, Compiere y Adempiere tiene grandes mejoras de desarrollo y actividad

en la comunidad.

OSGI no es solo popular sino un estándar aprobado en el arsenal de herramientas de desarrollo de IBM tal como el IDE (Entorno integrado de desarrollo por sus siglas en ingles) ECLIPSE.



El Código Modificado

Como presente anteriormente, el código que nosotros examinaremos a continuación se

encuentra en dos formas, mayormente paquetes Java y scripts de base de datos SQL.

Le presentaremos una cuantificación resumida de los cambios hechos y miraremos en un

grupo importante y selecto de ellos que estudiaremos en profundidad. Lo que estaremos

buscando será la falta de uso de plugins y la introducción directa de cambios en el núcleo y

otros anti-patrones.

Arriba podemos ver una pantalla de la historia completa de los cambios en el código de

acuerdo a la herramienta de control de versiones, Mercurial a través de Eclipse, el IDE

libre de IBM. Remarque nombres con cuadros de colores, azul para A y negro para B.

Note el momento del cambio sobre B, a el ingeniero interno de A. Note además como A

parece ser más aproximado y profesional para dejar observaciones y narrativas útiles,

que lo hecho por B.

Esto hará más fácil mi análisis ya que puedo diferenciar mejor y emitir juicio sobre el

trabajo de A sobre el del prematuro B. También lo oculte para evitar ser perjudicial para

ninguno. Estoy más interesado en lo que se hizo y no en quien lo hizo.



Ahora haremos una selección inicial para examinar más de cerca los cambios hechos.

Arriba y abajo hay una toma instantánea de tres commits en la historia de versiones con

el código fuente provisto por el cliente. El número total de cambios de B tiene muchos

cambios en archivos de clases de Java. La mayoría de ellos parecen estar en el

conglomerado de plugins del núcleo los cuales están bajo el mantenimiento del dominio

público del equipo del proyecto como se puede ver en línea en el motor de

mantenimiento http://jenkins.idempiere.com/job/iDempiereDaily/changes.

Esto es un gran hallazgo y ciertamente eleva las alarmas acerca de las historias de

horror relacionadas con esta investigación. La fecha de arriba 20 de diciembre de 2014

es en la onceava hora en la cual el sistema debería ser apagado hasta el 1 de enero de

2014. Esto tiene todos los signos reveladores de la fatalidad: enfoque Big Bang, sin

régimen de pruebas en sitio, sin ir acompañado de notas de versión y, definitivamente,

un campo minado con una bomba de tiempo haciendo tic-tac a distancia.

Los commits en los cambios son además hechos en su totalidad con grandes

cantidades de cambios en lugar de darle un tratamiento atomizado, cada cambio en un

commit separado. Ahora no es posible hacer rápido cualquier reverso a los errores pero

el mantenedor tiene que recurrir a una solución puntual manual y difícil.

El segundo commit en tiempo fue el 13 de febrero de 2014, tiene de nuevo un gran

número de clases y ahora sin ningún comentario en el mismo. Otra vez note que

http://jenkins.idempiere.com/job/iDempiereDaily/changes!



pertenece enteramente a los plugins del core, es decir, org.adempiere.base. Lo asumido

más temprano es correcto. El fuego se expande y el pobre cliente está en una lucha con

un montón de incendios. No sorprende que B renunció y dejó la escena del crimen para

que A la defendiera solo.

El tercer ejemplo es en fecha 28 de febrero de 2014 abajo. Esta vez hay un comentario

no descriptivo que cubre un gran número de clases y que parece ser un único gran

plugin. No está claro si son de la misa intención pero tampoco la intención esta

especificada.

Una explicación más completa, es ahora expuesta en el siguiente análisis detallado de

un set de clases del núcleo.



Clases PO del Núcleo Duro (Hard Core)

Quizá el nivel más bajo de clases del núcleo son las clases Persistent Object de las

cuales todos los demás objetos dependen y que reutiliza las definiciones del núcleo.

Abajo podrá encontrar la información de la cabecera de la clase.

La clase completa puede ser buscada en google tal como aquí le mostramos

https://searchcode.com/codesearch/view/3306742/. Esta clase está en el más alto orden

en la jerarquía de dependencia de objetos en el código Java. Como se puede apreciar

en la cabecera arriba solamente, la cantidad de comentarios y sus referencias refleja la

complejidad de lidiar con esta clase. La forma en la que cualquier cambio es introducido

a esta clase es estrictamente revisado previamente por la comunidad. Es una práctica

de la mayoría de los desarrolladores no tocar esta clase pero si recomendar cambios

solo bajo los más estrictos escenarios. De igual forma si el desarrollador se atreve

todavía emprender algún cambio en esta, se realiza una bifurcación (fork) y relega su

versión de la clase lejos del proyecto principal y él o ella tienen que mantenerlo cada vez

que haya algún cambio de él o ella o de la comunidad ahora "afuera" hasta donde

concierna a la modificación de la clase. Una clase privada bifurcada estará ausente de

la revisión por pares externos y sufrirá inclusive un mayor decaimiento y un pobre

aseguramiento de la calidad.

Y eso es lo que pasó rápidamente al código fuente del cliente. Aunque el cambio está en

minuta (solo observaciones en dos líneas y una variable suspendida no utilizada), un

usuario final informado o un desarrollador interno tendrán un motivo de alarma



innecesaria cada vez que se tenga que lidiar con esta clase en el futuro ya que con

cualquier cambio en el repositorio del núcleo se marcará esta clase como una clase con

cambios privados y puede ser difícil de combinar debido a posibles conflictos. Como se

puede observar abajo, compare las observaciones hechas antes por B con "globalqss".

Las observaciones de B no son de ayuda para explicar que no hay ningún intento ni

referencia alguna para la revisión de pares.

!

Como el cambio en minuta es insignificante, hacerlo dentro del núcleo tiene un impacto

serio. Esto es tan descuidado como dejar colocada una llave que no se utiliza en el

motor principal. Un día algo puede e irá mal. Se aconseja que este tipo de riesgos sean

impedidos a toda costa.

Tal práctica de codificación da la impresión de que el desarrollador ignora la importancia

de asuntos importantes como son:

1. El control de versiones dentro de la comunidad de pares.

2. Compatibilidad con versiones anteriores.

3. Estabilidad.

4. Documentación.

5. Administración o gestión de proyecto.

De aquí pasamos a otras clases tipo del núcleo, esta vez explicando otro aspecto del

estilo de codificación en uso para software como iDempiere.



Reemplazo del núcleo Hay casos en que el código del núcleo necesita ser reemplazado o anulado debido a

sus limitaciones para manejar ciertas funcionalidades nuevas y específicas. Hay una

mejor práctica para hacerlo. Una vez más todos los cambios deben ser alojados en

plugins externos y separados. La única diferencia es que ellos serán "extensiones" (add-

on) desde afuera.

Hay tres formas para que ellos puedan hacerlo.

Validadores de Eventos (Event Validators)

Esta característica ha estado presente en la Compiere original y ha sido heredada muy

bien hasta ahora en iDempiere. Sin embargo, durante los días anteriores al OSGi, ellos

eran definidos en otro jar personalizado que necesitaba ser recompilado dentro del

núcleo. Ahora en el framework OSGi, pueden ser ahora un independiente plugin.jar y

por lo tanto la recompilación del núcleo no es necesaria. Incluso se puede implementar

en directo, es decir, sin detener el núcleo de la aplicación. Esto es un gran salto

cualitativo en eficiencia y manejabilidad de una enorme caldero de código que sufre

continuos cambios.

EventValidators básicamente se disparan durante eventos que ocurran en documentos

como una Orden de Ventas, Factura, Pago y movimientos del Inventario. Cuando un

documento es creado, modificado, guardado, procesado o borrado, un código

personalizado puede interrumpirlo para dar mayor control y manipulación de datos.

En iDempiere el EventValidator está totalmente asentado en un plugin externo,

literalmente porque incluso la activación de metadatos del Modelo Validador que alberga

el EventValidator tampoco se hace en un archivo de configuración del núcleo sino en la

declaración externa de los servicios. Esta es también una técnica de software moderno

llamada el principio de Hollywood, "No me llames, yo te llamaré". Esto hace al núcleo

calmado y ligero, permitiendo mayor velocidad de respuesta y escabilidad al mismo

tiempo.

En el código del cliente, tal modificación se maneja de esa forma que vamos a examinar

más a fondo después.

Llamadas externas (Callouts)

Otra característicaa heredada de Compiere es el uso de llamadas externas a columnas

(Column Callouts) que entran en juego durante el cambio del campo de una pestaña de

una ventana. En el OSGi de nuevo la definición de metadatos dentro del núcleo de la

base de datos de éstos son retirados y dejados exclusivamente en un servicio de fábrica

con esquema de extensión que sigue de igual forma el principio de Hollywood.

Sin embargo, como veremos más adelante, el código modificado no uso la definición de

las Callouts en plugins pero siguen siendo los mismos dentro de los metadatos de base.

Pero áun, el código personalizado es combinado dentro de un estándar base de Callouts

y será difícil para separar cuando el núcleo cambie a través del tiempo.



A partir del resumen anterior hay cerca de 4 Callouts del núcleo involucradas. Esto se

agrega a la dificultad del mantenimiento que ya ha sido descubierto hasta ahora. A

pesar de ello, yo aún voy a mirar dentro de los Callouts mismos para descubrir a fondo

cualquier complicación extra del diseño y estilo del código.

Modelo Extendido

Las tablas o modelos del núcleo pueden ser extendidos por ejemplo en una tabla de

Producto, puede haber necesidad de dar a un producto mayores atributos o un carácter

que no está disponible en el presente diseño base. Una vez más, para hacerlo en los

tiempos de Compiere y ADempier era necesario definirlos en un customised.jar y

volverlos a compilar con el núcleo de la aplicación. La definición también repite de vuelta

el modelo base más las propiedades adicionales en una masa concentrada. Esto se

realiza en forma de sobrecarga o de manera primordial lo cual es prohibitivo para el

mantenimiento futuro..

En iDempiere, no solo tales extensiones de modelos se encuentran definidos en plugins

externos sino que también ellos tienen una clara separación y no impactan al núcleo.

Digamos por ejemplo, que el núcleo tienen un nuevo cambio y el modelo personalizado

no especificó tal cambio. Ese nuevo cambio puede perderse. Esto se considera como un

impacto o incompatibilidad hacia atrás o inestabilidad cuando nos referimos al tiempo

futuro.

La mejor práctica de iDempiere es hacer uso de una construcción de código llamada

POWrapper que envuelve el diseño del modelo del núcleo añadiéndose a él sin anularlo.

Es simplemente A + B, en lugar de B sobre A. Cualquier modificación posterior de A o B

tiene un impacto mínimo o nulo entre ambos. Mientras que tomar un objeto sobre otro es

enredado o bloquea exclusivamente el intento del uno al otro. Lamentablemente tal

avance en la construcción de la codificación que ya se ha hecho pública en el proyecto

wiki en línea no fue puesta en práctica en el trabajo de B.

(Desarrolladores más avanzados pueden impugnar la presunción que el framework

OSGi está 100% desacoplado del núcleo y que esto no tiene mayor complicación. Así

que para ser precisos, no existe algo como un objeto flotante real en un mundo virtual,

pero sí el espacio referencial con punteros. Es suficiente para nuestro propósito que

iDempiere sea un salto cualitativo de la forma en que ADempiere es extendido. Este

importante hecho se hizo claro para B durante mi noche inicial completa y reunión

matutina con ellos en 2013 que ellos concertaron para escuchar directamente de mí

porque los principales codificadores del proyecto desean cambiar a esta nueva

tecnología.)



Cambios en el Modelo del Núcleo Examinaremos clases tipo porque ellas son referenciadas después por el ModelValidator

durante el EventValidation. El primer cambio de abajo es otro claro ejemplo de la falta de

cuidado.

MOrder

Parece ser que no se acordó ninguna revisión de pares, tampoco se tuvo la

preocupación del posible impacto que esto tiene sobre una clase tipo del núcleo. La

observación dada parece parcial y ejecutada sumariamente. La eliminación de una

excepción que tiene significado para un método definido claramente, es decir,

copyLinesFrom donde ahora copiará el encabezado si las líneas están ausentes. Me

preocupa como un desarrollador será capaz de hacerlo a través de todo el ERP, él o ella

tendrán que batallar. Debe haber un método diferente para manejar esto y alojarlo en

procesos separados dentro de un plugin independiente. Pero espera, existe ya una

función copyHeader en la pestaña de cada ventana normal. B es un murciélago sordo.

Porque los murciélagos no son ciegos.

De todos modos, por el bien del argumento, para resolver esto podemos utilizar la nueva

clase MOrder que amplia a org.compiere.model.MOrder puesta junto con otros nuevos

campos en un POWrapper y anular este método. Es evidente que el desarrollador aquí

es ajeno a las repercusiones del significado de la palabra "impacto" en el cambio del

código. A continuación se muestra el otro cambio en MOrder:

Po ahora no hay más duda en mi mente que dicho código no tiene el propósito de ser

actualizable siguiendo progresivamente las versiones futuras de iDempiere. El

desarrollador que hizo esto no tiene idea en absoluto sobre el manejo del diseño de

código y su framework a un nivel profesional. Es muy seguro decir que toda la base de

código está destinado a quedar atascado en la versión 1.0c por siempre. (iDempiere en

el momento en que escribí esto se estaba moviendo de la versión 2.1 a la 3.0 con

características superiores de los servidores de aplicaciones ZK UI y Jetty.)

A continuación, me gustaría matar a dos pájaros de un tiro. Quiero mostrar un cambio

que B hizo y que después A revirtió.



MOrderLine

Se puede ver que A revirtió una pieza en la clase MOrderLine hecha por B. Lo que A

hizo es más aceptable, que es producir una ticket para esto (Ticket 116) y ofrecer una

explicación exhaustiva en alemán, abajo se pega la salida del Translate.Google.

Ticket [116] El descuento de la venta será redondeado después de guardarse. Corregido. Como se redondea a 2

decimales e iDempiere también debe calcular nuevamente el descuento cuando se guarde la posición actual, habrá

desviaciones. Por esta razón se realiza el cobro inclusive después de entrar en el descuento, el único posible

descuento de venta, de hasta 2 decimales se ajusta exactamente con la lista de precios de UK y VK-net y se lleva

adelante. Esto es en mí opinión, el único valor correcto si queremos redondear el dinero en efectivo a 2 posiciones

decimales.

Bajo que condiciones entonces hizo B ese cambio?. Vamos a rastrear de regrso esta

historia y llegamos a la observación que es solo un guión "-".

No se ofrecen comentarios en absoluto. Y para añadir más leña al fuego nuevamente

agrupados con clases con diferentes propósitos y sin relación. Así que aquí tenemos

que aprender otra lección importante. Documenta tu trabajo y deja rastro de los cambios

de manera atomizada para que otro colega como yo pueda revisarlo o analizarlo con

placer o desdén. La elección es tuya.



Ampliando

El cliente A tiene un requerimiento que es típico y puede ser común a muchos usuarios.

Desean extender la Línea de Orden (Order Line) para administrar los artículos de un

producto así como muchas otras propiedades nuevas como puede ser la tasa de cobro

que lleva un conjunto diferente de cálculos de acuerdo al producto elegido. Un producto

X puede tener una tasa de cobro debido al mercado al contado de X o el usuario puede

elegir una tasa de mercado diferente para él. Diferentes productos tienen un tratamiento

diferente de las tasas.

Por último, el cobro derivado de una fórmula para la tasa es agregado al costo de la

Línea de Orden del producto. Ahora ¿Cómo debe uno hacer eso?. Lo que ocurrió en

nuestro sistema desfavorable es que esto fue agregado en la misma tabla de detalles de

la OrderLine. Esto ahora sobrecarga una muy importante y ocupada tabla de línea con

más información que tiene muchas acciones alrededor de ella como parte de la atareada

Orden de Ventas. OrderLine ya tiene Callouts y eventos validadores trabajando hacia ella

para hacer tareas comunes como son descuentos, cálculo de precios y el total de línea.

Y con razón, cuando yo estaba en el lugar del cliente para tratar de usar las Ordenes de

Venta en ambiente recién migrado a la última versión de iDempiere 2.1 (Sí, incluso los

patitos feos pueden ser salvados para llegar a ser un cisne), todo era mucho más rápido

excepto el tratar de rescatar la OrderLine. Después de algunas averiguaciones

encontramos que el sobrepeso de la OrderLine se debe a que tiene demasiada actividad

recursiva pasando en su interior.

Entonces señalé al actual diseño de los metadados ya prevalente desde Compiere en

como manejar actividades diferentes dentro de una misma pestaña.



Ventana con Múltiples Pestañas

Este diseño ha estado presente desde los días de Compiere, el cual consiste en tener

básicamente pestañas múltiples o tablas para ser relacionadas a sus respectivas

pestañas maestras. A continuación se muestra un ejemplo de un caso que manejé hace

11 años durante los días de Compiere.

! Se puede ver que es para un negocio de Venta de Automóviles. Así el Encabezado de la

Orden tendrá la clave ID del cliente con más información, como por ejemplo, su

inscripción a la escuela de manejo que se necesita y puede ser manejada en otra

pestaña la cual tiene su respectivo vínculo C_BPartner_ID que las une entre sí. Y

además de eso, en la OrderLine está la clave ID del automóvil la cual puede registrarse

en otra pestaña y así sucesivamente, el Financiamiento de su Préstamo, etc. Cada

pestaña está asociada con su propio modelo de tabla y no pide prestado a uno anterior.

Esta es la separación adecuada y un diseño más normalizado de la base de datos

permitiendo el control sobre las relaciones muchos a muchos (many to many).

El Diccionario de la Aplicación Compiere ya atiende este tipo de comportamiento

permitiendo una infinidad de pestañas que son sofisticadas pero eficientemente

vinculadas, sin el usuario para hacer una configuración redundante del los elementos

repetitivos (boilerplate) o del código.

Este es un caso típico del deseo de B para saltar en el lucrativo negocio de la

consultoría de ERP sin prestar atención a la competencia y experiencia requerida. He

conocido a una gran cantidad de Bs en mis viajes alrededor del mundo.



En el ejemplo de nuestro cliente, queremos el Product_ID de la OrderLine para tener

mayor detalle de la pestaña que explica a la tasa del producto y su vínculo con su

M_Product_ID. Esto separa en un nuevo modelo solo para el ProductRateCalculation.

Puede hacer lo que desee en su propia cápsula atómica y no enredarse con otro modelo

heredado el cual ha existido desde la antigüedad y Dharma sabe que más está pasando

allí.

También recuerda nuestro principio de separación de la herencia del núcleo donde todo

lo que es hecho por la comunidad de pares para mejorarlo definitivamente bloqueará tus

cambios o viceversa. Pero entonces el usuario dice, "¿Qué pasa con el total que

tenemos que mostrar en la misma Línea de Orden?".

Allí entonces puede estar un mal necesario de agregar un solo campo en la ID de la

OrderLine para especificar el " RateChageAmount" y una llamada externa puede tomar eso

y agregar el campo PriceList para mostrar que el precio del producto es incrementado

con un cargo extra. A continuación se muestra una imagen que A me envió después de

los requerimientos para tener pestañas adicionales para la OrderLine. Originalmente B

lo diseño como se muestra pero la estructura subyacente de la pestaña reutiliza la

misma tabla OrderLine en lugar de dividirla en tablas individuales "MetalCharge" y

"WEEE".

Esta es una captura de la pantalla de la PC de A.

La mejora en el desempeño fue notable, de colgarse, a trabajar normalmente. Y su

mantenimiento será más fácil. Observe en la ventana como ya hay una gran cantidad de

nuevos campos adicionales en el encabezado principal comenzando con "as1". Sí,

iDempiere está abierto a modificaciones pero realizar cambios sin un buen fundamentoe

es saltar al fuego.



Cuando miré la forma en que B agrupó todo junto incluyendo otros requerimientos como

el de "Gruppi" el cual es examinado en el siguiente capítulo, encuentro un modelo

OrderLine hinchado hasta con 111 campos. En el panel de la derecha se pueden ver los

otros campos adicionales.

Sí, entiendo que el cliente quiere muchos de esos campos pero existe una

especialización llamada diseño de sistema donde grupos de campos pueden ser

agrupados en modelos separados para el manejo lógico así como para evitar el impacto

adverso. Esta misma OrderLine mostraba ya hasta 3 pestañas separadas como se

mostró en las últimas páginas con sus pestañas " MetalCharge" y " WEEE’

Esto no es diferente de la pestaña OrderTax que maneja los impuestos para toda la

orden y puede manejar los impuestos para una OrderLine individual. Esto no viene en la

pestaña OrderLine y de hecho permanece fuera y solo introduce cálculos en muchas

formas pero después y fuera de forma.

Si necesitamos digamos, información en tiempo de ejecución como el resultado del

impuesto para un determinado producto, es posible utilizar una simple llamada externa

directa para buscarlo y regresarlo con los datos.

Si más información es necesaria para ser vista de cerca, podemos usar una columna

virtual para mostrar un valor derivado sobre la marcha. Si se requiere más, entonces

utilice una pestaña adicional como se explicó anteriormente para una vista sub-

maestra/detalle o bien un diseño InfoWindow el cual es un trabajo difícil pero más

elegante y mantenible en una ejecución larga.



Máximas Importantes

Otro requerimiento importante de A es agrupar los artículos de los productos bajo

determinados empaquetados para algunos propósitos:

1. Para ocultar detalles de los artículos y mostrar únicamente el precio del paquete del grupo.

2. Para mostrar todavía los precios de detalle pero sólo para el personal interno.

3. Para acceder a una largo historial de precios de venta anteriores que sus clientes todavía quieren.

Ahora será un gran dolor de cabeza si el desarrollador consultor simplemente empuja

estos nuevos campos en una sola tabla. Y eso es exactamente lo que hizo B. Le

expliqué a A que iDempiere ya lo ha heredado de Compiere y ADempiere a través de

los años y una máxima importante que siempre enseño es:

Pregúntese si otra persona en el mundo tiene el mismo

problema. Si es así, entonces la solución podría estar ahí.

Entonces les expliqué acerca de más modelos ya presentes en iDempiere como BOM

(construcción de materiales) que puede ayudar a resolver el empaquetado del grupo. Un

EventValidator especial puede recoger ese grupo y rescribir el OrderLines simplemente

mostrando u ocultando lo que se quiera, o mejor aún, un formato de impresión especial

que sólo lo haga durante la impresión de los Presupuestos de Venta

También enseño otra máxima:

¿No podría un avanzado, global y público ERP software

como este tener lo que necesitas?

Sin embargo, debido al desorden creado por B, los trabajos de reparación son mayores

que el trabajo original. Debido a que el sistema ha entrado en producción con todos

estos errores, un esfuerzo de migración para convertir la estructura de la vieja tabla

(invalida con pestañas adicionales) en una más normalizada en diseño con nuevas

tablas representando los nuevos modelos relacionados. La buena noticia es que A

aprende rápidamente y la nueva estructura de la tabla se ha hecho y funciona. Ahora es

sólo arreglar procesos dependientes e impresiones.

Hay mucho más para cubrir, como el ModelValidator hecho por B que actualmente tiene

4000 líneas de longitud tratando de ser el todo para todos. Y mucho de sus accesos a

los modelos de datos no siguen las plantillas ORM de los setters y getters haciendo

largas, pesadas y riesgosas cadenas SQL que abundar en su interior. Por supuesto,

esto no es sólo una puerta trasera para los hackers se introdzcan al SQL, es también

una fuente de pérdida de memoria causando que el sistema falle todos los días.



Arriba podemos ver como esto ha pasado las 4,000 líneas. Debería existir más series

segregadas de eventos apropiadamente ligados para cada evento individual del modelo

de tabla para una más fácil depuración. Un error (bug) aquí y eso es todo, todo el

validador puede fallar. Observe también el uso del método ORM abierto que permite

valores de cadena escritos a mano en lugar de aquellos mecanografiados

estáticamente.



Pego abajo una sección adicional del largo EventValidator.

Observe el "gruppi" intento de empaquetar productos para los cuales yo sugeriría

explorar el "Phantom" BOMType existente ya en el plugin de Fabricación de Libero. Por

supuesto, la utilización indiscriminada de cadenas SQL nocivas es alarmante cuando ya

existe un modelo ORM que solo necesita la ejecución de GenerateModel para crearlas.

La pereza es costosa. Que no debe ser cuando B ha sido pagado muy bien para hacer

un buen trabajo.

En este momento, la instancia anterior de iDempiere con una actualización importante,

es probada.

1. Son aplicados scripts de migración para llevarla a la última versión 2.1.

2. Separados los procesos y ventanas de información (info-windows) en plugins

separados.

3. Priorizando en el núcleo los procesos hechos dentro de fragmentos de plugin.

4. Separando las pestañas múltiples en tablas normalizadas.

5. Publicando para compartir todos los descubrimientos al público: http://wiki.idempiere.org/en/AulerSipel.

6. Hacer pruebas con la suite FItNesse sigue pendiente y esperamos completar esto a finales del 2015.

http://wiki.idempiere.org/en/AulerSipel



A medida que avanzo por todo el desorden, sigo encontrando más y más de lo mismo.

Esto puede volverlo loco a cualquiera.

Todo esto se evita simplemente siguiendo el sencillo principio de oro de "separación del

asunto" ilustra lo que resulta ser una antigua y buena máxima de Java por sí misma. Por

supuesto, toma una fuerte curva de aprendizaje cambiar un viejo hábito perezoso para

pasar a realizar un trabajo bien escrito y legible. Y la abundancia de Software de Fuente

Abierta dicta este hábito aún más, ahora que los usuarios pueden estar en contacto con

el código. Es como abrir un reactor nuclear para que los turistas jueguen alrededor de él.

Irónicamente, encomendé a B publicar un Libro Blanco (white paper) de su búsqueda al

mismo tiempo ellos me dieron un indicio de que ellos lograron probar que iDempiere es

mejor que MSDynamics para el caso del cliente, sin decir más. Los llamé nuevamente el

año pasado, cocinándoles mi famoso arroz con pollo, y de nuevo les recordé que lo

único que me interesa es el Libro Blanco que me deben y no su negocio. Ahora no

necesito esperar para ello pues desde que yo he visto la fuente y una buena historia que

me permite cocinar algo mejor que una telerrealidad (reality show). Esto es lo que me dio

la idea de un "Libro Negro" (black paper).

En mi ligera pasión del libre ERP que es claramente para un uso muy costoso, yendo en

contra de soluciones alternativas patentadas tales como SAP que puede moverse entre

millones de Euros, es un reto difícil volverse parte del 8% de las historias de éxito de

ERP. De hecho, yo mismo tengo mi parte de fracasos y constantemente aprendo y

escribo acerca de ellos. Esta historia no es la primera ni la última. La publicación de este

tipo de Libros Negros buscan cambiar la actitud para un mundo mejor.

Recuerda, la fuente puede estar contigo. Esto hace que sea fácil caer en el lado oscuro.

Si lo haces, solo admítelo, aprende de ello, publícalo y sigue adelante.

Luego conserva la calma y ven a la luz. :)

¡ Karma & Paz !

BlackPaper Es

Documents

Transcript of BlackPaper Es