Valores y principios en el desarrollo de software. Hoy, principios.

Manu Pijierro
3 min readJan 21, 2018

--

En la anterior entrada del blog, hace varias semanas, escribía sobre los valores en el desarrollo de software enumerados por Kent Beck en su libro Implementation Patterns. Estos valores son: comunicación, simplicidad o flexibilidad. Los valores son definidos como conceptos o ideas más generales.

Los principios son otro nivel de ideas generales pero más específicas de la programación con los que se pueden explicar y comprender las motivaciones reales que se ‘esconden’ detrás de los patrones de implementación desarrollados en su libro. Los principios, además, ayudan a trasladar los valores en acción.

Los principios enumerados por Kent Beck son los siguientes:

Consecuencias locales

Las modificaciones de un código debería tener consecuencias locales, es decir, acotadas a su contexto. Si cambiar un código en un lugar concreto de nuestra aplicación tiene consecuencias en otras partes no esperadas, el coste de dicho cambio se eleva dramáticamente. Mantener un coste bajo en el mantenimiento y modificaciones del código es una de las principales motivaciones que se esconden detrás de los patrones explicados por Kent Beck. Así que, mientras más acotados, controlados y conocidos sean los cambios del código y sobre todo las consecuencias de los mismos, menor coste de desarrollo.

Minimizar las repeticiones

Un principio que nos ayuda a mantener consecuencias locales es precisamente minimizar la repetición del código. Cuando tenemos el mismo código en varios lugares, si cambias una copia del mismo, deberemos decidir si cambiar el resto de las copias. En este caso, el cambio no tiene un alcance local.

El código duplicado o jerarquías de clases similares son formas de repetición, pero estas repeticiones no siempre son inmediatas de apreciar hasta que son creadas. Como dice Kent Beck en el libro, la duplicación no es el ‘demonio’ pero si puede incrementar el coste del cambio.

Una de las formas de romper la duplicación es construir nuestras aplicaciones con partes muy pequeñas de código fácilmente reutilizables.

Mantener la lógica y los datos juntos

Otro principio corolario para conseguir consecuencias locales es mantener la lógica de nuestra aplicación y los datos con los que opera juntos, en la misma función si es posible o en el mismo objeto o yendo un poco más allá en el mismo paquete.

A la hora de implementar una modificación, será mucho mejor tener la lógica y los datos juntos para así hacer el cambio de una sola vez en un lugar acotado manteniendo las consecuencias locales.

Simetría

Identificar y expresar la simetría de una forma clara hace que el código sea más fácil de leer ya que una vez que hemos comprendido una parte del código, podemos imaginarnos y comprender rápidamente la otra parte. Esto se puede expresar por ejemplo, en el uso correcto de procesos que hacen una cosa y su contraria, o bien, manteniendo un número simétrico de parámetros, orden, tipo, etc., en las firmas de los métodos. La idea es que el código sea expresado de la misma forma en toda la aplicación para que su comprensión nos resulte más sencilla.

Expresión declarativa

Otro de los principios detrás de los patrones de implementación de Kent Beck consiste en expresar nuestro código con la mayor intención posible. A diferencia de la programación imperativa, la programación declarativa apuesta por un código más expresivo, en el que se declaren las intenciones de lo que se quiere hacer y no como se va a hacer además de mantener unos niveles de abstracción adecuados y coherentes a todos los niveles (clases, métodos…etc).

Ratio de cambio

Referido a cambios en el tiempo. Este principio final consiste en poner la lógica o los datos que cambian en el tiempo y al mismo tiempo, valga la redundancia, lo más juntos posibles. En este caso, estamos hablando de una forma de simetría temporal. Por ejemplo, los atributos de un objeto deberían cambiar todos más o menos al mismo tiempo, en caso contrario, habría que analizar si esos atributos que se actualizan con distinto ratio pudieran pertenecer a otro objeto nuevo o existente.

Chimpún.

Bibliografía

Implementation Patterns, Kent Beck.

Programación declarativa, Wikipedia

Programación imperativa, Wikipedia

--

--