YAGNI, KISS, DRY, WET, SLAP, ASAP, YOLO - ¿Qué significa todo esto?
¡Ave, codificador! Si alguna vez leíste literatura de programación en inglés, tomaste cursos en inglés, trabajaste con compañeros codificadores de habla inglesa o simplemente mantuviste correspondencia con ellos, probablemente te hayas encontrado con estas abreviaturas y cuando un codificador barbudo le dijo KISS a otro, te garantizo al menos ligeramente elevado.
En este artículo, analizaremos qué palabras, o más bien abreviaturas, son populares entre los TI-shniks de habla inglesa.
Imágenes aquí: youtu.be/ub0YtnSwqRA
KISS ("Mantenlo simple, estúpido")
Esto no es un patrón, ni un anti-patrón, ni siquiera una banda de rock de los setenta, en este caso, es uno de los principios o enfoques más populares para programar cualquier cosa.
De hecho, este principio requiere que su código sea lo más simple posible, porque un montón de funciones innecesarias que se duplican entre sí, y el hábito de rascarse la oreja izquierda con la mano derecha no son un signo de un programador profesional.
Cuanto más simple sea el código, más fácil será entenderlo, respectivamente, menos posibilidades de quemar una silla debajo de una persona que se encargará de tirar este código por ti.
Steve McConnell dijo una vez: "Escribe el código como si fuera apoyado por un psicópata violento que sabe dónde vives".
Por tanto, es mejor no complicar realmente las cosas que no lo requieran.
DRY ("No te repitas")
El principio Don't Repeat Yourself es muy similar al de KISS. Esto es bastante simple y al mismo tiempo tiene un significado amplio. Esto es bastante simple y al mismo tiempo tiene un significado amplio, ¿entiendes el chiste?
Copiar, pegar y duplicar fragmentos de su propio código, como escoliosis o discapacidad visual, todos los programadores sufren de esto con el tiempo. No hay nada malo. A veces, todos necesitan verificar algo rápidamente (comportamiento esperado u otra cosa) para luego determinar si vale la pena escribirlo correctamente. Pero definitivamente es inaceptable enviar dicho código a producción.
DRY nos recuerda que todo comportamiento repetitivo en el código puede y debe recuperarse (por ejemplo, dentro de una función) para su posterior reutilización. Tener dos partes del mismo código en su base de código no es bueno. A menudo, esto puede provocar la desincronización y otros errores en su código, sin mencionar el aumento en el tamaño del programa.
WET ("Disfrutamos escribiendo")
Las soluciones WET están muy extendidas en arquitecturas de varios niveles en las que se puede encomendar a un desarrollador, por ejemplo, agregar un campo de comentario a un formulario en una aplicación web. La cadena de texto "comentario" se puede repetir en una etiqueta, etiqueta HTML, nombre de función de lectura, variable privada, DDL de base de datos, consultas, etc. El enfoque DRY elimina esta redundancia mediante el uso de marcos que reducen o eliminan todas las tareas de edición, excepto las más importantes, mientras dejan la capacidad de agregar nuevas variables en un solo lugar.
YAGNI ("No lo vas a necesitar")
No necesita esto: este es un principio que puede contradecir las opiniones de algunos programadores, así como de aquellos que han agregado decímetros al plan de estudios de la escuela.
Estar preparado para el futuro es generalmente bueno, pero no en programación. Dejar cualquier código destinado solo para futuras extensiones no es un gran problema.
Pero si eres un cyber-plushkin por naturaleza, y por la sola idea de dejar solo lo necesario, la silla debajo de tus rollos comienza a derretirse, entonces averigüémoslo: ¿es este un mal enfoque de la programación o es una clínica en la vida?
Los proyectos de codificador no son cosas que tengan un final claro. A menos que el autor abandone la idea (y no se la transmita a otra persona), el proyecto esencialmente continúa. Por lo tanto, hay y siempre habrá margen de mejora, ya sea en el concepto, la arquitectura o incluso el código en sí.
Una cosa es cómo se ve el código ideal en su cabeza, sin errores ni muletas, y otra cosa es lo que realmente está sucediendo.
Naturalmente, un ligero toque de tristeza y apatía puede comprender al codificador en una fría tarde de otoño y el codificador puede decidir poner en el programa los llamados "puntos de extensión" (lugares diseñados para tener en cuenta fácilmente las nuevas funciones) si no se utilizan razonablemente o no son una función obligatoria. luego conviértase en un monumento a la procrastinación y agregue complejidad y tamaño innecesarios al código base. Ahora que lo pienso, incluso va en contra del principio KISS discutido anteriormente.
SLAP ("principio de nivel único de abstracción")
El Principio de Abstracción de Capa Única (SLAP) define cómo debemos organizar nuestro código (funciones específicas) para mantenerlo mantenible.
Es difícil vivir con funciones largas y complejas. Son difíciles de entender para otros desarrolladores y difíciles de probar. Si está completamente en nuestros dedos, entonces, tan pronto como nos enfrentemos a tal abominación, ¡debemos transformarla inmediatamente en varias funciones pequeñas!
Como dijo Robert Martin, "las funciones solo deben hacer una cosa, y deben hacerlo bien".
Pero, ¿exactamente cómo deberíamos organizar nuestras funciones? A medida que usted, mi peludo amigo, adquiera más experiencia en programación, comenzará a comprender más sobre los aspectos prácticos, estéticos y funcionales de la programación y un principio llamado SLAP que pretende ayudar.
En términos generales, sus funciones deben hacer solo una cosa, o en otras palabras SLAP, deben tener solo un nivel de abstracción.
Básicamente, una función que lee la entrada del usuario, por ejemplo, tampoco tiene que procesarla. En su lugar, necesitará utilizar una función separada que se encuentre en un nivel de abstracción diferente e inferior. Cuanto más general sea una función y cuantas más funciones utilice, más alto será en la jerarquía de abstracciones.
FOOBAR ("Jodido más allá de todo reconocimiento")
Parafraseando en ruso: “roto para que no se pueda restaurar”.
Esta es una expresión maravillosa que le llegó a TI de la jerga militar, junto con otras obras maestras como, por ejemplo, SNAFU - "Situación normal - todo jodido"; es algo así como: "la situación es bastante natural, pero todo fue en vano".
La leyenda dice que los programadores de C usaban los nombres "foo" y "bar" para las variables como los llamados "marcadores de posición" o marcadores de posición, especialmente en los ejemplos del tutorial. Entonces, sus cabecitas brillantes se liberaron de la carga de inventar nuevos nombres y pudieron concentrarse en resolver problemas.
Con el tiempo, esto se convirtió en una tradición y migró de C a muchos idiomas no tan antiguos, por lo que se pueden encontrar ejemplos de tales nombres en libros de texto en todas partes, y la palabra "FooBar", aplicada al proyecto, significa que puede comenzar a buscar algo más. ...
Lo antes posible, tan pronto como sea posible")
"Tan pronto como sea posible."
Recientemente, se ha convertido en una tendencia "Tan pronto como sea razonablemente posible" - "Tan pronto como sea posible, pero dentro de límites razonables".
También entró en uso de la jerga del ejército ya durante la Primera Guerra Mundial. Se usa activamente hasta el día de hoy, si este acrónimo se usa a menudo en correspondencia con los superiores, entonces esto puede indicar elocuentemente el nivel de organización en la empresa o las habilidades de gestión y la capacidad de priorizar entre los jefes. Pero hay, por supuesto, excepciones, cuando la situación se salió de control y Foobar en general.
FYI ("Para su información")
El significado oficial es "lo traigo a su atención", pero traducido libremente: "para que usted sepa". Se encuentra en la correspondencia por correo electrónico en todas partes, especialmente cuando la correspondencia no se realiza personalmente con usted, en el sol despejado, pero, sin embargo, decidieron informarle.
TL; DR ("Demasiado tiempo; no se leyó")
Un análogo de nuestro "neosilil de múltiples letras". Esto a menudo se puede ver en publicaciones largas, en las que el autor revela su alma y se quita los velos, pero el lector es demasiado vago para ahondar en esta obra.
DIY ("Hágalo usted mismo")
Hazlo tu mismo. Proviene de los nombres de pequeños talleres de construcción que venden productos para reparar una casa en lugar de construirla. La implicación era que el trabajo son cosas pequeñas y puedes hacerlo tú mismo, sin contratar personal calificado.
Posteriormente, el concepto migró a TI y puede ser adecuado, por ejemplo, en situaciones en las que un especialista necesita hacer un trabajo de un campo relacionado, pero es tan pequeño y trivial que es más fácil hacerlo usted mismo.
Yolo tú solo vives una vez")
"Solo se vive una vez." Por analogía con el latín “carpe diem” (“aprovechar el momento”), este es un llamado a una vida plena, incluso a comportamientos que pueden conllevar algún riesgo. Es el último argumento en la frontera con una experiencia irrazonable o una diversión desenfrenada, pero a veces puede llevar un mensaje más razonable: es una estupidez dejar que el miedo gobierne tus decisiones, porque solo se vive una vez.
Y recuerda, YOLO, así que BESO. Fue V. ¡Nos vemos en el canal! ¡Cra!