Anatoly Alexei Pedemonte Ku:::…

He aquí algunos simples principios básicos, para un desarrollador de  software, algo que encontré por la web hace bastante tiempo y lo pongo a disposición para todos mis colegas

No repitas

Posiblemente el principio por excelencia, no se debe duplicar información ya que la duplicación incrementa la dificultad de cambios y su posterior evolución.

Regla del noventa-noventa

“El primer 90% del código ocupa el 90% del tiempo de desarrollo. El 10% restante del código ocupa el otro 90% de tiempo de desarrollo.”

También se puede enunciar como: el tiempo que falta para acabar el proyecto es constante.

La regla del noventa-noventa es una instancia del Principio de Pareto.

Principio de Hanlon

* Nunca le atribuya a la maldad lo que puede ser explicado por la estupidez
* Nunca le atribuya a estupidez lo que pueda explicarse adecuadamente mediante la ineptitud
* Nunca le atribuya a ineptitud lo que pueda explicarse adecuadamente mediante el desconocimiento

Peor es mejor

Peor es mejor es una técnica de desarrollo de software y a la vez un principio, en la cual la simplicidad en la interfaz y en la implementación es más importante que cualquier otra propiedad del sistema (incluyendo corrección, consistencia y nivel de finalización).

Principio KISS

El principio KISS es aquel que recomienda el desarrollo empleando partes sencillas, comprensibles y con errores de fácil detección y corrección, rechazando lo enrevesado e innecesario en el desarrollo de sistemas complejos en ingeniería. KISS es un acrónimo de la frase en inglés “Mantenlo simple, estúpido” (Keep It Simple, Stupid).

Gran bola de lodo

En programación, “gran bola de lodo” es un término aplicable a un sistema de ordenador sin una arquitectura realmente discernible.

Una Gran bola de lodo es una selva de código enrevesado, dificultoso, caóticamente estructurado, que crece descontroladamente, que se mantiene como unido a base de cuerda y cinta aislante. Este tipo de sistemas presentan signos inconfundibles de crecimiento incontrolado y constantes necesidades de reparación. Elementos lejanos en el sistema comparten información profusamente, incluso hasta el punto de que prácticamente cualquier información importante se trata de manera global o se duplica. La estructura global del sistema puede no haber llegado a estar claramente definida nunca. Si alguna vez lo estuvo, es probable que se haya deteriorado hasta el punto de ser imposible reconocerla. Los programadores con un mínimo respeto por la estructuración huyen de esta clase de cenagales. Sólo a aquéllos a los que la arquitectura les trae sin cuidado y que tal vez se sienten cómodos programando por inercia parches día tras día para los interminables agujeros de estos diques que hacen aguas por todas partes, no les importa trabajar en tales condiciones.

Los programadores a cargo de proyectos con grandes bolas de lodo deben estudiar su comportamiento para entender su función, cambios de tecnología (de una filosofía cliente-servidor a una basada en web, de la utilización de ficheros al empleo de una base de datos, etc.) pueden proporcionar un buen motivo para empezar desde cero.

Espero les  guste y a programar felices…!