Vocabulario software, la jerga de los informáticos

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).

Anuncios

Comenta la entrada

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s