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.

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

Demasiado Largo; Para Leer

In your car, at home, or at work — Bosch technology shapes many areas of life.

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

Demasiado Largo; Para Leer

Maximiliano Contieri

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

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

Demasiado Largo; Para Leer

Maximiliano Contieri

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

HISTORIAS RELACIONADAS