Este post es una traducción de: http://www.javacodegeeks.com/2012/12/agile-software-developer-terminology-for-new-programmers.html
Muchas veces cuando estamos leyendo un artículo técnico las siglas y la jerga se ponen un poco cuesta arriba. Sobre todo al principio cuando no se es muy ducho en la materia (como yo) siglas como DRY (que no es lo mismo que DRY), YAGNI,.. nos suenan un poco raro. Traduzco el post porque me parece interesante tener un pequeño diccionario con todos estos términos.
YAGNI
You Are Not Going To Need It – No vas a necesitarlo
Consiste en que no se debe nunca agregar funcionalidad excepto que sea necesario. La tentación de escribir código que no es necesario, pero que puede serlo en un futuro tiene las desventajas.
| Siglas | Descripción |
| DRY
Don’t Repeat Yourself – No te repitas |
Según este principio toda pieza de información nunca debería ser duplicada debido a que la duplicación incrementa la dificultad en los cambios y evolución posterior, puede perjudicar la claridad y crear un espacio para posibles inconsistencias. Por ejemplo, copiar y pegar código en las pruebas unitarias. |
| KISS
Keep It Simple Silly [or Stupid] – Mantenlo simple estúpido |
Escribir el código solo para resolver el problema de la manera menos complicada. Véase a “navaja de Occam” |
| WET
Write Every Time – Escribir todo mil veces |
La antítesis de DRY, el código se repite mucho en diferentes clases, paquetes y funciones.Antídoto: Pruebas unitarias y refactorización. |
| WETTT
Write Everything Ten Thousand Times Escribir todo mil veces |
Es el superlativo de WET |
| R3
Rules of Three – Regla de tres |
Relacionado con DRY y WET. Cuando se tienen tres partes del código duplicadas en un función o en un método es hora de refactorizra.Normalmente pasa porque hay presión con el tiempo o porque el Scrum Master dice, no hagas eso en este sprint. |
| DBC
Design By Contract- Diseño por contratos |
La idea es construir un servicio basado en un primer contrato. Por ejemplo en Java escribiremos la interfaz más sencilla posible y después implementaremos la clase que implementa dicha interfaz. Es más fácil refactorizar si se tienen claras las interfaces. Por ejemplo tenemos la interfaz JDBC y muchísimas implementaciones diferentes. |
| BDUF O BUDF
Big Up-Front Design |
Es un problema sobre todo de las grandes instituciones en las que se necesita un documento de 100 páginas de requisitos de negocio antes de la construcción de software, sólo para que el equipo de desarrollo tenga un documento prácticamente inútil. |
| PINK BOOK | Es un libro con la cubierta rosa sobre desarrollo ágil algo antiguo llamado Extreme Programming Installed by Ron Hendries et AlI |
| YOLO
You Only Load It Once [If Ever]- Solo se carga una vez |
El principio YOLO dice que al cargar los datos iniciales de configuración en el servidor no se necesitan diseños de E/S complejos, ya que solo se carga una vez. |
| SPIKE | En la metodología XP es un espacio de tiempo en el que se desarrolla un prototipo para resolver cuestiones técnicas, explorar soluciones y/o eliminar la incertidumbre.Antes de comprometerse es bueno testear una tecnología, por ello se define un tiempo de estudio y prototipado en esta metodología. |
| TDD
Test Driven Development – Desarrollo guiado por pruebas |
Es una técnica de desarrollo en la que se insta a escribir primero los tests antes que el código. Se basa en 5 pilares: Escribir la prueba, escribir el código para que pase la prueba, ejecutar pruebas automáticas, refactorizar y repetir.Para aprender esta técnica recomiendo el libro de Carlo Blé “Diseño ágil con TDD” |
| TFD
Test First Development |
Muy parecida a la anterior |
| VELOCITY
Velocidad del equipo |
Una medida muy básica sobre el retorno de la inversión para el desarrollo de software SCRUM y no tiene nada que ver con los presupuestos financieros y reporting. Velocity es el número de puntos de la historia completados por equipo por iteración. |
| STORY POINT
Puntos de Historia |
En metodología SCRUM corresponde a lo “difícil” que puede ser implementar un sprint o una tarea. Cada equipo tiene su definición.Un manera de signar puntos de historia puede ser mediante “planning póker” |
| DTSTTCPW
Do The Simplest Thing That Could Possibly Work – Es la cosa más simple que podría funcionar |
Está relacionado con spike y KISS y significa que hay que utilizar siempre la cosa más fácil que puede funcionar. |
| UNIT TEST
Test unitario |
Una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. En Java se utiliza JUnit.Es importante recordar que una prueba válida una parte de una función. |
| FUNCTIONAL TEST | Es una prueba basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software. |
| ACCEPTANCE TEST | La prueba de aceptación es realizada por un grupo de usuarios finales o los clientes del sistema, para asegurarse que el sistema desarrollado cumple sus requisitos. |
| SOLID
Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation and Dependency Inversion. |
Principios que cuando se aplican en conjunto es más probable que un desarrollador cree un sistema que sea fácil de mantener y ampliar en el tiempo |
| SINGLE RESPONSABILITY PRINCIPLE
Única responsabilidad |
la noción de que un objeto solo debería tener una única responsabilidad. |
| OPEN CLOSE PRINCIPLE | la noción de que las “entidades de software … deben estar abiertas para su extensión, pero cerradas para su modificación”. |
| LISKOV SUBSTITUTION PRINCIPLE | la noción de que los “objetos de un programa deberían ser reemplazables por instancias de sus subtipos sin alterar el correcto funcionamiento del programa” |
| DEPENDENE INVERSION PRINCIPLE | la noción de que uno debería “Depender de Abstracciones. No depender de concreciones.” |
| XP
eXtreme Programming – Programación Extrema |
Es una metodología de desarrollo que pone más énfasis en la adaptabilidad que en la previsibilidad. Se basa en estos valores: simplicidad, comunicación, feedback, valentía, respeto |
| BROOKS LAWS | es un principio utilizado en el desarrollo de software que afirma que «añadir más efectivos a un proyecto de software en retraso, lo retrasará más» |
| DESING PATTERN | Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. |
Seguro que hay muchos más términos, de aquí http://es.wikipedia.org/wiki/Anexo:Filosof%C3%ADas_del_desarrollo_de_software he recogido algunas definiciones, otras las he traducido del artículo original.
Estaría bien añadir muchos más términos, o modificar aluna errata (que seguro que las hay).
Jesús L.C. - Apuntes de un aprendiz 