🆙 🎎 🔹 ¿Qué es el "código limpio" en 2020? 👆 🚉 🚒

^{"Código limpio" y un gato limpio}

No alimente a los desarrolladores de pan, discutamos sobre la limpieza del código: por ejemplo, la publicación de Dan Abramov "Adiós, código limpio" recientemente hizo un escándalo .

Pero al mismo tiempo, el concepto mismo de "código limpio" no tiene una definición clara. El libro principal sobre este tema es "Código limpio" , donde Robert "Tío Bob" Martin inmediatamente declara: "cuántos programadores, tantas definiciones". Sin embargo, a partir de esto no concluye "hablar de ello es inútil", sino la conclusión "vale la pena comparar diferentes definiciones". Por lo tanto, en el libro citó las opiniones de varios programadores prominentes sobre qué es el código limpio.

Nos resultó interesante: en 2020, las ideas de la humanidad sobre el código limpio siguieron siendo las mismas, ¿o cambiaron de alguna manera desde que se lanzó el libro? ¿Las opiniones de diferentes especialistas de TI difieren: tal vez los backenders ven todo desde un ángulo y los evaluadores desde otro?

En abril, el tío Bob volará a San Petersburgo para hablar en nuestras tres conferencias, y están en solo tres direcciones diferentes ( sobre el desarrollo de .NET , sobre las pruebas y sobre JavaScript ). Por lo tanto, preguntamos a varios oradores de estas conferencias qué código limpio tienen para comparar las opiniones de los expertos de la industria en 2020.

Y dado que el tema es hueco, seguro que ninguno de ustedes estará de acuerdo con ninguna de las opiniones. En ese caso, vamos a discutir en los comentarios, ¡esto también es divertido!

UPD: , . , . - . . 13 , .

DotNext

John es una leyenda de Stack Overflow, autor de C # in Depth y uno de los donantes más famosos del planeta. Nos dio esta definición:

“Para mí, el código limpio es un código aburrido, desde el punto de vista de la implementación. La única sorpresa en él es cuánto está desprovisto de sorpresas. Tengo que sentir, "Sí, podría escribir esto", incluso si realmente no pudiera, por lo bien que está diseñado.

Cuando la abstracción se elige correctamente, la implementación se deriva naturalmente. Idealmente, esta abstracción también debería sentirse simple y obvia, aunque de hecho, llevarla a tal estado podría llevar horas, semanas, meses de reflexión y experimentación.

La mencionada falta de sorpresas se aplica luego: cuando escribo código usando una API bien diseñada, mi código también se vuelve obvio y aburrido ".

Andrey Akinshin

Los visitantes de DotNext no necesitan presentar a Andrei, pero por lo demás le diremos que es conocido por su trabajo en IDE Rider , la biblioteca BenchmarkDotNet , informes vívidos y el libro "Benchmarking Pro .NET".

Cuando le preguntamos qué pensaba sobre el código limpio, Andrei se refirió a dos de sus viejos habraposts: "Código perfecto y proyectos reales" y "Comentar o no comentar" . Y hemos seleccionado para usted un par de párrafos a partir de ahí, con los cuales probablemente alguien querrá discutir:

“Me encanta el código perfecto. Después de todo, este no es solo el enfoque correcto para escribir programas, sino también un verdadero arte. Al leer una buena lista, me da tanto placer como leer un buen libro. Diseñar la arquitectura de un proyecto grande no es más fácil que diseñar la arquitectura de un edificio grande, y si funciona bien, el resultado no es menos hermoso. A veces me fascina cuán graciosamente entrelazados patrones de diseño para crear un sistema de software perfecto. Admiro la atención al detalle cuando absolutamente todos los métodos son tan simples y directos que dicen ser el ejemplo clásico de código perfecto.

Pero, por desgracia, todo este esplendor se rompe en la dura realidad y los proyectos reales. Si hablamos de un proyecto de producción, a los usuarios no les importa cuán hermoso sea su código y cuán buena sea la arquitectura, les importa para que el proyecto funcione bien. Pero sigo pensando que, en cualquier caso, debes esforzarte por escribir correctamente, solo que no debe haber fanatismo ".

Dylan Beatty

Habrachitateli puede recordar a Dylan en su informe reflexivo y vívido sobre el trabajo con código heredado: para Habr hicimos su decodificación . Y cuando recurrimos a Dylan sobre el código limpio, escribió un texto tan detallado y reflexivo que lo publicó en al menos una publicación separada:

"Es interesante para mí que el concepto de" código limpio "se haya extendido mucho más allá del círculo de personas que han leído el libro de Robert Martin. Hablé con muchos, muchos desarrolladores que escucharon las palabras "código limpio" pero no leyeron el libro. Incluso los conocí en un codrev: "Todo está bastante bien aquí, pero ¿puedes limpiarlo un poco?" - y tal solicitud puede ser molestamente inexacta si no es obvio lo que significa "puro" en este contexto particular.

En inglés hay palabras que a menudo se encuentran juntas: "limpio", "ordenado", "organizado", "ordenado", y para mí, como hablante nativo de inglés, todas significan cosas ligeramente diferentes. Creo que es útil considerar algunas connotaciones de estas palabras en relación con el desarrollo de software.

Imagine, por ejemplo, la cocina de un restaurante. La palabra limpia en este contexto tendrá connotaciones muy específicas. Todo se lava, esteriliza, no hay amenaza de infección debido a los alimentos crudos y similares.

Pero esto no significa automáticamente que todo esté bien organizado aquí. Si alguna vez trataste de cocinar con un amigo o en un departamento alquilado en Airbnb, sabes lo molesto que es cuando las cosas están fuera de lugar. El detergente para lavar platos está en el buffet, en el que espera ver ollas, y el exprimidor de ajo generalmente no está claro dónde. Sí, todo está limpio, no existe la amenaza de que a alguien le guste la comida cocinada en esta cocina, pero trabajar en esas condiciones es molesto.

Ahora imagine un taller de carpintería. En este lugar, la suciedad también puede causar problemas, pero aquí no tiene la misma definición de "limpieza" que en la cocina. Puede limpiar el cincel hasta que comience a brillar, pero aún es poco probable que corte salchichas con él. Entonces la palabra "limpio" puede ser muy subjetiva.

Pero para mí, palabras como "ordenado" y "organizado" funcionan en contextos donde "limpio" no funciona muy bien. "Organizado" significa que alguien ha pensado cuidadosamente sobre cómo organizar los elementos de un lugar de trabajo en particular, y "ordenado" significa que estos elementos están realmente en los lugares asignados a ellos. Como dice el viejo refrán, "todo tiene su lugar y todo está en su lugar".

Quizás, en el caso del código, deberíamos pensar en las palabras "limpio" , "ordenado" y "organizado" como tres conceptos diferentes. "Limpiar"significa que observa los componentes de la base del código (métodos, funciones, interfaces) y no ve motivos para preocuparse. Al nombrar se adhieren a las convenciones; los nombres de variables y métodos se escriben sin errores; en detalles como sangrías y corchetes se adhieren a un estilo único; donde quiera que mire, verá evidencia de que, en el nivel básico, esto lo llevan a cabo personas que se toman en serio los negocios. Esto es lo opuesto a un "código sucio", uno en el que son deseables muchos errores tipográficos, llaves y sangría en los nombres, nombres de archivo inapropiados. Estas son las cosas que se arreglan mágicamente cuando se llama a la herramienta de limpieza de código en algo como ReSharper.

"Organizado"- Se trata de arquitectura. Se trata de cómo puede sumergirse en una base de código desconocida y encontrar cosas donde espera verlas. Las interfaces y los límites de dominio ayudan, no interfieren; los métodos y variables nombrados no solo se nombran correctamente desde el punto de vista del idioma, sino que también reflejan el idioma único de la empresa con la que trabaja.

Y "ordenado" se trata de respetar las convenciones locales ... una base de código en la que puede encontrar las cosas correctas en sus lugares, incluso si el modelo organizativo específico no es muy claro para usted en ese momento.

Creo que cuando hablan de la lucha por el "código limpio", esto generalmente significa las tres cosas. Pero establecer el objetivo de ser completamente "código limpio", especialmente cuando se trabaja con un proyecto heredado complejo, puede ser una perspectiva bastante desalentadora. Quizás sería útil para todos nosotros pensar un poco más y descubrir cuál de los componentes del "código limpio" realmente beneficiará al proyecto en el que estamos trabajando actualmente ".

Heisenbug

Esta es una "conferencia de prueba no solo para probadores": está en la intersección de las pruebas y el desarrollo. Por lo tanto, muchos de sus oradores entienden los detalles de ambos mundos a la vez.

Ivan Krutov y Anna Chernysheva

Ivan y Anna trabajan en diferentes compañías, pero algo los une: ambos saben mucho sobre Selenium. Hablamos con ellos al mismo tiempo, por lo que obtuvimos una definición conjunta:

Ivan: "Para mí, la definición más simple de código limpio es el código que es comprensible sin comentarios," autodocumentado ". El código que está lleno de comentarios que intentan explicar lo que hace no es código puro ".

Anna: "Me parece a mí: este es un código que puedes descubrir rápidamente, corregir un error, expandirlo fácilmente, complementarlo".

Ivan: "También puedes decir que este es un" código por el que no te avergüenzas ". En general, dicen que si miras el código que escribiste hace seis meses y no estás aterrorizado, entonces no estás desarrollando. Resulta que cada año su código debería ser más limpio ".

Sebastian Dashner

Sebastian es el principal defensor de desarrolladores Java de IBM, y a menudo se lo puede ver en conferencias de Java. Pero dado que ahora está volando a Heisenbug, le preguntamos sobre el código limpio en el contexto de las pruebas, y él respondió:

“En mi experiencia, la calidad del código es importante no solo en el caso del código de producción, sino también para nuestras pruebas. En las pruebas, el código limpio, las abstracciones correctas y la delegación a menudo se descuidan, lo que conduce a un código de prueba que no puede admitir. Cuando refactorizamos el código de producción y cambiamos su comportamiento, queda claro si hemos hecho un buen trabajo modelando e implementando nuestras pruebas ”.

Andrey Lushnikov

Andrey está trabajando en una herramienta de automatización del navegador Playwright, sobre la que escribimos recientemente . Su definición resultó ser la más concisa:

“El código limpio es un código tonto y muy comprensible. Y cuanto más tonto, mejor.

Alexandra Svatikova

Alexandra es una experta en seguridad de la información en Odnoklassniki, que "comenzó en TI como desarrollador de Java, pero dio un giro equivocado". Su definición resultó ser:

“El código puro tiene tres propiedades: otro desarrollador puede leerlo y comprenderlo fácilmente, las mejoras menores requieren un esfuerzo proporcional y se puede predecir el efecto de un cambio en particular.

De hecho, esto significa que el código está estructurado, es conciso, sigue prácticas generalmente aceptadas para el lenguaje en el que está escrito, no contiene dependencias implícitas o efectos secundarios y está cubierto por pruebas ".

Holyjs

Andrey Melikhov

Andrei es conocido por muchos por el proyecto Devshakhta . No es sorprendente que una persona que constantemente formula sus pensamientos en el Podcast de Devshacht y exprese claramente su posición:

"Robert" tío "Martin con sus tres libros principales (" Código limpio "," El codificador limpio "y" Arquitectura limpia "), Me parece que está tratando de responder preguntas por sí mismo: quién, qué y cómo debe escribir. Uno puede discutir sobre la exactitud de algunas de sus conclusiones, pero esto es lo que es indiscutible: estos libros se basan en una rica experiencia personal y sentido común. Y dentro del marco de esta idea, puedo decir que para mí un código limpio es un código que sería escrito por una persona que tropezó con un número considerable de dificultades en su vida y en este proceso doloroso aprendió a caminar con un paso cuidadoso que les permite evitarlo.

Puede que no te sientas cómodo con el estilo de esta persona, pero si lo sigues, ciertamente permanecerás intacto. Puede tomar este estilo y reciclarlo, hacerlo conveniente para usted. O puede sumergirse desesperadamente en el río para llenar sus propios conos, desarrollar su propio estilo, mientras que el resto lo mirará con incredulidad, moviéndose bajo la supervisión de camaradas mayores.

El código puro es un código que es fácil de leer, fácil de mantener y fácil de extender. Son estos tres aspectos los que establecen una base sólida para las aplicaciones que tienen que vivir durante años frente a requisitos externos volátiles. A saber, tales aplicaciones las escribimos en grandes empresas "

Alexandra Kalinina

Alexandra es miembro del comité del programa HolyJS, tiene una amplia experiencia en programación y, aunque no está con Heisenbug, también conoce las pruebas de primera mano (unidad, integración, E2E, B2B). Aquí está su texto:

“El código limpio ahora es un concepto simple, pero es bastante difícil de entender. Me parece que se puede obtener un código limpio observando las siguientes reglas:

- cada fragmento de código individual debe ser capaz de escalar o crecer / mejorar independientemente de otros fragmentos, pero al mismo tiempo conservar la idea / integración original con otros fragmentos (SOLID ayuda mucho, y también la regla "todas las decisiones que puedan tomarse más adelante deben tomarse más tarde").
- El código debe leerse como un libro fascinante, con nombres y designaciones típicas comprensibles. Por ejemplo, si decide escribir una historia, lo más probable es que tenga una estructura típica como una introducción, una trama, un clímax y un desenlace. Incluso si usted es el único que trabaja en un proyecto, el código debe ser leído fácilmente por usted después de cualquier momento, independientemente de la arquitectura, el lenguaje o los marcos elegidos.
- El código debe tener una estructura clara. Aquellos. Debe entenderse la razón por la cual este o aquel fragmento de código está en el proyecto.
"Cada línea de código debe justificarse desde una perspectiva empresarial"

Nicolò Ribaudo

Nicolo, mientras todavía era estudiante, se convirtió en uno de los desarrolladores clave del compilador de Babel (ya le preguntamos sobre esto por separado). Su versión resultó ser esta:

“Un código limpio es un código que se puede dividir fácilmente en pequeños componentes atómicos.

El "átomo de código" es el conjunto de instrucciones más pequeño posible que tiene un significado independiente y no depende innecesariamente del contexto circundante: los nombres de las variables y operaciones son lo suficientemente descriptivos para que el lector no necesite asignar memoria adicional en su cabeza para almacenar sus valores y posibles modificaciones, así como no era necesario buscar en otra parte del código para comprender qué significa el resultado de este "átomo". Cuanto más pequeños son los átomos, más fácil es comprender lo que hace el código.

El código puede ser limpio independientemente del lenguaje o paradigma de programación: los átomos se pueden implementar como pequeños objetos, funciones o incluso como pequeños fragmentos de código que no están aislados sintácticamente ".

Conclusión

Finalmente, cuando se recopilaron las opiniones, se las mostramos al tío Bob y le preguntamos si quería decir algo. La respuesta resultó ser:

“Apoyo totalmente a los comentaristas anteriores. Solo agregaría una cosa que Michael Feathers dijo una vez: "Un código limpio siempre parece haber sido escrito por una persona a la que le importa".

Su conclusión suena muy amigable. Pero el código limpio es un tema tan discutible que mientras uno de ustedes asiente, probablemente alguien más está ardiendo, sintiendo algo como esto:

« : „ , ”. , , : . , !»
« „ ”? „” , — , , „” — !»
"Las palabras" puedes llenar tus baches mientras los demás miran con desconcierto "suenan despectivas, como si solo los tontos lo hicieran. ¡Pero todo lo mejor e innovador aparece cuando llena sus conos y comprende sus razones, y no solo sigue libros antiguos! ”

UPD 12 de marzo: aunque el tío Bob no puede volar con nosotros, es poco probable que nuestras conferencias de San Petersburgo ( para desarrolladores de .NET , probadores y desarrolladores de JavaScript ) discutan con un código limpio. En los sitios de conferencias: siempre versiones actualizadas de los programas. Estén atentos y suscríbase a nuestros boletines informativos: una vez a la semana hablaremos sobre los cambios.

¿Qué es el "código limpio" en 2020?