Los olores a código son un clásico.  Huele porque es probable que haya muchos casos en los que podría editarse o mejorarse.  La mayoría de estos olores son solo indicios de algo que podría estar mal. Por lo tanto, no es necesario que se arreglen per se... (Sin embargo, debe investigarlo).   Olores de código anteriores  Puedes encontrar todos los olores del código anterior (Parte i - XXIX)  aquí  Continuemos...  Code Smell 146 - Comentarios de Getter    Los comentarios son un código Olor. Los captadores son otro olor a código. ¿Adivina qué?  TL; DR: No use captadores. No comentes captadores  Problemas  Comentarios abusadores  Legibilidad  captadores  Soluciones  Eliminar comentarios captadores  Quitar captadores  Contexto  Hace unas décadas, solíamos comentar todos los métodos. Incluso los triviales.  El comentario debe describir solo una decisión crítica de diseño.  Código de muestra  Equivocado   pragma solidity >=0.5.0 <0.9.0; contract Property { int private price; function getPrice() public view returns(int) { /* returns the Price */ return price; } }  Derecho   pragma solidity >=0.5.0 <0.9.0; contract Property { int private _price; function price() public view returns(int) { return _price; } }  Detección    Semiautomático [x]  Podemos detectar si un método es getter y tiene un comentario.  Excepciones  La función necesita un comentario, que accidentalmente es un captador y el comentario está relacionado con una decisión de diseño.  Etiquetas  Comentarios  Conclusión  No comentes captadores.  No agregan ningún valor real e inflan su código.  Relaciones   Code Smell 05 - Abusadores de comentarios   Code Smell 68 - Captadores   Code Smell 01 - Modelos anémicos  Créditos   Foto de Reimond de Zuñiga en Unsplash  El código debe ser notablemente expresivo para evitar la mayoría de los comentarios. Habrá algunas excepciones, pero deberíamos ver los comentarios como una "falta de expresión" hasta que se demuestre lo contrario.   Roberto Martín   Grandes citas de ingeniería de software  Code Smell 147 - Demasiados métodos    Las clases de utilidad son geniales para recopilar protocolo.  TL; DR: no agregue protocolo accidental a sus clases  Problemas  Legibilidad  Violación de responsabilidad única  mala cohesión  alto acoplamiento  Reutilización baja  Soluciones  rompe tu clase   Extraer clase  Refactorizaciones   Refactorización 007 - Extraer clase  Contexto  Tendemos a poner un protocolo en la primera clase que encontramos.  Eso no es un problema.  Solo tenemos que refactorizar.  Código de muestra  Equivocado   public class MyHelperClass { public void print() { } public void format() { } // ... many methods more // ... even more methods public void persist() { } public void solveFermiParadox() { } }  Derecho   public class Printer { public void print() { } } public class DateToStringFormatter { public void format() { } } public class Database { public void persist() { } } public class RadioTelescope { public void solveFermiParadox() { } }  Detección    Automático [x]  La mayoría de los linters cuentan los métodos y nos advierten.  Relaciones   Code Smell 124 - Cambio divergente   Code Smell 143 - Grupos de datos   Code Smell 94 - Demasiadas importaciones   Code Smell 22 - Ayudantes   Code Smell 34 - Demasiados atributos  Más información   Gurú de la refactorización  Etiquetas  Cohesión  hinchados  Conclusión  Dividir clases y protocolo es una buena práctica para favorecer objetos pequeños y reutilizables.  Créditos   Foto de   en  Marcin Simonides Unsplash  No hay código tan grande, retorcido o complejo que el mantenimiento no pueda empeorar.  Gerald M Weinberg  Código olor 148 - tareas pendientes    Compramos deuda para nuestro futuro yo. Es tiempo de venganza.  TL; DR: No deje TODO en su código. ¡Arreglalos!  Problemas  Deuda técnica  Legibilidad  Falta de confianza  Soluciones  Arregla tus TODO  Contexto  Nos encontramos con TODO en nuestro código. Los contamos.  Rara vez lo abordamos.  Empezamos con la deuda técnica.  Luego pagamos la deuda + los intereses.  Unos meses después, pagamos más intereses que la deuda original.  Código de muestra  Equivocado   public class Door { private Boolean isOpened; public Door(boolean isOpened) { this.isOpened = isOpened; } public void openDoor() { this.isOpened = true; } public void closeDoor() { // TODO: Implement close door and cover it } }  Derecho   public class Door { private Boolean isOpened; public Door(boolean isOpened) { this.isOpened = isOpened; } public void openDoor() { this.isOpened = true; } public void closeDoor() { this.isOpened = false; } }  Detección    Automático [x]  Podemos contar TODOs.  Etiquetas  Deuda técnica  Conclusión  Podemos contar TODOs.  La mayoría de los linters lo hacen.  Necesitamos la política para reducirlos.  Si estamos usando TDD, escribimos el código que falta de inmediato.  En este contexto, las TODO solo son válidas cuando se realiza un desarrollo Primero en profundidad para recordar los caminos abiertos para visitar.  Más información   ¿Deberías poner ToDos?   Teoría de las ventanas rotas  Créditos   Foto de   en  Eden Constantino Unsplash  Después de terminar el primer 90 % de un proyecto, debe terminar el otro 90 %.   miguel abrash  Code Smell 149 - Encadenamiento opcional    Nuestro código es más robusto y legible. Pero escondemos NULL debajo de la alfombra.  TL; DR: Evite Nulos e indefinidos. Si los evita, nunca necesitará Opcionales.  Problemas  nulos   SI Contaminante  Soluciones  Quitar nulos  Tratar con indefinido  Contexto    opcional, opcionales, coalescencia y muchas otras soluciones nos ayudan a lidiar con los infames nulos. Encadenamiento  No hay necesidad de usarlos una vez que nuestro código es maduro, robusto y sin valores nulos.  Código de muestra  Equivocado   const user = { name: 'Hacker' }; if (user?.credentials?.notExpired) { user.login(); } user.functionDefinedOrNot?.(); // Seems compact but it is hacky and has lots // of potential NULLs and Undefined  Derecho   function login() {} const user = { name: 'Hacker', credentials: { expired: false } }; if (!user.credentials.expired) { login(); } // Also compact // User is a real user or a polymorphic NullUser // Credentials are always defined. // Can be an instance of InvalidCredentials // Assuming we eliminated nulls from our code if (user.functionDefinedOrNot !== undefined) { functionDefinedOrNot(); } // This is also wrong. // Explicit undefined checks are yet another code smell  Detección    Automático [x]  Esta es una   . función de idioma  Podemos detectarlo y eliminarlo.  Etiquetas  Nulo  Conclusión  Muchos desarrolladores se sienten seguros contaminando el código con transacciones nulas.  De hecho, esto es más seguro que no tratar los NULL en absoluto.    , verdaderos y falsos también son olores de código. Los valores nulos  Necesitamos apuntar más alto y hacer un código más limpio.    : elimine todos los valores nulos de su código. Lo bueno    : usa el encadenamiento opcional. Lo malo    : no tratar nulos en absoluto. Lo feo  Relaciones   Code Smell 145 - Truco de cortocircuito   Código Olor 12 - Nulo   Code Smell 69 - Big Bang (Castings ridículos de JavaScript)  Más información   Referencia de encadenamiento opcional   Null: El error del billón de dólares   Cómo deshacerse de los IF molestos para siempre   ¿QUÉ?  Créditos   Foto de   en  engin akyurt Unsplash  El que pelea con monstruos debe tener cuidado de no convertirse en un monstruo. Y si miras por mucho tiempo a un abismo, el abismo también te mira a ti.   Nietzsche  Code Smell 150 - Comparación igual    Cada desarrollador compara los atributos por igual. Están equivocados.  TL; DR: No exporte y compare, solo compare.  Problemas  Rotura de encapsulación  Duplicación de código  Violación de ocultación de información  Violación  del antropomorfismo  Soluciones  Ocultar la comparación en un solo método  Contexto  La comparación de atributos se usa mucho en nuestro código.  Tenemos que centrarnos en el comportamiento y las responsabilidades.  Es responsabilidad de un objeto compararlo con otros objetos. No el nuestro.  Los optimizadores prematuros nos dirán que esto tiene menos rendimiento.  Deberíamos pedirles evidencia real y contrastar la solución más mantenible.  Código de muestra  Equivocado   if (address.street == 'Broad Street') { if (location.street == 'Bourbon St') { // 15000 usages in a big system // Comparisons are case sensitive  Derecho   if (address.isAtStreet('Broad Street') { } // ... if (location.isAtStreet('Bourbon St') { } // 15000 usages in a big system function isAtStreet(street) { // We can change Comparisons to // case sensitive in just one place. }  Detección    Semiautomático [x]  Podemos detectar comparaciones de atributos utilizando árboles de sintaxis.  Puede haber buenos usos para tipos primitivos como con muchos otros olores.  Etiquetas  Encapsulación  Conclusión  Necesitamos poner las responsabilidades en un solo lugar.  Comparar es uno de ellos.  Si algunas de nuestras reglas comerciales cambian, debemos cambiar un   . solo punto  Relaciones   Code Smell 63 - Envidia de características   Code Smell 101 - Comparación con booleanos   Code Smell 122 - Obsesión primitiva  Créditos   Foto de   en  Piret Ilver Unsplash  El comportamiento es lo más importante del software. Es de lo que dependen los usuarios. A los usuarios les gusta cuando agregamos comportamiento (siempre que sea lo que realmente querían), pero si cambiamos o eliminamos el comportamiento del que dependen (introducimos errores), dejan de confiar en nosotros.   Michael plumas  Artículo siguiente: 5 olores de código más.

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Software Engineer and Book Author

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Cómo encontrar las partes apestosas de su código [Parte XXX]

Cómo encontrar las partes apestosas de su código [Parte XXX]

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Telegram: el puente de Crypto Island hacia el continente

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

El modelo Bitcoin UTXO, impulsando un ecosistema único

Telegram: el puente de Crypto Island hacia el continente

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

El modelo Bitcoin UTXO, impulsando un ecosistema único

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps