Share
Los olores de código y sus refactorizaciones pueden ser muy desalentadores e intimidantes para los novatos. Así que en esta serie, he tratado de hacer que sean fáciles de entender, tanto para desarrolladores de Ruby con experiencia como para principiantes..
Este artículo final menciona algunos olores más que debe tener en cuenta y resume lo que esta pequeña serie quería lograr. Una última bocanada, si te gusta ...
El último artículo de esta serie es algo así como una ronda de bonificación. Quería presentarles algunos olores más que pueden abordarse rápidamente y sin mucho problema. Uno para el camino, por así decirlo. Creo que con el conocimiento que has recopilado de los artículos anteriores, la mayoría de ellos ni siquiera necesitarán ejemplos de código para rodear tu cabeza..
Cuando abre un libro sobre refactorización, encontrará fácilmente más olores de los que hemos analizado. Sin embargo, con estos principales en su haber, estará bien preparado para lidiar con cualquiera de ellos..
Los comentarios generosamente aplicados rara vez son una buena idea, probablemente nunca. Por qué no? Porque podría sugerir que su diseño no habla por sí mismo. Eso significa que su código es probablemente tan complicado de entender que necesita explicaciones literales.
En primer lugar, quién quiere ir a través de montones de texto en su código, o peor, a través de un código que es difícil de entender. Bote si ambos son una ocurrencia común. Eso es simplemente una mala forma y no es muy considerado con las personas que vienen después de ti: sin ofensas, masoquistas, torturen su futuro yo todo lo que quieran..
Quieres escribir código que sea lo suficientemente expresivo en sí mismo. Crear clases y métodos que hablen por sí mismos. En el mejor de los casos, cuentan una historia que es fácil de seguir. Esa es probablemente una de las razones convenciones sobre configuraciones se hizo tan influyente. Reinventar la rueda es a veces una buena práctica para agudizar su comprensión y explorar nuevos territorios, pero en entornos de desarrollo acelerados, sus colegas buscan claridad y navegación rápida, no solo dentro de sus archivos sino también dentro del mapa mental que crea. en tu código.
No quiero adentrarme en un tema completamente nuevo, pero la denominación desempeña un papel importante en todo eso. Y el exceso de comentarios dentro de su código contradice ligeramente las buenas prácticas y convenciones de nomenclatura. No me malinterpretes, está bien agregar comentarios, simplemente mantente en el camino que "ilumina" tu código en lugar de distraerlo. Los comentarios no deben ser instrucciones para códigos inteligentes que, en su mayoría, puedes descifrar porque querías presumir. Si mantiene sus métodos simples como debería y nombra todo con consideración, entonces no tiene necesidad de escribir novelas completas entre su código.
Manténgase alejado de lo siguiente:
También es útil desglosar partes de métodos a través de método de extracción y dar a esta parte de un método un nombre que nos diga sobre su responsabilidad, en lugar de tener todos los detalles desordenados en un alto nivel de comprensión de lo que sucede dentro del cuerpo del método..
def create_new_agent ... end ... # create new agent visite root_path click_on 'Create Agent' fill_in 'Agent Name', con: 'Jinx' fill_in 'Email', con: '[email protected]' fill_in 'Password', con: 'secretphrase 'click_button' Enviar '...
¿Qué es más fácil de leer? Un obvia no, por supuesto! Utilice el kilometraje gratuito que obtiene al nombrar las cosas correctamente a través de métodos extraídos. Por supuesto, hace que su código sea mucho más inteligente y fácil de digerir, además de los beneficios de refactorizar en un solo lugar si se reutiliza. Apuesto a que esto ayudará a reducir sus comentarios por una cantidad muy significativa..
Esto es muy simple. ¡No utilice devoluciones de llamada que no estén relacionadas con la lógica de persistencia! Sus objetos tienen un ciclo de vida persistente que crea, guarda y elimina objetos, por así decirlo, y no quiere "contaminar" esa lógica con otro comportamiento como la lógica de negocios de sus clases..
Mantenlo simple, ¿recuerdas? Ejemplos típicos de qué evitar son el envío de correos electrónicos, el procesamiento de pagos y demás. ¿Por qué? Debido a que la depuración y refactorización de su código debe ser lo más fácil posible, y las devoluciones de llamada desordenadas tienen una reputación de interferir con estos planes. Las devoluciones de llamada hacen que sea un poco demasiado fácil enturbiar las aguas y dispararse en el pie varias veces.
Otro punto problemático acerca de las devoluciones de llamada es que pueden ocultar la implementación de la lógica empresarial en métodos como #salvar o #crear. Así que no seas perezoso y abusa de ellos solo porque parece conveniente!
La mayor preocupación es el acoplamiento de preocupaciones, por supuesto. ¿Por qué dejar que el método de crear Agente de espectro, por ejemplo, tratar con la entrega de un #mission_assignment ¿o algo? Como a menudo, solo porque podamos hacerlo fácilmente no significa que debamos hacerlo. Es un bocado garantizado en el culo esperando a suceder. La solución es en realidad bastante sencilla. Si el comportamiento de una devolución de llamada no tiene nada que ver con la persistencia, simplemente cree otro método y listo..
Las malas elecciones de nombres tienen serias consecuencias. En efecto, estás perdiendo el tiempo de otras personas, o incluso mejor que el tuyo, si tienes que volver a visitar esa parte del código en el futuro. El código que escribes es un conjunto de instrucciones para que lo lean tú y otras personas, por lo que un enfoque puramente lógico, súper prosaico, demasiado inteligente o peor, un simple y perezoso nombre de las cosas es una de las peores cosas que puedes dejar atrás. Trate de hacer que su código sea más fácil de entender proporcionando mejores nombres.
¡La claridad triunfa sobre la falsa inteligencia o concisión innecesaria cualquier día de la semana! Trabaja duro en nombrar métodos, variables y clases que faciliten el seguimiento de algún tipo de hilo.
No quiero ir tan lejos como para decir que debes tratar de contar una historia, pero si puedes, ¡adelante! Las máquinas no son las que necesitan "leer" su código; es su gestión, por supuesto. Tal vez esa es una de las razones por las que el término "Software Writer" ha estado creciendo en mí últimamente. No estoy diciendo que el aspecto de ingeniería deba disminuirse, pero escribir software es más que escribir instrucciones sin alma para las máquinas, al menos un software que sea elegante y que despierte la alegría de trabajar..
No te asustes si esto resulta ser mucho más difícil de lo que pensabas. Nombrar es notoriamente difícil!
¿Los mixins son un olor? Bueno, digamos que pueden oler mal. La herencia múltiple a través de Mixins puede ser útil, pero hay un par de cosas que los hacen menos útiles de lo que podría haber pensado cuando comenzó con OOP:
Le sugiero que lea un poco sobre "Composición sobre herencia". La esencia de esto es que debe confiar más en la reutilización de sus propias clases compuestas por separado que en la herencia o subclases. Los mixins son una forma de herencia que se puede dar un buen uso, pero también es algo de lo que deberías sospechar un poco..
Cuidado con pasar repetidamente los mismos argumentos múltiples en tus métodos. Eso sugiere a menudo que tienen una relación que se puede extraer en una clase propia, lo que a su vez a menudo puede simplificar drásticamente la alimentación de estos métodos con datos al reducir el tamaño de los argumentos. Sin embargo, si vale la pena introducir una nueva dependencia es lo que hay que sopesar..
Este olor es otra forma de duplicación sutil que podemos manejar mejor. Un buen ejemplo es pasar una larga lista de argumentos que conforman una dirección y la información de la tarjeta de crédito. ¿Por qué no empaquetar todo esto en una clase existente, o extraer una nueva clase primero y pasar la dirección y los objetos de la tarjeta de crédito en su lugar? Otra forma de pensarlo es tener un objeto de rango en lugar de un principio y un final. Si tiene variables de instancia que caen por ese olor, entonces vale la pena considerar la extracción de una clase. En otros casos, un objeto parametrico Podría ofrecer la misma calidad de abstracción..
Sabrá que ha logrado una pequeña ganancia si su sistema es más fácil de entender y si encuentra un nuevo concepto como tarjeta de crédito, que podría encapsular en un objeto..
¡Felicidades! ¡Has mejorado tus habilidades OOP significativamente! El estado de nivel de jefe se acerca. No, en serio, buen trabajo si todo este tema fuera nuevo para ti!
Como recomendación final, quiero que te lleves una cosa. Por favor, recuerde que no hay ninguna receta que siempre funcione. Tendrá que sopesar cada problema de manera diferente y, a menudo, mezclar diferentes técnicas para satisfacer sus necesidades. Además, durante el resto de su carrera, es muy probable que esto sea algo con lo que nunca dejará de luchar. Supongo que es una buena lucha, creativa y desafiante..
Esta es una pequeña suposición, pero creo que si comprendió la mayoría de los temas que cubrimos, estará en el camino correcto para escribir el código que otros desarrolladores desean descubrir. Gracias por su tiempo leyendo esta pequeña serie y buena suerte convirtiéndose en un hacker feliz!
Accentsconagua