Escrito por Martin Fowler
Traducido por Rafael Vacas
Revisado por Jorge Ferrer
En mis esfuerzos por escribir, desde siempre he querido escribir material sobre validación. Es un tema que conduce a una gran confusión y estaría bien tener una descripción sólida de algunas de las técnicas que funcionan bien. No obstante, la vida está llena de cosas sobre las que redactar, bastantes más de las que el tiempo permite.

Algunas lecturas recientes me hicieron pensar en escribir sobre algunas cuestiones preliminares sobre el tema. Algo común que veo que hace la gente es desarrollar rutinas de validación para objetos. Estas rutinas vienen de distintas formas, pueden estar en el objeto o externo, pueden devolver un booleano o lanzar una excepción para indicar un fallo. Pero una de las cosas en las que creo que cae constantemente la gente es cuando piensa en la validez del objeto de forma independiente del contexto tal como implica el método isValid.

Escrito por Martin Fowler
Traducido por Jorge Ferrer
Revisado por Carmen Vidal
Una interfaz minimalista es un estilo de diseño de APIs que uso comocontraste de una InterfazHumanizada. La idea detrás de un interfaz mínimalista es diseñar una API que permita al cliente hacer todo lo que necesita, pero reduce las capacidades al menor conjunto posible de métodos que permiten hacer el trabajo. (Ver InterfazHumanizada para consultar un buen ejemplo de sus diferencias)

Los argumentos a favor de la InterfazHumanizada se describen en ese artículo, aquí se se presenta una exposición racional de la interfaz
minimalista.

Escrito por Martin Fowler
Traducido por Carmen Vidal
Revisado por Jorge Ferrer

Dando vueltas durante un rato al alboroto acerca de Ruby, he encontrado por casualidad el término 'la interfaz humanizada'. Éste describe parte de la actitud rubística al escribir la interfaz de la clase y también establece un contraste interesante entre dos escuelas de pensamiento en el diseño de APIs (el otro es el InterfazMinimalista).

La esencia de la interfaz humanizada es averiguar qué quiere hacer la gente y diseñar la interfaz de modo que sea realmente fácil hacer el caso común.

El contraste obvio con una interfaz minimalista es que las interfaces humanizadas tienden a ser mucho mayores, y de hecho los diseñadores de interfaces humanizadas no se preocupan demasiado de si la interfaz es grande. Esto no quiere decir que las clases con interfaces humanizadas tienen que ser más grandes en términos de implementación. La funcionalidad fundamental de las dos es a menudo bastante similar.

Escrito por Martin Fowler
Traducido por Jesús Pérez
Revisado por Carmen Vidal

De vez en cuando la gente se pregunta si una especialidad particular puede ser usada de forma incremental: " No se puede hacer (seguridad | diseño de interfaz de usuario| bases de datos | internacionalización | *) con un proyecto ágil porque este aspecto tiene que ser desarrollado realizando un gran diseño inicial".

Cuando se me hace una pregunta como esta, me encuentro perdido porque desconozco esa especialidad. El diseño de aplicaciones es algo de lo que pienso que puedo hablar, pero no sobre diseño seguridad - y mi interrogador bien puede ser un reconocido experto en este campo.

A pesar de mis limitaciones reconocidas en el campo del que se habla, no voy a decir que sólo se puede usar diseño planificado en ese área. Lo que puedo decir es que realmente no sabemos si se puede hacer el diseño incremental en aquella área. He visto bastantes casos en los que la gente ha dicho " no se puede usar el diseño incremental para x " sólo para averiguar que se puede. El diseño de aplicación es de una forma, el diseño de bases de datos es de otra. De esto modo, hasta que la gente pruebe el diseño incremental de un modo serio, no estoy dispuesto a excluirlo.

Parte de la dificultad de evaluar esta pregunta está en que es demasiado fácil hacer el diseño incremental mal. Si se hace el diseño incremental de un forma incontrolada, con alta probabilidad se termina con un lío de diseño - para hacer el trabajo de diseño incremental se necesita algo que haga el diseño convergir al orden. En el articulo "Está el Diseño Muerto" me referí a éstas como prácticas de habilitación. Para el diseño de software, las pruebas, integración continua y refactorizar son las prácticas clave que permiten que el diseño del software converja y evitar la entropía del software. Cuando hablamos de algo más, como el diseño de UI, la cuestión encontrar cuáles son las prácticas de habilitación. Pueden ser similares o inspiradas por las del diseño de software, o pueden ser diferentes. En el diseño de base de datos, por ejemplo, la migración de datos incremental es una práctica de habilitación clave. Hasta que se encuentre un buen conjunto de prácticas de habilitación, el diseño incremental es algo frágil.

Escrito por Martin Fowler
Traducido por Rafael Vacas
Revisado por Ismael Ferrer

Como mis lectores habituales saben, se me conoce por usar metáforas de otras profesiones para razonar acerca del desarrollo de software. En particular, creo que la metáfora de la ingeniería ha hecho mucho daño a nuestra profesión - en cuanto a que ha promovido la noción de separación entre diseño y construcción.

Esta misma cuestión nos surgió en nuestra oficina de Londres en el contexto de la industria textil - una metáfora usada a menudo en los círculos ágiles - particularmente por los Poppendieck.. Así como no me gusta mucho razonar mediante la metáfora de la ingeniería civil, ¿me gustará más la metáfora de la industria textil?.

Pienso que tienen los mismos peligros, pero todo depende de como se haga uso de la metáfora. Hacer comparaciones con otra actividad es útil si te ayuda a formular preguntas, pero es peligroso si lo utilizas para justificar respuestas.