Antipatrones de Software

1,196 views
1,069 views

Published on

Esta presentación recorre una serie de falacias comunes respecto al desarrollo de software y una serie de antipatrones clásicos.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,196
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
11
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • Antipatrones de Diseño
    Deuda Técnica
    OOD / SOLID
    Testing
  • 1994
  • LAN (más o menos)
    WAN (poco – mejor distribuir)
    Integración ENTRE redes
    Internet !!!
    Ser ROBUSTO ante las FALLAS
    - En general, programar defensivamente
    - En particular, tener alternativas a la desconexión
    - Pensar más allá del LOG en el TRY/CATCH de las transacciones a la DB
    Definir claramente las METAS de RENDIMIENTO y ESCALABILIDAD
    - Cuidado con soluciones mágicas: el efecto CACHE (locks)
    - Problemas de RENDIMIENTO que realmente son de ESCALA
    Usualmente los modelos de trabajo remoto SUPONEN que la red funciona 7x24
    - Si no está, los CLIENTES NO FUNCIONAN
    Los clientes tampoco están siempre en línea (hay lugares donde NO HAY RED!)
    - Soporte online / offline
    - TRY/CATCH - Reintentos, colas, archivos temporales, DB locales, etc
    - Infraestructura de MENSAJERIA CONFIABLE
  • Transmitir datos TOMA TIEMPO
    LATENCIA variable en distintos escenarios (INTERNET)
    Latencia EN DESARROLLO
    En producción: Clientes con DIAL-UP !!!
    MINIMIZAR la transferencia
    en la presentación – HTML cuidadoso
    en las comunicaciones – DTOs – Mensajes – Servicios
  • Cada vez tenemos más, cada vez DERROCHAMOS mas.
    No importa el caño, NO SOMOS LOS UNICOS (Kazaa y el BitTorrent)
    Si en nuestra punta tenemos T1, el cliente puede tener DIAL-UP
    A veces, un cliente más sofisticado responde mejor:
    - Smart/Fat clients (Updater App Block / ClickOnce)
    - AJAX (pros y contras)
  • Sabemos que no, pero PREPARAMOS NUESTRAS APLICACIONES para esto?
    La seguridad es un PROCESO, NO un PRODUCTO
    Si cree que la tecnología le va a solucionar los problemas, no entiende ni la tecnología ni los problemas. (Bruce Schneier, Secret and Lies)
    Alcanza el Firewall?
    - Meterse en el medio (dentro de la DMZ)
    - No dejar lógica de dominio suelta (en las páginas, por ejemplo!)
    - SIEMPRE validar los ingresos del usuario
    - SQL Injection
    Qué pasa DENTRO del Firewall?
    - Ingeniería social
    - Ataques a la DB (Oracle y SQL defaults scott/tiger – sa/ )
    OWASP.ORG – Writing Secure Code
    Transporte:
    - Si le confiamos la seguridad (HTTPS) perdemos independencia
    - CIA (confidencialidad/integridad/autenticidad) a nivel de los mensajes
    XML Encryption - WS-Security - Crypto APIs de las plataformas (sobre estándares, por favor … ) - System.Security.Cryptography
  • Leslie Lamport:
    “Sistemas distribuidos: sabés que tenés uno cuando al caerse una computadora de la que nunca habías oído no podés trabajar con NADA”
    Lo único seguro es el CAMBIO
    Nuestra pequeña red puede parecer inmutable – y entonces la compañía se FUSIONA.
    Los servidores cambian, se separan o consolidan.
    NO ASUMIR ninguna distribución física.
    NO ACOTARSE a requerimientos MUY ESPECIFICOS de hardware o distribución.
    Seguir el ejemplo de las URL:
    Ubicación transparente
    Migración y reubicación transparente
    Transparencia de replicación
    Ser CONFIGURABLES lo más granularmente posible.
  • Nuevamente, cuando suponemos que estamos en un ambiente estable…
    La empresa se FUSIONA,
    el personal de IT CAMBIA,
    nuestro sistema comienza a ser usado por un SOCIO…
    Debemos tener en cuenta siempre
    Administración (al menos XML ó INI, idealmente cierta UI)
    Instalación y puesta en marcha (idealmente automatizada, al menos parte automática y parte documentada)
    Monitoreo (mínimamente LOGs o eventos, idealmente integración con MOM u otros estándares)
    Ni siquiera la DB nos pertenece de por vida. Si hoy somos los DBA, mañana podemos perder control.
    Preferiblemente, no acoplarse a la estructura en forma directa
    DAL – ORM
    No asumamos ports que deben estar abiertos. El caso para HTTP – port 80 rules!
    Los usuarios NO deben ser PROPIETARIOS dentro del sistema, pero si deben estar ABSTRAIDOS.
    La pesadilla del single-sign-on – algunos usuarios ni siquiera son humanos
    Multitud de autorizaciones: AD – Kerberos – Passport – LDAP – inventados… WS-Trust – Múltiples credenciales por mensaje
  • La pesadilla de los OBJETOS REMOTOS.
    El costo del marshaling y la falacia de mover OOP a un ambiente distribuido como si nada.
    Una llamada a una función es unas 1000 veces más costosa SOBRE EL LOOPBACK de nuestra máquina.
    Remoting o Web Services sobre TCP (WSE 2+) ayudan, pero no resuelven el problema.
    La fábula de la torta.
    Pasando datos en tandas – Mensajes - Servicios
  • Aceptémoslo: .NET, JAVA, COBOL, Perl, C++, PHP, Ruby/Rails, etc, y UNIX/Linux, Mainframes, etc.
    Ni hablar a nivel HARDWARE.
    El costo de la neutralidad tecnológica.
    ¿Podemos elegir una plataforma (o una gama) pero interoperar?
    Lo importante son los estándares de integración.
    Mantener fachadas de uso grueso (SERVICIOS) para los bloques funcionales más importantes,
    y capas más granulares (pero lo más gruesas posibles) para las piezas variables (DBs, dispositivos, aún servicios del OS)
    Soportarse sobre (o tolerar) estándares:
    XML principalmente, SOAP y WS-*
    Los problemas de la interoperabilidad:
    La Tierra no es plana
    Los formatos binarios pueden ser SIMILARES pero NO IDENTICOS
    Los sistemas de tipos NO COINCIDEN
    Los objetos no serializan del todo bien en XML (la diferencia de impedancia entre objetos y jerarquías)
    NO ENVIAR OBJETOS, SINO XML (MENSAJES AGAIN) - Headers y contenido
    Transporte: DIVERSIDAD – HTTP TCP – SMTP/POP3 – MSMQ – JMS…
    Sincrónicos o no, write/only, suscripción, broadcast, temas de seguridad
    NO ATARSE a un transporte
    Construir mensajes que puedan usarse sobre cualquiera - Iinformación de ruteo en el mensaje mismo - WS-Addressing - INDIGO
  • Ocurre en muchos de nuestros sistemas chicos, HASTA QUE CRECEN.
    Si somos exitosos, DEBERIA pasar.
    Cada día necesitamos más y más INTEGRARNOS con otros sistemas
    Cambios ó diversidad en la Interfaz de Usuario
    Cambios ó diversidad en la DB
    Cambios ó diversidad en la lógica de dominio
    ó infraestructura
    ó canal de comunicaciones
    N-Tier más que nunca
    Diferencias capas físicas (tiers) de capas lógicas (layers)
    Importancia de versionado, instalación y actualización POR COMPONENTE
    Modelos desconectados – Granularidad gruesa
    SOA – XML Services (adiós al prefijo Web)
  • ¿Cuándo está terminado un sistema?
    Entorno cambiante
    Empresa cambiante
    Reglas de juego cambiantes
    Siempre hay nuevos requerimientos y extensiones
    Por eso también cambia la TOPOLOGIA
    Manteniéndose AGIL
    CONFIGURABLE
    DESACOPLADO
    tan INDEPENDIENTE de las PLATAFORMAS como sea posible
    DODUMENTACION DINAMICA (no estática)
    REFACTORING
  • LOGICA DE NEGOCIOS es un término nebuloso
    A CONTRAPELO de lo que venimos pregonando por años, pero… ¿real?
    El ejemplo del largo del campo que cambia
    DB – UI – reglas
    El ejemplo de las condiciones de descuento
    DB – UI – reglas - parámetros
    El rol de la metadata, sus complicaciones – OCL (Object Constrain Language – no se usa mucho en la práctica)
    La confusión puede ser con el “Una y sólo una vez”, que originalmente no implicaba ubicación.
    ABIERTO A DISCUSION
  • El software evoluciona;hagámoslo más apto si queremos que sobreviva.
  • Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation
  • Antipatrones de Software

    1. 1. Teach Yourself C++ in 21 Days
    2. 2. FFaallaacciiaass yy AAnnttiippaattrroonneess MMaarrttíínn SSaallííaass
    3. 3. LLaass 77 ffaallaacciiaass ddee llaa ccoommppuuttaacciióónn ddiissttrriibbuuiiddaa EEsseenncciiaallmmeennttee ttooddooss,, aall ccoonnssttrruuiirr ssuu pprriimmeerr aapplliiccaacciióónn ddiissttrriibbuuiiddaa,, hhaacceenn llaass ssiigguuiieenntteess ssiieettee pprreessuunncciioonneess.. TTooddaass rreessuullttaann sseerr ffaallssaass aa llaarrggoo ppllaazzoo,, yy ttooddaass ccaauussaann ggrraannddeess pprroobblleemmaass yy ddoolloorroossaass eexxppeerriieenncciiaass ddee aapprreennddiizzaajjee.. PPeetteerr DDeeuuttsscchh
    4. 4. 11.. LLaa rreedd eess ccoonnffiiaabbllee
    5. 5. 22.. LLaa llaatteenncciiaa eess cceerroo
    6. 6. 33.. EEll aanncchhoo ddee bbaannddaa eess iinnffiinniittoo
    7. 7. 44.. LLaa rreedd eess sseegguurraa
    8. 8. 55.. LLaa ttooppoollooggííaa nnoo ccaammbbiiaa
    9. 9. 66.. HHaayy uunn ssoolloo AAddmmiinniissttrraaddoorr
    10. 10. 77.. EEll ccoossttoo ddee ttrraannssppoorrttee eess cceerroo
    11. 11. 88.. LLaa rreedd eess hhoommooggéénneeaa ((GGoosslliinngg))
    12. 12. 99.. EEll ssiisstteemmaa eess mmoonnoollííttiiccoo ((NNeewwaarrdd))
    13. 13. 1100.. EEll ssiisstteemmaa eessttáá tteerrmmiinnaaddoo ((NNeewwaarrdd))
    14. 14. 1111?? LLaa llóóggiiccaa ddee nneeggoocciiooss ppuueeddee ––yy ddeebbee–– sseerr cceennttrraalliizzaaddaa ((NNeewwaarrdd))
    15. 15. CCoorroollaarriioo
    16. 16. MMeettooddoollooggííaa • CCooppyy aanndd ppaassttee pprrooggrraammmmiinngg • GGoollddeenn hhaammmmeerr // SSiillvveerr BBuulllleett • IImmpprroobbaabbiilliittyy ffaaccttoorr • PPrreemmaattuurree ooppttiimmiizzaattiioonn • PPrrooggrraammmmiinngg bbyy ppeerrmmuuttaattiioonn • RReeiinnvveennttiinngg tthhee wwhheeeell // RReeiinnvveennttiinngg tthhee ssqquuaarree wwhheeeell • TTeesstteerr DDrriivveenn DDeevveellooppmmeenntt
    17. 17. PPrrooggrraammaacciióónn • AAcccciiddeennttaall ccoommpplleexxiittyy • AAccttiioonn aatt aa ddiissttaannccee • BBlliinndd ffaaiitthh • BBooaatt aanncchhoorr // LLaavvaa ffllooww • BBuussyy ssppiinn • CCaacchhiinngg ffaaiilluurree • CCaarrggoo ccuulltt pprrooggrraammmmiinngg • CCooddiinngg bbyy eexxcceeppttiioonn • EErrrroorr hhiiddiinngg • HHaarrdd ccooddee • LLoooopp--sswwiittcchh sseeqquueennccee • MMaaggiicc nnuummbbeerrss // ssttrriinnggss • SSoofftt ccooddee • SSppaagghheettttii ccooddee
    18. 18. DDiisseeññoo • BBiigg bbaallll ooff mmuudd • DDaattaabbaassee--aass--IIPPCC • GGoolldd ppllaattiinngg • IInnnneerr--ppllaattffoorrmm eeffffeecctt • IInnppuutt kklluuddggee • IInntteerrffaaccee bbllooaatt • MMaaggiicc ppuusshhbbuuttttoonn • RRaaccee hhaazzaarrdd • SSttoovveeppiippee ssyysstteemm
    19. 19. OOrriieennttaacciióónn aa OObbjjeettooss
    20. 20. BBiibblliiooggrraaffííaa mmaarrttiinn@@ssaalliiaass..ccoomm..aarr bblloogg..ssaalliiaass..ccoomm..aarr @@MMaarrttiinnSSaalliiaass

    ×