Diferencia entre revisiones de «Propagacion de lo propietario»
(Página creada con «"Propagacion de lo propietario" es un antipatron que consiste en la integración de sistemas empleados sistemas de información y protocolos no estandar, proporcionando una...») |
|||
| Línea 1: | Línea 1: | ||
| − | " | + | "Propagación de lo propietario" es un antipatron que consiste en la integración de sistemas empleados sistemas de información y protocolos no estandar, proporcionando una vinculación inadecuada y perpetua con dicho sistema no estándar habitualmente propietario. |
| − | Los IDOCS de SAP con sus segmentos son un ejemplo de esto: No son estructuras de datos reconocidas por organismos de estandarización, son un principio de SAP que no se corresponden con conceptos modernos de ingenieria de software como la | + | Los IDOCS de SAP con sus segmentos son un ejemplo de esto: No son estructuras de datos reconocidas por organismos de estandarización, son un principio de SAP que no se corresponden con conceptos modernos de ingenieria de software como la orientación a objetos o el respeto a namespaces con nombres unívocos. |
| − | [[Categoría:Malas prácticas en los proyectos de software]] | + | Por su propia naturaleza añaden deuda técnica a los proyectos de software donde se utilicen, independientemente de los mecanismos que la consultora exponga para justificar su uso, ya sea en formato plano o XML, seguirán siendo elementos no acordes a ningún paradigma intuitivo, global o estandarizado. |
| + | |||
| + | [[Categoría: Malas prácticas en los proyectos de software]] | ||
Revisión del 20:56 2 ene 2021
"Propagación de lo propietario" es un antipatron que consiste en la integración de sistemas empleados sistemas de información y protocolos no estandar, proporcionando una vinculación inadecuada y perpetua con dicho sistema no estándar habitualmente propietario.
Los IDOCS de SAP con sus segmentos son un ejemplo de esto: No son estructuras de datos reconocidas por organismos de estandarización, son un principio de SAP que no se corresponden con conceptos modernos de ingenieria de software como la orientación a objetos o el respeto a namespaces con nombres unívocos.
Por su propia naturaleza añaden deuda técnica a los proyectos de software donde se utilicen, independientemente de los mecanismos que la consultora exponga para justificar su uso, ya sea en formato plano o XML, seguirán siendo elementos no acordes a ningún paradigma intuitivo, global o estandarizado.