Creo que tarde o temprano, cada desarrollador piensa en su cabeza que el código debe escribirse de cierta manera. ¿Por qué el marco de este autor es tan fácil de usar y la inmersión en él es tan rápida? ¿Por qué este código me parece horrible? En este momento, tiene lugar una ronda importante en el desarrollo del desarrollador como profesional. No solo comienza a pensar en cómo implementar una tarea específica, sino también en cómo
formalizar su decisión. Los pensamientos sobre una cierta estructuración del código y su hermoso diseño comienzan a surgir en mi cabeza. Alguien comienza a crear para sí mismo un cierto conjunto empírico de reglas para el diseño del código, alguien viene en ayuda de la literatura o el consejo de camaradas más experimentados. En cualquiera de estos escenarios, el código comienza a verse no solo como una solución incondicional al problema. Se piensa que parte del código está hecho
feo , pero aquí resultó ser genial y
elegante . Pero, ¿quién define estos criterios de belleza en relación con el código y qué se establece en ellos? ¿Está todo claro sobre la etiqueta y la belleza del código?
Descargo de responsabilidad: este artículo tiene como objetivo compartir pensamientos que surgieron en el proceso de tratar de dar sentido al concepto de código hermoso. Estos pensamientos no pretenden ser la verdad última. Solo espero que estos pensamientos, pensamientos y argumentos probablemente ayuden a alguien a ver el proceso de escribir código desde una perspectiva ligeramente diferente. Además, no hay una sola regla formal de la forma "Escriba el código de esta manera, y será feliz". Ya se ha escrito una gran cantidad de literatura de autores mucho más respetados sobre este tema.
Todos los interesados en las discusiones sobre el tema de qué es la belleza del código, en qué se puede expresar, por qué todas las prácticas conocidas no pueden cerrar esta pregunta de una vez por todas, le pido un gato.
Buenas y malas prácticas
"... y le preguntó al bebé: - ¿Qué es bueno y qué es malo?" - Mayakovsky V.V.
Y a menudo nos preguntamos cómo formatear correctamente nuestro código. Para responder a esta pregunta, ya se ha escrito una gran cantidad de literatura profesional en el mundo. Tomemos, por ejemplo, los trabajos más populares sobre este tema, que son los más escuchados:
Creo que hay una gran cantidad de libros que pueden complementar esta lista. Pero la historia no trata sobre la necesidad de aplicar este o aquel enfoque. No se trata de cómo este o aquel libro es bueno o malo. En el curso de la reflexión, podemos concluir que incluso el uso de todas las buenas prácticas descritas en estos libros no le garantiza un código hermoso. Y que todo esto puede ser en detrimento y para bien. Resulta que si no hay una "fórmula para el éxito" definitiva, entonces quizás valga la pena comenzar al menos con un bosquejo de pensamientos sobre lo que exactamente quieres lograr, tratando de escribir un código hermoso. Sabemos qué es el código, pero ninguno de nosotros puede decir qué es un código hermoso.
Prerrequisitos para pensamientos
No importa cómo alguien quiera separar la programación en una disciplina independiente separada, todo se reduce a la ingeniería. En consecuencia, los pensamientos e ideas generales en el campo de la ingeniería son válidos tanto para la industria automotriz y la construcción, como para la programación. Todo esto se trata de la aplicación del conocimiento científico a la creación de algo práctico, hasta cierto punto material (si hablamos de desarrollo de software, pueden surgir disputas puramente filosóficas sobre la materialidad). Desde un punto de vista práctico, cuanto más simple es el sistema (diseño, idea), más conveniente, más fácil de trabajar y mantener, y
más hermoso parece.
Una explicación de este pensamiento es un ejemplo de la industria automotriz.Tomemos un ejemplo de la industria automotriz. Por el momento, tenemos una gran selección de automóviles de diferentes categorías de precios y características, así como la estructura interna de las unidades. Dejemos de lado todos los pensamientos sobre el componente económico (costo, relaciones públicas, marketing, etc.) e intentemos evaluar la situación actual en el mercado de automóviles en términos de confiabilidad. Habiendo reducido el campo de razonamiento, nos restringimos a la evaluación de la unidad de potencia. Esto se aplica, por ejemplo, a los motores de los automóviles. Por el momento, la gente ya ha inventado muchos tipos diferentes de motores, cada uno de los cuales es bueno en su campo. Los principios de su trabajo son simples pensamientos sobre la ubicación de los pistones, cilindros, su número y volumen. Todo esto, en un grado u otro, afecta solo a 2 indicadores: confiabilidad y potencia. Las realidades actuales son tales que la solución más confiable es utilizar una gran unidad atmosférica. Los motores turboalimentados son más pequeños en comparación con las soluciones atmosféricas, sin embargo, implican el uso de una unidad separada para el suministro de aire (turbinas), lo que complica el sistema en su conjunto. Además, dado que el motor en sí es más pequeño, en una empresa con una turbina puede producir la misma potencia o incluso más que un motor de aspiración natural 2 o 3 veces más grande. Esto se logra debido al hecho de que el motor, que da más potencia, funciona al límite de posibilidades. Al mismo tiempo, un gran motor de aspiración natural produce aproximadamente la misma potencia, pero es más fácil de usar y mucho más ingenioso. Es decir, una solución más simple es al mismo tiempo la más pragmática.
Explicación de este pensamiento con un ejemplo de la naturaleza.Otro ejemplo simple se puede tomar de la naturaleza. Desde su aparición en el planeta, las abejas han estado construyendo colmenas. Las colmenas se consideran las estructuras de insectos más avanzadas. La cuestión es cómo las abejas construyen panales. Para la construcción de panales, se utiliza un mínimo de material, cera, que se presenta de la manera más óptima, en forma de hexágonos. Aquí podemos observar nuevamente el triunfo de la simplicidad. En lugar de usar materiales más fuertes o estructuras más complejas (que probablemente requerirán algunas columnas auxiliares, soportes, etc.), se usa un material simple y una forma simple pero más avanzada para lograr la solución más pragmática y elegante . Evidencia de que tal solución es hermosa, mucho. Tomemos, por ejemplo, la impresión 3D. Cualquier persona que esté más o menos interesada en las impresoras 3D sabe que las impresoras imprimen modelos, dentro de los cuales hay una estructura de panal que hemos visto a las abejas.
Explicación de esta idea mediante un ejemplo de las matemáticas.En este ejemplo, la simplicidad puede no ser tan obvia. Muchas personas, en su mayoría de una mentalidad no técnica, encuentran las matemáticas complejas y en su mayoría inútiles. La idea principal que sentó las bases para todas las matemáticas es la idea de que todas las situaciones de la vida se pueden modelar. Debe tenerse en cuenta que a menudo el modelo resultante es mucho más simple y menos detallado que el proceso de la vida real. El ejemplo más simple es, digamos que un pastor tiene un rebaño de ovejas. Pero el día fue duro, y se quedó dormido en el trabajo, y cuando se despertó, pensó que necesitaba asegurarse de que todas las ovejas estuvieran en su lugar. En este momento, el aparato matemático más antiguo, los números, pueden ayudarlo. Por sí mismos, los números no significan nada. En una figura abstracta, aislada de la realidad, no tiene más sentido que tratar de poner los pantalones sobre la cabeza. Pero con respecto a la situación de determinar el número de objetos no tienen igual.
Daré un ejemplo más complejo. Mi programa universitario tenía una asignatura extremadamente útil llamada Algoritmos combinatorios. La mayor parte de este curso se dedicó al estudio de la teoría de grafos y varios algoritmos de grafos. Hablar sobre teoría de grafos fue anteriormente sobre otros temas, pero solo superficialmente. Es decir, todos mis compañeros de clase ya se imaginaban qué era y con qué estaba. Alguien incluso hizo trabajo de laboratorio en la implementación de cualquier algoritmo en gráficos. Pero fue en uno de los pares de algoritmos combinatorios que el profesor de repente preguntó: "¿Y quién puede decir por qué se necesitan estos gráficos?" Por extraño que parezca, ninguno de los miembros del grupo fue capaz de responder, se colgó un silencio grave. La respuesta fue obvia y simple: se necesitan gráficos para modelar. Por sí mismos, nadie necesita gráficos, al igual que la capacidad de implementar el recorrido en ancho o profundidad. Pero, como se aplica a muchas situaciones de la vida, es extremadamente conveniente abandonar un montón de detalles innecesarios y dejar solo una esencia abstracta.
Hay muchos más ejemplos similares de la vida humana y la naturaleza que estarán unidos por un pensamiento común: a menudo, una solución simple es la más bella. Es en el momento en que descubro lo simple que este o aquel objeto parece ser tan necesario en la vida, el pensamiento de que está hecho
maravillosamente se arrastra en mi cabeza. Si bien no estamos hablando de estética, exclusivamente del dispositivo del "compartimento del motor".
Una vez me topé con el libro
Kevlin Henney: 97 cosas que todo programador debe saber: la sabiduría colectiva de los expertos . Este libro tiene 97 capítulos pequeños escritos por diferentes personas y solo se relaciona con el hecho de que se trata de programación. Una especie de sabiduría mundana de personas con amplia experiencia en programación. Inmediatamente haga una reserva de que una descripción tan detallada de ninguna manera es un anuncio. Pero no puedo mencionar este libro, porque uno de sus capítulos requiere pensar que un
código hermoso es un código simple . En general, se llama "La belleza está en la simplicidad" (La belleza reside en la simplicidad). El autor comienza el capítulo con una cita de Platón de que todas las cosas bellas son simples:
La belleza del estilo, la armonía, la gracia y el buen ritmo dependen de la simplicidad - Platón
Fue este aforismo lo que despertó aún más mi interés en el campo del código hermoso y la aplicabilidad del concepto de una "solución hermosa" al código, y como resultado, la equivalencia de un código hermoso a simple.
¿Qué es la belleza?
Entonces, llegamos a la cuestión de la belleza del código. Para comprender de la manera más objetiva posible si la belleza es sinónimo de simplicidad en nuestra pregunta, debemos comenzar con un concepto básico. Vaya a wikipedia para obtener una definición:
La belleza es una categoría estética que denota perfección, una combinación armoniosa de aspectos de un objeto, en la que esta última evoca placer estético en el observador.
Hablando de código, no podemos razonar exclusivamente desde un punto de vista estético. Un código hermoso (perfecto, bueno) combina estética y semántica. La semántica del código también debe pertenecer a la categoría de "soluciones hermosas".
Creo que muchos estarán de acuerdo en que, además del valor práctico, el código (más precisamente, el resultado de su trabajo y el proceso de creación) es creativo. La analogía creativa más cercana al desarrollo de software es la creación de una obra literaria. Estas ramas de la creatividad, sin duda, tienen mucho en común. Para simplificar, el código del programa se puede comparar con un libro. Ambos son
simulacro de pensamientos. La única diferencia es que, en términos generales, el resultado del código es algún tipo de resultado en la pantalla del dispositivo, y el resultado de leer el libro son
alucinaciones, series visuales, asociaciones e impresiones que surgen en nuestras mentes. Al escribir libros, se tiene en cuenta una gran cantidad de reglas que le permiten formatear correctamente el texto. Este momento es similar a las reglas de un lenguaje de programación y al flujo de trabajo del compilador / traductor / intérprete. El texto fuente del libro se somete a una rigurosa edición iterativa antes de aparecer ante los ojos del lector. Pero el contenido es más importante. Por otro lado, pocas personas pueden dominar el libro más interesante y fascinante hasta el final o entender correctamente si los pensamientos no están correctamente (léase: bellamente) enmarcados en un texto coherente.
¿Por qué es importante el código hermoso?
En la expresión de pensamientos en papel, sin duda vale la pena centrarse en las reglas del lenguaje, así como en la estructura y la simplicidad de la expresión. Las impresiones y pensamientos que se transmitirán al lector, y las imágenes que aparecen en su cabeza, dependen directamente de esto. Todo es un poco más complicado con el código. Al usuario final de nuestro software no le importa cuán bellamente está escrito y qué tipo de experiencia obtiene el desarrollador al trabajar con este código. El usuario final solo está interesado en la calidad del producto lanzado, cómo funciona, qué tan conveniente es usarlo.
A diferencia de la literatura, la calidad del código es una característica que es importante para el desarrollador o el equipo que trabaja en ella. No tiene que ser desarrolladores. Todo el equipo (por ejemplo, gerentes de proyectos, jefes e inversores) puede sufrir una gran cantidad de errores durante el desarrollo. Sin embargo, en el caso de especialistas de otras áreas, la belleza del código les concierne solo indirectamente. En primer lugar, los desarrolladores se convierten en víctimas del código feo. ¿Por qué es tan importante para ellos? La mayor parte del tiempo al desarrollar un producto, lo pasamos analizando el código, navegando en él, en busca de un lugar donde necesite escribir o corregir las líneas necesarias.
Todo sería mucho más simple si una persona estuviera involucrada en el desarrollo de un producto en particular. Todo el código fuente sería consistente y entendible para él. Pero para que este mismo software se pueda desarrollar en tiempo real, y no décadas, un equipo de varios desarrolladores a menudo participa en el desarrollo de un software. Hace sus propios ajustes. Por ejemplo, el concepto de belleza (en particular, la belleza del código) que cada desarrollador puede tener. Pero dado que el trabajo continúa en equipos, los estándares se establecen para configurar el equipo para pensar
más o menos lo mismo. Esto nos permite hacerlo de modo que al leer el código, el desarrollador no siempre pueda entender si él o alguien más escribió el código y quién exactamente, y da una sensación de comunidad, integridad del equipo. Decimos "Código de nuestra aplicación", y no "mi código" o "mi script". Hablando en términos generales, estamos tratando de tener una idea general sobre la belleza de un grupo de personas conectadas por un solo software y, a menudo, nada más. Resulta que en el concepto de belleza de código hay subjetividad, pero tratamos de minimizarla dentro del equipo. Pero, ¿es posible hacer que el concepto de belleza de código sea completamente objetivo? ¿A qué recurrimos en un intento por lograr la belleza objetiva y cuánto funciona? Para llegar a la respuesta a estas preguntas, vale la pena considerar ese poco en común que absolutamente todas las personas tienen. A saber: el cerebro y cómo procesa la información.
¿Cuál es el mejor trabajo del cerebro?
En Internet, puede encontrar innumerables artículos sobre cómo funciona el cerebro para reconocer la información. Por ejemplo, puede consultar
este artículo.
Nuestro cerebro procesa una gran cantidad de información y, para optimizar su actividad, utiliza plantillas. Estos patrones se forman en el curso de nuestras vidas. Un buen ejemplo es el proceso de lectura. Cuanta más literatura haya leído una persona en un idioma, mayor será su velocidad de lectura. Cuantos más libros leas, más palabras leerás y más a menudo las encontrarás. El reconocimiento visual de palabras que ocurren con frecuencia ocurre muchas veces más rápido que leer una nueva terminología (especialmente para un área temática desconocida). Cuantos más libros haya leído un autor, más rápido podrá leer otras obras de ese autor. Esto es cierto porque cada autor tiene un vocabulario y un estilo de escritura limitados.
Si miras más profundamente, entonces aprendemos a leer por el hecho de que estamos aprendiendo el alfabeto. Más precisamente, aprendemos a reconocer las letras escritas, y solo entonces retomamos el reconocimiento de las palabras. Otro hecho interesante está relacionado con el reconocimiento de letras: la velocidad de reconocimiento de letras por parte del cerebro también depende de la fuente, si hablamos de texto impreso o de escritura a mano para textos escritos a mano. Además, cuando se trata de textos escritos a mano, la situación puede llegar al punto de lo absurdo: la escritura a mano puede ser tan mala que simplemente no podemos entender lo que está escrito (hola a los médicos). El proceso de enseñar a un niño a leer, muy probablemente, es precisamente el fenómeno vital que inspiró a las personas a crear redes neuronales. Quienes estén interesados en este tema pueden ver materiales sobre cómo se reconoce el texto utilizando algoritmos de redes neuronales.
Cuando leemos las palabras, solo en las etapas iniciales prestamos atención a todas las letras. Y nos enseñan a leer en consecuencia, primero por letra, luego por sílabas y solo luego por palabras. Hay un estudio interesante, cuya tesis puede responder por sí misma:
Según las rzelulattas, el ilseovadny odongo de un unquirtiset no es parte del trabajo, en los capullos, las calabazas en solva se tuestan de inmediato. Galvone, cortando y abofeteando bkvuy blyu en msete. En el pasado, los bkuvs se pueden sellar en un seno completamente, lecturas de texto completamente desgarradas sin brem. Pichriony Egoto, es porque no hacemos cada calabaza por separado, pero todo es sólido.
Y esta es otra prueba de que el cerebro trabaja con patrones. Toda la información nueva que recibimos del cerebro también está tratando de manejar las plantillas existentes, recurriendo a 3 principios básicos:
- eliminación: eliminamos de la memoria información única (menos plantilla) no utilizada
- distorsión: se refiere a la exageración o subestimación de algo. Por ejemplo, en nuestra vida cotidiana, las palabras "nunca", "siempre", "nada", "todos", "todos" se utilizan con frecuencia. Si lo piensa, cada uso de esa palabra es una mentira o una distorsión de los hechos.
- — -, . .
, ,
, . . , . — (code in terms of domain). , ( — «» «»).
, , . . , . , .
:
- , , . , , .
- , . , , . , . , . , . - , « ».
- , . . , , . . , .
Resulta que se debe crear un código hermoso a partir de simples repeticiones redundantes . Incluso hay un acrónimo conocido DRY sobre este tema : no se repita. Sin embargo, ¿es esto siempre cierto si miras al mundo más amplio?— . . , . — . , , . , . , — Rap/Hip-hop — . , . , — , . — ? , , . — , . — , , . . «» . , .
. -. , , . , , ,
.
, ?
?
Desde el momento en que nos sumergimos en la profesión, complejos e intrincados, a primera vista, los principios y enfoques nos rodean. Los especialistas senior, bajo cuyo ala estudiamos, hablan sobre varios enfoques, patrones y libros que vale la pena leer para tener éxito en el campo de la POO. Creo que las palabras más escuchadas son patrones de diseño y SÓLIDOS . No todo el mundo se vuelve completamente claro por qué todo esto es necesario. Pero el punto general es escribir un código hermoso y correcto. ¿Y cómo nos ayuda esto, y es siempre? Todos los patrones y abreviaturas mágicas tienen como objetivo enseñarnos a pensar en la programación con los mismos patrones que al leer y analizar texto sin formato.¿Los patrones de diseño son siempre buenos?
. , . , . , , , . — , , , . . , .
, , . - -. , , , . , — , - / («, !») . , - . , , , . — . ( , , ) , . , .
, , . , , . , , , . ( - , ), .
, , . , — . , , . — « », « ! () ...». , . — . .
, :
.
, — , . , () — , .
, , . - . , , . , . . , , , , . , — . , . -. , - — , . , , , . , — .
API
API, - , ( ). - , . API , , . 2 .
, () , , , , . , .
—
. , , , . LINQ C#. (IEnumerable). - , . C# —
Zenject .
:
Container.Bind<Foo>().AsSingle().NonLazy().FromInstance(FooInstance");
Un ejemplo muy famoso de una interfaz fluida de Swift es el popular marco
Alamofire .
En él a menudo puedes ver tales diseños:
Alamofire.request( .GET, "http:foo.com", parameters: ["include_docs": "true"],encoding: .URL).validate().responseJSON { (response) -> Void in... }
En la mayoría de los casos, se puede elegir el estilo apropiado en función de la situación actual. Pero nadie se molesta en reescribir la API de la biblioteca de un estilo a otro sin cambiar la funcionalidad, y luego se convierte en una cuestión de gusto o belleza. En general, las interfaces fluidas no son tan comunes como el estilo clásico, pero dependiendo de una gran cantidad de factores, pueden hacer que el código sea más hermoso o más feo. Derivar una fórmula universal aquí también falla.
Productos de belleza lingüística
Ya hemos llegado a la conclusión de que para la belleza necesitamos plantillas, sin ellas en ningún lado. Los patrones deben ser reconocibles, simples y cortos. Con patrones de diseño, todo resultó ser ambiguo. Pero además de los patrones arquitectónicos, las construcciones del lenguaje que está escribiendo también vienen al rescate. El mismo patrón de diseño implementado en un idioma puede verse hermoso y feo dependiendo de las herramientas específicas del idioma.
Común para la mayoría, si no para todos los lenguajes de programación, entonces para la mayoría, una herramienta de lenguaje que no afecta la semántica del código, pero afecta su belleza, es comentar. Agregar un buen comentario en el lugar correcto puede mejorar la apariencia del código. Pero vale la pena escribir un comentario aislado del estilo general (por ejemplo, los lenguajes tipo c le permiten describir comentarios de tres maneras diferentes), ya que arruina de inmediato la imagen general y distrae visualmente la percepción del código en sí.
Como víctima, veamos algunas de las herramientas que nos brinda C #. Una de las herramientas más simples en este lenguaje es la palabra clave
var . Evita indicar explícitamente el tipo de una variable cuando se declara, utilizando var para cualquier tipo o interfaz.
Por un lado, esta herramienta ayuda a eliminar casi todos los nombres de tipo en los cuerpos de los métodos. Por otro lado, te hace pensar sobre a qué tipo pertenece esta o aquella variable. La gran mayoría de los desarrolladores condolencias a C # consideran que usar var es una buena práctica. Es decir, esta herramienta de lenguaje puede considerarse más útil que perjudicial en términos de la belleza del código.
La directiva
#region #endregion le permite especificar bloques de código que se pueden contraer en el IDE. Es una de las herramientas más controvertidas. En algunos equipos, el uso de esta directiva está estrictamente prohibido, en otros se recomienda de forma obligatoria. Un argumento para no usar esta directiva es que diluye el código con inserciones semánticamente inútiles que le impiden concentrarse en el código mismo. Como argumento "a favor", se puede citar una práctica en la que los métodos de clase se agrupan por región de tal manera que se puede ver fácilmente y sin editar el código su implementación interna, o una API externa, o una implementación de uno u otro patrón (que a menudo puede verse como plantilla y se retira a la región para que los ojos no se callen). En resumen, podemos decir que la herramienta es más que controvertida.
La herramienta final a tener en cuenta es las
expresiones lambda y los métodos anónimos. En términos generales, podemos decir que ambas herramientas están diseñadas para describir el método de la manera más compacta posible, a menudo sin declararlo explícitamente. Para estos fines, podemos acudir al rescate con características tales como reducir la firma, los tipos de parámetros de entrada y salida, lo que obliga al compilador a mostrar todo esto explícitamente para nosotros. Sin embargo, una herramienta que muchos tienden a considerar una parte integral del lenguaje tiene la posición más controvertida en términos de la belleza del código. Por ejemplo, LINQ es difícil de imaginar sin expresiones lambda; son compactas y concisas. Pero si abusa de su uso, todo el código de la clase puede convertirse fácilmente en un lío ilegible.
Tales herramientas de lenguaje como métodos de extensión (métodos de extensión), foreach vs for, métodos anónimos, operador ternario, encadenamiento de constructores y otros quedan fuera del alcance del análisis. Todos ellos también están unidos por el uso controvertido en ciertas partes del código. De esto podemos concluir que no existe un azúcar sintáctico perfecto, lo que hace que el código sea indudablemente más hermoso.
Como material adicional sobre el tema del azúcar sintáctico, no me puedo perder el lenguaje de programación joven: Swift. En su mayor parte, no ofrece construcciones de lenguaje únicas. Sin embargo, su capacidad para omitir el ";" Al final de la línea de código, mi noción actual del proceso de escribir código me destrozó. Sé que en la lectura habitual de esta función, no se percibe como algo fuera de lo común. Pero durante el desarrollo del combate en este idioma, al principio fue bastante difícil de reconstruir. No escriba ";" al final de una línea de código es la práctica recomendada en este lenguaje. Parecería que esto es una verdadera bagatela, pero también puede establecer un paralelismo con él fuera del contexto de programación. Este paralelo reside en las reglas de puntuación de la mayoría de los idiomas del mundo. Estamos acostumbrados a poner puntos al final de una oración, durante años formando un patrón para reconocer pensamientos completos en un texto. Quizás en una simple oportunidad para omitir ";" una regla oculta está oculta en el código, que se puede expresar de la siguiente manera: escriba solo una fecha límite de código en una línea del archivo de código fuente. Y esta recomendación se expresa en última instancia en forma de práctica para no poner ";" al final de la línea, sin dar la oportunidad de agregar algo más a esta línea. Sin embargo, Swift también tiene algunas buenas innovaciones de sintaxis, como la declaración de
guardia .
Si se trata de ";" Al final de una línea de código, es difícil no mencionar el lenguaje Python. Este lenguaje está repleto de todo tipo de azúcar sintáctica. Una parte considerable de este azúcar es controvertida, incluso, si puedo decirlo, claramente no es necesario, solo complica la lectura del código. Sin embargo, todo esto es ambiguo en el contexto del hecho de que el umbral para ingresar al idioma es extremadamente bajo. Parece que los desarrolladores del lenguaje han hecho todo lo posible para garantizar que pueda escribir código en Python, prestando la menor atención posible a la sintaxis. Otra de las características de este lenguaje, me gustaría señalar la falta de asignación explícita de bloques de código (los corchetes "{}" no se utilizan). En lugar de resaltar explícitamente, Python vive con sangría. Por un lado, esto se percibe mejor visualmente, porque el texto tiene menos caracteres de servicio sin sentido. Por otro lado, debe prestar atención a la sangría, que en la mayoría de los idiomas claramente no es necesaria. Este lenguaje no podría funcionar sin interrupciones de los patrones C. En lugar de una declaración try-catch, tenemos try-except. Por su nombre, el operador parece lógico, pero es difícil de reconstruir.
Como último ejemplo controvertido de una herramienta de lenguaje que se encuentra en muchos idiomas, daré clases y métodos generalizados (genéricos). Las generalizaciones per se están diseñadas para evitar que tengamos que duplicar mucho código repetitivo. Es decir, al menos en términos de deshacerse de la duplicación de código en diferentes lugares, las generalizaciones sirven como una herramienta para hacer que el código sea más hermoso. Pero el concepto mismo de un tipo parametrizado por otro tipo se percibe bastante difícil. Cada vez, tropezando con la generalización en el código, uno tiene que dedicar más tiempo a comprender la semántica que a comprender la semántica del código no generalizado.
Dados los puntos indicados anteriormente, se puede argumentar que el azúcar sintáctico también es una herramienta controvertida que puede hacer que el código sea más y menos hermoso.
El lado del software que nos puede ayudar
Toda la subjetividad del enfoque para escribir código y el concepto de su belleza puede ser confusa. Este problema es especialmente grave en una situación en la que un nuevo desarrollador llega a un equipo bien coordinado. A menudo, un novato no tiene más remedio que imitar el código ya escrito y ajustarse en el curso al estilo existente. Esto es lo que a la mayoría de las personas no les gusta cuando llegan a un nuevo trabajo. Todos sus patrones de percepción, cadenas neuronales, reflejos que se han formado a lo largo de los años de experiencia, comienzan a hacer daño en lugar de beneficios pasados. Afortunadamente, al menos en esta área es posible introducir algunas prácticas generales, libres de subjetividad.
Además, hemos sido pensados y atendidos durante mucho tiempo. Los IDE modernos han recorrido un largo camino desde los editores de texto convencionales y pueden facilitar enormemente la tarea de mantener el estilo del código. El resaltado de sintaxis es quizás la herramienta más antigua del IDE. A pesar de su simplicidad y familiaridad, la idea es la misma: formar una plantilla específica que ayude a escribir código. El ejemplo más simple es subrayar una determinada palabra en el código en rojo en caso de error. Además, muchos lugares dudosos a los que debe prestar atención están marcados en amarillo. Todo esto junto es una plantilla que se ha formado en nuestra cabeza desde la infancia con la ayuda de los semáforos.
En términos de belleza de código, los IDE modernos también intentan ayudar lo más que pueden. Por ejemplo, puede tomar un IDE bastante joven de JetBrains - Rider. Aquí, la simplificación de las condiciones lógicas y la ayuda para elegir un nombre de variable, corrección ortográfica en comentarios y nombres de variables, alineación automática y mucho más vienen al rescate.
En cuanto a nombrar variables, alinear el código, insertar pestañas en lugar de espacios y espacios en el código combinado: este es todo el punto principal que ayuda a diseñar el texto como código en un estilo que se adapte a usted. Y el IDE hará la mayoría de estas ediciones en segundo plano por usted. Resulta que solo necesitas enseñarle lo que quieres y, posteriormente, se convertirá en un asistente indispensable para ti, lo que te ahorrará mucho tiempo. Los detalles para enseñarle a su IDE su estilo no son relevantes para el tema de este artículo. Pero si piensa en este concepto en su conjunto, el proceso resulta ser muy similar al proceso de introducir un nuevo desarrollador en el equipo. Una herramienta indispensable para esto es un documento de acuerdo de estilo de código. La única diferencia es que el desarrollador lo recibirá en forma de documento, y el IDE lo generará o guardará en un archivo de configuración interna, en un formato que solo uno entiende.
Por lo tanto, el paso innegable hacia un código hermoso es su estandarización. Muchas empresas de todo el mundo descuidan escribir un documento que estandarice el estilo del código. Sucede que una catástrofe adquiere proporciones terroríficas: la cantidad de proyectos que se desarrollan simultáneamente en la empresa es igual a la cantidad de estilos de codificación utilizados dentro de la empresa. En tales circunstancias, la transición de un desarrollador de un proyecto a otro se vuelve aún más trivial. Si nadie monitorea la estandarización de la base del código, entonces el código tiende a convertirse en un código masivo, y la adaptación en un nuevo proyecto se siente como mudarse a otra compañía, causando más estrés del que podría. Junto con un aumento en el nivel de estrés durante la transición a un nuevo proyecto, el período de adaptación también aumenta.
Tales problemas pueden evitarse teniendo en existencia solo un documento con una convención de estilo de código. Este documento también puede considerarse una herramienta de desarrollo. Con un documento así y un IDE moderno en su arsenal, puede simplificar enormemente su vida al automatizar el estilo de código en el nivel IDE. Esto reducirá el umbral para que el desarrollador se una al equipo y reducirá la cantidad de reclamos contra el desarrollador durante la revisión del código. La idea de automatizar y usar las herramientas de desarrollo al máximo está lejos de ser nueva, se puede encontrar en muchas fuentes, incluido el legendario libro "Programador-pragmático".
Para resumir: las herramientas de desarrollo tienen un efecto muy positivo en la belleza del código. Además, el factor de subjetividad no afecta la utilidad de estas herramientas.
Un lado del software que puede arruinarlo todo.
Ya nos hemos familiarizado con la buena parte del software. ¿Pero son todas las soluciones técnicas destinadas a hacer que el código sea más hermoso? Sucede que cuando un producto está casi listo para su lanzamiento, resulta que no corresponde a las características técnicas de un dispositivo en particular, lo cual es muy importante para nosotros. Este problema es especialmente grave en el campo del desarrollo de software de juegos. Alguien puede tener objeciones razonablemente razonables de que puede escribir de inmediato un software óptimo y hacer la optimización durante el desarrollo, logrando la solución más óptima. A tales objeciones, se puede citar un contraargumento:
La optimización prematura es la raíz de todo mal. -Donald Knut
El debate sobre si esta afirmación es verdadera o no no se refiere a la belleza del código y está más allá del alcance del razonamiento actual.
Pero la optimización puede afectar negativamente la belleza del código. Esto no siempre sucede, pero hay algunas prácticas que probablemente se pueden expresar lejos del código más legible. Ejemplos de tales optimizaciones:
Estas optimizaciones son bastante difíciles de implementar, pero son necesarias en el desarrollo de la informática de alto rendimiento y en una serie de otras situaciones. Pero, por ejemplo, el uso excesivo de la interacción multiproceso tiende a complicar en gran medida el código. Tenemos una situación en la que se puede sacrificar la belleza del código para la optimización técnica.
¿A quién puedo contactar para pedir consejo?
Decidimos que, independientemente de la subjetividad del concepto de la belleza del código, existen prácticas para ayudar a mantenerlo: un documento sobre el estilo del código y un IDE configurado correctamente. Este paquete realmente puede hacer la vida más fácil, pero no puede garantizar un resultado del 100%. La razón de esto es el factor humano. El desarrollador puede estar familiarizado con el documento de estilo de código, tener un IDE configurado correctamente e ignorar todas las reglas y advertencias del IDE. Puede haber al menos 2 razones para esto:
- Desarrollador sin escrúpulos. Quizás el desarrollador aún no está acostumbrado a un nuevo estilo para él y escribe de la manera habitual. O tal vez simplemente no considera que mantener un estilo común sea un punto importante, uno al que valga la pena prestarle atención.
- Una cierta combinación de circunstancias. La mayoría de nosotros conocemos o hemos probado Agile y practicamos sprints con un plazo fijo y un conjunto de tareas. En la vida, hay situaciones en las que llegó una solicitud "desde arriba" sobre la necesidad de implementar una característica importante aquí y ayer que no estaba incluida en el sprint actual. Ninguna empresa puede garantizar que esto no suceda. Cuando se implementan tales funciones, muchas veces suceden cosas, como una "decisión sobre la rodilla" y una "revisión". A menudo, tales cosas se hacen por el bien de la velocidad y simplemente no hay tiempo para seguir la belleza de tal edición.
No importa la razón que llevó al desarrollador a escribir un código feo y llenarlo en una base de código común. Al mismo tiempo, tan pronto como una enmienda entre en el lanzamiento, es probable que permanezca en una forma tan fea. Parecería que ¿qué podría salir mal si todos entendemos que esto sucede solo en situaciones excepcionales y que esto no se puede hacer? La esencia del problema es que este es el precedente que ha tenido lugar. Significa que es muy probable que después de un tiempo, cuando todos olviden el contexto de la situación que ha tenido lugar, algún desarrollador tropezará con este feo código durante el trabajo. Luego, pueden surgir pensamientos equivocados en su cabeza de que si esto ya está en el proyecto, entonces agregar otra porción no empeorará. La receta para el desastre es simple: repita la última acción n veces hasta que todo el proyecto consista en lugares "excepcionales": ventanas rotas.
Tal efecto está muy bien descrito en
Broken Window Theory . Puede lidiar con ventanas rotas de manera bastante simple: solo necesitamos un guardia que supervise el código. Con respecto a la programación, una solución de este tipo encaja bien con el concepto de revisión de código. No puedo nombrar un solo efecto secundario negativo de la práctica de llevar a cabo revisiones periódicas del código. Lo único que las personas líderes pueden tocar es la pérdida de una cantidad significativa de tiempo en la realización de una revisión de código y la corrección de comentarios al respecto. Puede ser difícil para esas personas explicar qué es la deuda técnica y de dónde proviene. Pero en el contexto de la belleza del código, la revisión de código es una práctica puramente positiva.
Además de la persona que lleva a cabo la revisión del código del proyecto (o varias personas), también puede contactar a los desarrolladores del lenguaje o al gurú de la programación para obtener asesoramiento. Por supuesto, no debe confiar en el hecho de que puede escribir una carta o llamar directamente por este mismo gurú. Pero para la mayoría de los lenguajes de programación, hay oficiales o generalmente aceptados.
estándares de estilo de código escritos por personas de buena reputación. Ejemplos:
- Python - PEP8
- C # - StyleCop
- Swift - La guía oficial de estilo Swift de raywenderlich.com
- Objective-C - La guía de estilo oficial de raywenderlich.com Objective-C
Seguir los estándares de estilo de código generalmente aceptados es una buena práctica para ayudar a mantener su código hermoso. Aunque la subjetividad también está presente en los estándares generalmente aceptados, no es posible concluir que el código escrito por estándares comunes será hermoso.
Conclusión sin conclusión
. , , , ( ). , , . , - , , . , , .
, , . . , , , . .