Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Técnicas y herramientas para que la computadora haga más y el programador menos

385 Aufrufe

Veröffentlicht am

Presentación en ECI 2008

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Técnicas y herramientas para que la computadora haga más y el programador menos

  1. 1. Técnicas y Herramientas para que la Computadora haga más y el Programador menos Lic. Hernán A. Wilkinson
  2. 2. Gerente de Desarrollo en Mercap Docente en UBA y UCA
  3. 3. ¿Por qué ese Título? ¿Qué significa? 4
  4. 4. Se nos ocurrieron otros títulos atractivos cómo…
  5. 5. ¡Tips & Tricks de la Programación! 6
  6. 6. ¡El futuro de la programación! 7
  7. 7. ¡La solución a todos sus problemas! 8
  8. 8. Algo más real… Técnicas y Herramientas… 9 Desarrolladas y mejoradas por Mercap
  9. 9. En Mercap desarrollamos Productos (dominio financiero)  Tiempo de vida > 15 años  Muy importante la calidad  Muy importante la funcionalidad diferencial
  10. 10. XTrade  12700 clases  710800 LOC Smalltalk Equivale a 3 mill. Java aprox  ¿Problemas Principales?
  11. 11.  Nuevos Requerimientos Funcionales  Mejoras en el Diseño/Implementación Actual  Rotación de Personal  Peter Naur  Programming as a Theory Building   NO QUEREMOS QUE SEA UN PROBLEMA Evolución de Código
  12. 12. No veremos problemas de Performance Espacio
  13. 13. ¿Qué significa que la “Computadora haga más y el programador menos”? 14
  14. 14. Como programadores… ¿no tienen que hacer tareas…? 15
  15. 15. ¿Repetitivas? 16
  16. 16. ¿Tediosas? 17
  17. 17. ¿Tareas que son siempre lo mismo…? 18
  18. 18. Tareas muy importantes que nunca se hacen por falta de tiempo… 19
  19. 19. ¿Cómo podemos salir de este embrollo? 20
  20. 20. ¡Lograr que la computadora trabaje por nosotros! Para eso están… para hacer el trabajo “automatizable”
  21. 21. ¿Cómo detectamos qué tareas son?
  22. 22. Douglas Hofstadter 23
  23. 23. podemos “salir del sistema” 24 Somos inteligentes porque “reflexionar” sobre él
  24. 24. 25 Konrad Lorenz (nobel 1973)
  25. 25. 26 En su libro “Los ocho pecados mortales de la humanidad civilizada” “si no reflexinamos…” “viviremos una eterna niñez…”
  26. 26. 27 Alan Kay (Turing Award 2003)
  27. 27. 28 Pero debemos hacerlos con “threshold above normal” “no reinventar la rueda pinchada”
  28. 28. 29 ¡Debemos hacerlo conociendo nuestras raíces, nuestra historia! LISP – ¡50 años! Para no cometer los mismos errores, para estar por arriba de la media
  29. 29. Paremos la pelota  ¿Qué tareas puedo automatizar?  ¿Qué tareas son repetitivas, propensas a error, etc?
  30. 30. Qué vamos a ver  Testing Automatizado  Objetos Auto-Defendibles  Automatización de Inspección de Código  Automatización de Excepciones a la regla  Asegurar Calidad en Puntos Críticos  Integrar Código Automáticamente  Migrar Datos (objetos) Automáticamente
  31. 31. Test Driven Development
  32. 32. Seguro que todos lo conocen…
  33. 33. ¡¡¡16100 Tests!!! Corren en 7 minutos aprox
  34. 34. ¿Para qué sirve?  Ayuda a tener confianza sobre los cambios a realizar  Delega en la computadora la verificación de lo que estamos haciendo  Los test son especificaciones de cómo debe funcionar el código
  35. 35. Ayuda a…  Entender el problema a partir de ejemplos concretos  Concentrarse en el problema real  Minimizar Acoplamiento
  36. 36. Vamos a dar unos pasos más…
  37. 37. 38 Objetos Auto Defendibles, Reificación de Código y Automatización de Inspección de Código
  38. 38. Transacción de Compra miCuenta (from) cuentaDelOtro (to)
  39. 39. Transacción de Venta miCuenta (to) cuentaDelOtro (from)
  40. 40. ¿Cómo lo representamos? aTransac anAccount anotherAcc 10 pesos from to amount
  41. 41. ¿Cómo sabemos si la transacción es una compra o venta? ¿Cómo sabemos el “tipo”?
  42. 42. ¿Como sabemos el “tipo”? aTransac aOwnAcc aThirdAcc 10 pesos from to amount aTransac aOwnAcc aThirdAcc 10 pesos from to amount Compra Venta type type
  43. 43. 44 Solución: ¡Usemos un If!
  44. 44. Típica implementación usando If Transaction>>type (fromAccount isThirdAccount and: [toAccount isOwnAccount ]) ifTrue: [^’Sell']. (fromAccount isOwnAccount and: [toAccount isThirdAccount]) ifTrue: [^’Buy'].
  45. 45. ¿Para qué sirve el “tipo”? Transacciones Contador Impresora
  46. 46. 47 journalEntry transaction type = ‘Buy’ ifTrue: [ ^self buyJournalEntry ]. transaction type = ‘Sell’ ifTrue: [ ^self sellJournalEntry ]. voucher transaction type = ‘Buy’ ifTrue: [ ^self buyVoucher]. transaction type = ‘Sell’ ifTrue: [ ^self sellVoucher]. Típico uso del “tipo” con if
  47. 47. ¿Qué pasa si agregamos otro “tipo”? Transferencia
  48. 48. type (fromAccount isThirdAccount and: [toAccount isOwnAccount ]) ifTrue: [^’Sell']. (fromAccount isOwnAccount and: [toAccount isThirdAccount]) ifTrue: [^’Buy']. (fromAccount isOwnAccount and: [toAccount isOwnAccount ]) ifTrue: [^‘Transfer']. Agrego el nuevo caso Típica implementación usando If
  49. 49. voucher transaction type = ‘Buy’ ifTrue: [ ^self buyVoucher]. transaction type = ‘Sell’ ifTrue: [ ^self sellVoucher]. 50 journalEntry transaction type = ‘Buy’ ifTrue: [ ^self buyJournalEntry ]. transaction type = ‘Sell’ ifTrue: [ ^self sellJournalEntry ]. transaction type = ‘Transfer’ ifTrue: [ ^self transferJournalEntry ]. ¡En algún lugar nos vamos a olvidar de agregar el if! Típico uso del “nuevo tipo” con if
  50. 50. ¿Cuál es el Problema del if?  La computadora no decide  ¡Lo hacemos nosotros!  No hay Meta-Información (información sobre las decisiones de diseño)
  51. 51. ¿Qué tal si hacemos que los objetos lo resuelvan? que la computadora haga más… y el programador menos
  52. 52. Modelemos los Tipos de Transacciones TransactionType -accepts: aTransaction -canHandle: aTransaction -typeOf: aTransaction Buy -accepts: aTransaction -canHandle: aTransaction Sell -accepts: aTransaction -canHandle: aTransaction
  53. 53. Implementación usando Objetos Transaction>>type ^TransactionType typeOf: self Transaction>>type (fromAccount isThirdAccount and: [toAccount isOwnAccount ]) ifTrue: [^’Sell']. (fromAccount isOwnAccount and: [toAccount isThirdAccount]) ifTrue: [^’Buy']. Sell>>canHandle: aTrx ^aTrx fromAccount isThirdAccount and: [aTrx toAccount isOwnAccount ] Buy>>canHandle: aTrx ^aTrx fromAccount isOwnAccount and: [aTrx toAccount isThirdAccount ]
  54. 54. Usando el “tipo” con Objetos Buy -accepts: aTransaction -canHandle: aTransaction Sell -accepts: aTransaction -canHandle: aTransaction canHandle: aTransaction canHandle: aTransaction TransactionType -accepts: aTransaction -canHandle: aTransaction -typeOf: aTransaction typeOf: aTransaction ^aSell ^false ^true
  55. 55. 56 journalEntry ^transaction type accept: self Usando el “tipo” con Objetos journalEntry transaction type = ‘Buy’ ifTrue: [ ^self buyJournalEntry ]. transaction type = ‘Sell’ ifTrue: [ ^self sellJournalEntry ]. visitBuy ^self buyJournalEntry visitSell ^self sellJournalEntry
  56. 56. 57 Usando el “tipo” con Objetos journalEntry aTrx type ^aSell aSell accept: self visitSell ^aSellJournalEntry voucher aTrx type ^aSell aBuy accept: self visitBuy ^aBuyVoucher¡Son Visitors!
  57. 57. ¿Qué ganamos?
  58. 58. ¡No hay más If! ¡Los tipos no son Strings, son Objetos!
  59. 59. ¿Qué pasa ahora si agregamos Transferencia? TransactionType -accepts: aTransaction -canHandle: aTransaction -typeOf: aTransaction Buy -accepts: aTransaction -canHandle: aTransaction Sell -accepts: aTransaction -canHandle: aTransaction Transfer -accepts: aTransaction -canHandle: aTransaction
  60. 60. 61 Agregemos Transferencia journalEntry aTrx type ^aTransfer aTransfer accept: self visitTransfer ^aTransferJournalEntry journalEntry aTrx type ^aSell aTransf accept: self visitTransfer ^aTransferVoucher ¿Nos podemos olvidar de implementar visitTransfer?
  61. 61. ¡NO! Lo avisa la Revisión Automática de Código para Visitors
  62. 62. Tests de Visitors
  63. 63. Inspecciones Automáticas de Código  Naming conventions:  Ortografía, Nombre de módulos, Nombre de Clases, etc.  Diseño:  Clases abstractas sin variables de instancia  Arquitectura:  Clases de test en aplicaciones de test, mock objects en aplicaciones de test, inexistencia de referencias desde aplicaciones del modelo a aplicaciones de test, etc.  Implementación:  Comentarios de código según convención, categorización de mensajes, dónde debe estar implementado un mensaje, de dónde se debe enviar un mensaje, etc.
  64. 64. Inspecciones Automáticas de Código  Implementación de Patrones  Correcta implementación de Singleton y Visitor  Ambiente de Desarrollo  Que todos estén usando los mismos directorios, los mismos settings del ambiente, etc.  Uso correcto de Frameworks  SUnit: Recursos que no referencien a tests, que los tests hagan assert, recursos no cíclicos, etc.  Dependecy Injection: Que todas las dependencias sean iniciliazadas correctamente  Code Coverage: Definición correcta de los métodos a excluir  ETC…
  65. 65. Inspecciónes automática de Código  Evita errores comúnes  Ayuda a mantener consistente el modelo  Controla los errores de programadores nuevos  Asegura calidad de código
  66. 66. Lo importante  Automatizar la auditoría de todas las desiciones que se tomen Diseño Implementación Arquitectura Nomenclatura Uso de otros modelos Etc…  340 chequeos
  67. 67. Implementación de typeOf: Transaction>>type ^TransactionType typeOf: self TransactionType >>typeOf: aTransaction ^self subclasses detect: [ :aClass | aClass canHandle: aTransaction ] Reflexionemos un poco…
  68. 68. Reflexionemos un poco… typeOf: aTransaction ^self subclasses detect: [ :aClass | aClass canHandle: aTransaction ] typeOf: aTransaction | posibleTypes | posibleTypes := self subclasses select: [ :aClass | aClass canHandle: aTransaction ]. posibleTypes isEmpty ifTrue: [ self error: ‘Error de programación’ ]. ^posibleTypes first  ¿Qué pasa si más de un tipo corresponde a la transacción?  ¿Qué pasa si ningún tipo corresponde a la transacción? posibleTypes size >1 ifTrue: [ self error: ‘Error de programación ].
  69. 69. Self Defense Objects Los objetos se aseguran de ser utilizados correctamente
  70. 70. Reflexionemos un poco más… ¿Hay que escribir siempre lo mismo? ¿No es el mismo problema? ¿Necesitaremos hacer esto para otros casos? typeOf: aTransaction | posibleTypes | posibleTypes := self subclasses select: [ :aClass | aClass canHandle: aTransaction ]. posibleTypes isEmpty ifTrue: [ self error: ‘Error de programación’ ]. posibleTypes size >1 ifTrue: [ self error: ‘Error de programación ]. ^posibleTypes first for: aTransaction
  71. 71. ¡Reificar el código! typeOf: aTransaction | posibleTypes | posibleTypes := self subclasses select: [ :aClass | aClass canHandle: aTransaction ]. posibleTypes isEmpty ifTrue: [ self error: ‘Error de programación’ ]. posibleTypes size >1 ifTrue: [ self error: ‘Error de programación ]. ^posibleTypes first for: aTransaction SuitableClassSelector -value -for: aSuperClass
  72. 72. Reflexionemos un poco más… typeOf: aTransaction ^(SuitableClassSelector for: self) value for: aTransaction typeOf: aMovie ^(SuitableClassSelector for: self) value for: aMovie typeOf: aCar ^(SuitableClassSelector for: self) value for: aCar TransactionType: MovieType: CarType: etc…
  73. 73. Usando el “tipo” con Objetos Buy -accepts: aTransaction -canHandle: aTransaction Sell -accepts: aTransaction -canHandle: aTransaction aSuitable Class Finder value aTransaction (sell) canHandle: aTransaction canHandle: aTransaction ^Sell TransactionType -accepts: aTransaction -canHandle: aTransaction -typeOf: aTransaction typeOf: aTransaction ^aSell Transfer -accepts: aTransaction -canHandle: aTransaction canHandle: aTransaction ^false ^true ^false
  74. 74. ¿Qué logramos?  Creamos una nueva construcción “sintáctica”  No puede haber “errores” al agregar nuevos casos puesto que la computadora se encarga de verificarlo  Son objetos (meta), no texto. Podemos ver:  Donde se usa  Cuanto casos hay  Testearlo una sola vez  Etc.
  75. 75. Recapitulemos  TDD  Self Defense Objects  Reificación de Construciones Sintácticas  Inspección Automática de Código
  76. 76. Automatizar las Excepciones a las Reglas de Validación de Código
  77. 77. Falsos Positivos isEmpty ^self size = 0 Warning: No se debe usar “size = 0” sino “isEmpty” ¡Pero se está implementando “isEmpty”! Se marca como “error esperado” y se puede seguir usando la herramienta
  78. 78. Ejemplo (modelo open source) expectedSmallLintFailures ^Array with: ( MCPExpectedSmallLintFailure unoptimizedToDoFailedClass: self failedMethod: 'initializeConnectors' asSymbol reasonDescription: 'No funciona bien con el #to:do: optimizado, ver comentarios en el metodo' definedBy: 'diegof') expectedSmallLintFailures ^Array with: ( MCPExpectedSmallLintFailure utilityMethodsFailedClass: self failedMethod: #factorForSameYearFrom:to: reasonDescription: 'Por factorizacion‘ definedBy: 'hernan') Hay un test que verifica que el usuario es válido!
  79. 79. ¿Qué ganamos?  Evitar Falsos Positivos constantes que desalientan el uso de la automatización de inspección de código  Se debe asegurar que no haya “errores esperados” que no aplican
  80. 80. Asegurar Calidad en Puntos Críticos
  81. 81. ¿Cómo?  Asegurar 100% de cobertura de test  Asegurar que no hayan “errores”
  82. 82. Módulo Estable Módulo Estable Depende de Depende de Módulo Estable Módulo Estable ¡100 % de Cobertura! ¡No hay errores! Módulo No Estable Módulo No Estable
  83. 83. ¿Qué ganamos?  Test que aseguran que los modulos estables tienen un 100 % de cobertura  No hay errores (detectables automáticamente)  Aseguramos calidad para los módulos core  Delegar en la computadora dicha verificación
  84. 84. Integración de Código
  85. 85. Integración Manual
  86. 86. ¡Integración Automática! Ejemplo
  87. 87. ¿Qué ganamos?  Proceso automático No hay posibilidad de error Es más rápido que hacerlo manualmente  Pasamos de estas varios días integrando a hacerlo en menos de media hora
  88. 88. ¿Qué pasa con los refactorings? ClassA ClassB m1 ^ClassA new Renombra Error de Integración Tesis de Diego Tubello para integrar refactorings automáticamente Linea Base Linea A Linea B
  89. 89. Migración de Datos
  90. 90. Versión inicial de Stock Stock (versión 1) acindar ‘acindar’ name
  91. 91. Segunda Versión de Stock Stock (versión 1) acindar ‘acindar’ name Stock (versión 2) acindar ‘acindar’ name dollar issueCurrency
  92. 92. ¿Por qué hay que migrar datos?  ¿Por qué cambia el tipo de un campo?  ¿Por qué cambia la estructura de una tabla?  ¿Por qué se agregan nuevas tablas?  ¡¡POR QUE EVOLUCIONA EL CÓDIGO!!   Migrar código y datos!
  93. 93. Migración de Objetos (en vez de migración de datos)
  94. 94. No sería bueno una herramienta que…  Nos avise cuando agregamos/sacamos una variable de instancia?  Nos diga cuando cambia una jerarquía?  Modifique el código de una nueva versión?  ¿No sería bueno que la computadora se encarge de resolver este problema?
  95. 95. ¿Para qué? Única línea de Producto
  96. 96. ¿Qúe ganamos?  Cambio automatizado de versiones  Nos permite tener una única línea de productos  Permite que los clientes tengan la última versión
  97. 97. 98 ¡Conclusiones!
  98. 98. 99 Camino recorrido  Testing automatizado  Código auto defendible  Inspecciones automátizadas  Reificación de Código  Excepciones a la regla  Asegurar la calidad de puntos críticos  Integración de Código  Migración de Objetos
  99. 99. 100 Porque en Mercap tenemos… ¿Por qué lo logramos?
  100. 100. 101 Podemos “Salir del Sistema” y Reflexionar (como dice Hofstadter)
  101. 101. 102 Se generó un ambiente “adulto” gracias al “Feedback” (como propone Lorenz)
  102. 102. 103 Porque usamos Herramientas estables, maduras que permiten hacer Meta-programación (como propone Alan Kay)
  103. 103. Ideas de Tesis…  Change Model para Objetos  Mejor modelo de Migración de Objetos  Interfaz de Usuario declarativa  …además de las que ya se están haciendo cómo Refactorings de Traits SmallLint para Traits Reificación de Meta-Ejecución
  104. 104.  13-15 Noviembre  Gratis!  M. Oca 745 - UAI
  105. 105. Queremos agredecer a la competencia de esta charla…
  106. 106. Una lástima no haber consegido los sponsors… 
  107. 107. 108 Preguntas y Comentarios Email: hernan.wilkinson@mercapsoftware.com blog: http://objectmodels.blogspot.com/
  108. 108. 109

×