BESO (principio)

KISS ( acrónimo de " Mantenlo simple, estúpido ") es un principio de diseño adoptado por la Marina de los EE. UU. en 1960 [1] [2] .

El principio KISS establece que la mayoría de los sistemas funcionan mejor si se mantienen simples en lugar de volverse más complejos. Por lo tanto, en el campo del diseño, la simplicidad debe ser uno de los objetivos clave y se debe evitar la complejidad innecesaria. La frase se asoció con el diseñador de aviones Clarence Johnson (1910-1990) [3] . En los 1970s el término "principio KISS" fue ampliamente utilizado [ 4 ] .  Las variaciones de la frase incluyen " ing. Mantenlo simple, tonto ", " mantenlo breve y simple ", " mantenlo simple y directo " [5] y " mantenlo pequeño y simple " [6] .

Origen

Según los informes, el acrónimo fue acuñado por Clarence Johnson, ingeniero jefe de Lockheed Skunk Works (creadores del Lockheed U-2 , SR-71 Blackbird y muchos otros aviones) [3] .

Si bien ha sido popular durante varias décadas usar el descifrado "Mantenlo simple, estúpido", Johnson descifró a KISS como "Mantenlo simple, estúpido" (sin coma) y muchos autores todavía usan esta interpretación [7] (en inglés , a diferencia del ruso, se usa una coma para aislar (asignar) la apelación muy raramente). No había ningún significado oculto en eso de que el ingeniero era estúpido; todo lo contrario [3] .

Este principio se ilustra mejor con la historia cuando Johnson entregó un conjunto de herramientas a un equipo de ingenieros de diseño de aeronaves, dándoles la condición de que un mecánico de nivel medio debería poder reparar el avión que estaban diseñando en el campo con solo esas herramientas. . Así que "tontería" se refiere a la relación entre el hecho de que las cosas se rompan y la dificultad de repararlas.

El acrónimo se usa a menudo en la Fuerza Aérea de los EE. UU. y en el campo de la ingeniería de software.

Opciones

Lo más probable es que el principio se derive de conceptos similares como la navaja de Occam , "La simplicidad es la máxima sofisticación" de Leonardo da Vinci, "Menos es más" de Mies van der Rohe o "Il semble que la perfección soit atteinte non quand il n' y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher" de Antoine de Saint-Exupéry . Colin Chapman , fundador de Lotus Cars , instó a sus diseñadores a "simplificar, luego agregar ligereza". Las máquinas Robinson y la máquina Goldberg , que intencionalmente tienen soluciones demasiado complicadas para tareas o problemas simples, son ejemplos humorísticos de soluciones "no KISS".

Un punto de vista alternativo - "Hacer todo lo más simple posible, pero no más simple" - se atribuye a Albert Einstein , aunque esto puede ser una presentación editorial en sus propias palabras de una conferencia dada por Einstein [8] .

“Mantenerlo simple y directo” es una opción utilizada en marketing [5] .

En películas animadas

El animador Richard Williams explica el principio de KISS en su libro The Animator's Survival Kit , y Disney Old Men Nine también escribe sobre él en The Illusion of Life: Disney Animation . El problema es que los animadores inexpertos "animan en exceso" su trabajo, lo que significa que un personaje puede moverse demasiado y hacer demasiado. Williams anima a los animadores a seguir "KISS".

En desarrollo de software

El principio que prohíbe el uso de medios más complejos que los necesarios [9] . Un dicho que a menudo se invoca en las discusiones de diseño para evitar el aumento de la funcionalidad y gestionar la complejidad del desarrollo. Posiblemente relacionado con Keep It Short and Simple [10] . El principio declara la sencillez del sistema como principal objetivo y/o valor. Eric Raymond resume la filosofía UNIX en su libro como el principio KISS ampliamente utilizado [11] .

• Menos es más (Menos es más)
• No te repitas (SECO)
• No lo vas a necesitar (YAGNI)

• Divide las tareas en subtareas que no creas que deban llevar más de 4 a 12 horas de codificación.
• Divida la tarea en muchas tareas más pequeñas, cada tarea debe ser resuelta por una o un par de clases
• Mantenga sus métodos pequeños. Cada método no debe tener más de 30-40 líneas. Cada método debe resolver un pequeño problema, no muchos casos. Si su método tiene muchas condiciones, divídalo en varias. Esto aumentará la legibilidad, facilitará el mantenimiento del código y encontrará errores en él más rápido. Te encantará mejorar el código.
• Mantenga sus clases pequeñas. La misma técnica se aplica aquí como con los métodos.
• Primero encuentre una solución al problema, luego escriba el código. Nunca hagas lo contrario. Muchos desarrolladores encuentran una solución a un problema mientras escriben código, y no hay nada de malo en ello. Puede hacer esto y seguir las reglas anteriores. Si puede dividir mentalmente una tarea en partes más pequeñas cuando escribe código, hágalo por cualquier medio. Y no tengas miedo de reescribir el código una y otra y otra vez... El número de líneas no cuenta, siempre y cuando creas que puedes hacer aún menos/mejor.
• No tengas miedo de deshacerte del código. Cambiar el código anterior y escribir una nueva solución son dos cosas importantes. Si se enfrenta a nuevos requisitos, o no los conocía antes, a veces es mejor encontrar una solución nueva y más elegante que resuelva tanto los problemas antiguos como los nuevos.

Véase también

• TMTOWTDI
• software inflado

Notas

1. ↑ The Routledge Dictionary of Modern American Slang and Unconventional English , Tom Dalzell, 2009, 1104 páginas, p.595, página web: BGoogle-5F Archivado el 24 de noviembre de 2016 en Wayback Machine : señala el "Proyecto KISS" de la Marina de los EE. UU. de 1960, encabezado por el contralmirante Paul D. Stroop, Chicago Daily Tribune , p.43, 4 de diciembre de 1960.
2. ↑ The Concise New Partridge Dictionary of Slang , Eric Partridge, Tom Dalzell, Terry Victor, Psychology Press, 2007, p.384.
3. ↑ 1 2 3 Clarence Leonard (Kelly) Johnson 1910-1990: A Biographical Memoir Archivado el 10 de octubre de 2015 en Wayback Machine (PDF), por Ben R. Rich, 1995, National Academies Press, Washington, DC, p. 13
4. ↑ Pozo y cantera , vol. 63, julio de 1970, p.172, cita: "como en cualquier otro paso del proceso de desarrollo, siga el principio KISS - Keep It Simple, Stupid".
5. ↑ Definición del principio 1 2 Kiss por MONASH Marketing Dictionary (enlace descendente) (18 de noviembre de 1994). Consultado el 24 de enero de 2016. Archivado desde el original el 30 de enero de 2016. (indefinido) 
6. ↑ Principio del beso (enlace descendente) . Consultado el 1 de octubre de 2015. Archivado desde el original el 21 de septiembre de 2011. (indefinido) 
7. ↑ Ram B. Misra (2004), "Global IT Outsourcing: Metrics for Success of All Parties", Journal of Information Technology Cases and Applications , volumen 6, número 3, página 21. Versión en línea Archivado el 29 de enero de 2012 en Wayback Machine . Consultado el 19 de diciembre de 2009.
8. ↑ Todo debe hacerse lo más simple posible, pero no más simple | Investigador de citas . Consultado el 3 de mayo de 2016. Archivado desde el original el 29 de mayo de 2012. (indefinido)
9. ↑ KISS // Diccionario explicativo de informática / Pivnyak G.G. - Ducha. : Nat. bugle un-t, 2008. - S.  130 . — 599 pág. - ISBN 978-966-350-087-4 .
10. ↑ Principio  del beso . babylon.com. Fecha de acceso: 25 de julio de 2010. Archivado desde el original el 18 de febrero de 2012.
11. ↑ Eric Raymond . La filosofía Unix en una lección // El arte de la programación Unix. — Addison-Wesley. — ISBN 0-13-142901-9 .

Enlaces

• Principios del beso
• Principios de KISS para productos ORM
• KISS es el principio de diseño que contiene todos los demás principios de diseño