Principios en el desarrollo de software

Los principios en desarrollo de software son ciertas características de diseño de objetos que permiten que el código sea mas expresivo y por ende mas mantenible, hay varios principios, los más conocidos son los principios SOLID, DRY y KISS, en una serie de blogs entraremos mas en detalle en cada uno de ellos, por lo pronto y de forma muy general doy una breve descripción.

SOLID acrónimo de Single Responsability (responsabilidad única), Open-Close (abierto a extensión y cerrado a modificación),  Liskov Substitution (substitución de Liskov), Interface Segregation (segregación de interfaces) y Dependency inversion (inversión de dependencias) estos son principios que aplican de forma directa en el diseño de clases para programación orientada a objetos, como comenté, mas adelante en algún post revisaremos cada uno de estos principios.

DRY acrónimo de Don't Repeat Yourself (No te repitas a ti mismo), este principio es uno de los más publicitados en el medio y su aplicación va desde una clase hasta un sistema completo, pasando por versionamiento de la base de datos y documentación.

KISS acrónimo de Keep It Simple Stupid (mantenlo simple, estúpido) es un principio también muy conocido pero que es muy difícil de aplicar ya que por naturaleza (no le encuentro otra razón) los desarrolladores somos muy perfeccionistas, pero este principio nos dice que hay que mantener las cosas lo más simple posibles y esto es desde el código, hasta el propio producto igual, pasando por la documentación y el proceso de desarrollo de software.

Estos principios son muy usados y mencionados del desarrollo usando metodologías ágiles (de las que escribiremos en algún post posterior) y es que es muy normal que en este tipo de metodologías dada su naturaleza propicien que los desarrolladores se apeguen a este tipo de principios casi de a fuerzas pero de una forma un poco sutil.

Además de estos principios se podrían mencionar también otras características del software que un buen desarrollo debe de cumplir como el hecho de que todo código productivo debe de estar respaldado por un test o prueba unitaria automatizada y ya hablando de los tests también mencionar que estos tests no deben de ser "low class citizens", es decir, estos tests son igual (o tal vez hasta mas) de importantes que el código productivo, otra característica de un buen código es que debe de ser un código limpio siguiendo ciertos lineamientos encaminados mas que nada a que sea entendible y por lo tanto mantenible.

Bueno, pues esperen próximamente posts relacionados a todo esta madre sin sentido que les acabo de decir.

Saludos.