La navaja de Occam, KISS y YAGNI: la simplicidad en el código no debería ser sólo postureo developer

La navaja de Occam, KISS y YAGNI: la simplicidad en el código no debería ser sólo postureo developer
Sin comentarios Facebook Twitter Flipboard E-mail

La simplicidad en cualquier diseño de software es un atributo deseable. Aunque muchas veces nos pueda sonar a postureo developer, seguir los principios de diseño nos pueden libran de muchos quebraderos de cabeza por implementar sistemas innecesariamente complejos.

Es importante recordar los principios de diseño de software que abordan la importancia de la simplicidad como KISS, YAGNI o la navaja de Occam.

KISS

KISS significa “Keep It Simple, Stupid” (Mantenlo simple, estupido) . Es uno de los principios más antiguos de diseño de software, aunque lo olvidamos a menudo.

Los sistemas más eficaces son los que mantienen la simplicidad, evitando la complejidad innecesaria. El objetivo es que el diseño del software sea lo más simple posible.

Los desarrolladores somos humanos, por lo que tenemos capacidades limitadas. Tanto a la hora de escribir código como de depurarlo, aún más cuando nos enfrentamos a código complejo sin motivo.

YAGNI

YAGNI significa “You Aren't Gonna Need It” (No vas a necesitarlo) Es uno de los principios del Extreme Programming que indica que un programador no debe agregar funcionalidades extras hasta que no sea necesario.

"Aplicar siempre las cosas cuando realmente los necesita, no cuando lo que prevén que los necesita." - Ron Jeffries

La relación con el principio de “Last Responsible Moment” es clara, ya que nos debemos basar en hechos y no en suposiciones. Así evitamos sobre diseñar sistemas, una tendencia que retrasa y entorpece el alcance inicial de la tarea que estamos desarrollando.

Navaja de Occam

La Navaja de Occam se remonta a un principio metodológico y filosófico, perfectamente aplicable al desarrollo de software, según el cual, “en igualdad de condiciones, la explicación más sencilla suele ser la correcta”.

Este principio lo podemos usar tanto en el momento de implementar una solución como a la hora de encontrar el causante a un bug. ¿Cuántas veces nos habrá pasado que la metedura de pata más tonta es la causante del problema aunque hayamos estado comprobando lo más complejo?

Simple no significa ignorar la complejidad real

Cada vez que se habla de simplicidad se cae en la trampa del exceso de simplicidad. Los principios anteriormente expuestos no significan que tengamos que ignorar la complejidad de los hechos reales. Un diseño de software simple es el que se centra en los requisitos actuales, pero no olvida necesidad futuras como la mantenibilidad, extensibilidad o la reutilización. Al fin y al cabo, los diseños que buscan la simplicidad del código son más fáciles de adaptar a la necesidades futuras que los complejos.

¿Cuál es vuestra experiencia con los desarrollos de software que se vuelven cada vez más complejos e imposibles de manejar?

Comentarios cerrados
Inicio