Hispanopedia WikiEn programación informática , un olor a código es cualquier característica del código fuente que sugiere un problema más profundo. [ 1 ] [ 2 ] Determinar qué es y qué no es un olor a código es subjetivo y varía según el lenguaje , el desarrollador y la metodología de desarrollo.
El término fue popularizado por Kent Beck en WardsWiki a finales de la década de 1990. [ 3 ] Su uso aumentó después de aparecer en el libro de 1999 Refactoring: Improving the Design of Existing Code de Martin Fowler . [ 4 ] También es un término utilizado por programadores ágiles . [ 5 ]
Definición
Una forma de ver los olores del código es en relación con los principios y la calidad: "Los olores son ciertas estructuras en el código que indican la violación de principios de diseño fundamentales y afectan negativamente la calidad del diseño". [ 6 ] Los olores del código generalmente no son errores ; no son técnicamente incorrectos y no impiden que el programa funcione. En cambio, indican debilidades en el diseño que pueden ralentizar el desarrollo o aumentar el riesgo de errores o fallas en el futuro. Los malos olores del código pueden ser un indicador de factores que contribuyen a la deuda técnica . [ 1 ] Robert C. Martin llama a una lista de olores del código un "sistema de valores" para la artesanía del software. [ 7 ]
Contrariamente a estas interpretaciones severas, la definición original de Cunningham era que un olor es una sugerencia de que algo puede estar mal, no una evidencia de que ya existe un problema. [ 3 ]
A menudo, el problema subyacente que sugiere un mal olor en el código se puede descubrir al someterlo a un ciclo de retroalimentación breve , donde se refactoriza en pasos pequeños y controlados, y se examina el diseño resultante para detectar otros malos olores que indiquen la necesidad de una mayor refactorización. Desde la perspectiva de un programador encargado de la refactorización, los malos olores en el código son heurísticas que indican cuándo refactorizar y qué técnicas específicas utilizar. Por lo tanto, un mal olor en el código impulsa la refactorización.
Factores como la comprensibilidad del código, la facilidad con la que se puede modificar, la facilidad con la que se puede mejorar para admitir cambios funcionales, la capacidad del código para ser reutilizado en diferentes entornos, la facilidad con la que se puede probar el código y la fiabilidad del código son factores que se pueden utilizar para identificar malos olores en el código. [ 8 ]
Un estudio de 2015 [ 1 ] que utilizó análisis automatizado para medio millón de confirmaciones de código fuente y el examen manual de 9.164 confirmaciones que se determinó que presentaban "malos olores de código" encontró que:
- Existen pruebas empíricas de las consecuencias de la "deuda técnica", pero solo existen pruebas anecdóticas sobre cómo , cuándo o por qué ocurre.
- La sabiduría popular sugiere que las actividades de mantenimiento urgentes y la presión por entregar funcionalidades priorizando el tiempo de comercialización sobre la calidad del código suelen ser las causas de este tipo de problemas.
Herramientas como Checkstyle , PMD , FindBugs y SonarQube pueden identificar automáticamente los problemas de código.
Ejemplos
Olores a nivel de aplicación
- Código duplicado
- Código idéntico o muy similar que existe en más de una ubicación.
- cirugía de escopeta
- un único cambio que debe aplicarse a varias clases al mismo tiempo.
Olores propios de una clase
- Clase grande, también conocido como objeto dios
- una clase que contiene demasiados tipos o que contiene muchos métodos no relacionados.
- Legado rechazado
- una clase que sobrescribe un método de una clase base de tal manera que el contrato de la clase base no es respetado por la clase derivada , violando el principio de sustitución de Liskov .
- Uso excesivo de literales o números mágicos
- Estos deben codificarse como constantes con nombre para mejorar la legibilidad y evitar errores de programación. Además, los literales pueden y deben externalizarse en archivos/scripts de recursos u otros almacenes de datos, como bases de datos, siempre que sea posible, para facilitar la localización del software si se pretende implementarlo en diferentes regiones. [ 9 ]
- Desanimado
- una conversión de tipo que rompe el modelo de abstracción; la abstracción puede tener que ser refactorizada o eliminada. [ 10 ]
- Agrupación de datos
- Ocurre cuando un grupo de variables se pasan juntas en distintas partes del programa. En general, esto sugiere que sería más apropiado agrupar formalmente las diferentes variables en un solo objeto y pasar únicamente ese nuevo objeto. [ 11 ] [ 12 ]
olores a nivel de método
- Demasiados parámetros
- Una larga lista de parámetros es difícil de leer y complica la llamada y la prueba de la función. Puede indicar que el propósito de la función está mal concebido y que el código debería refactorizarse para que la responsabilidad se asigne de forma más clara. [ 13 ]
Véase también
- Antipatrón : solución a un problema que puede ser de uso común, pero que generalmente es una mala elección.
- Olor a diseño : término en programación informática.
- Lista de herramientas para el análisis estático de código
- Deterioro del software : Degradación o pérdida de la funcionalidad del software con el tiempo.
Referencias
- 1 2 3 Tufano, Michele; Palomba, Fabio; Bavota, Gabriele; Oliveto, Rocco; Di Penta, Massimiliano ; De Lucia, Andrea; Poshyvanyk, Denys (2015). "Cuándo y por qué tu código empieza a oler mal" (PDF) . 2015 IEEE/ACM 37.ª Conferencia Internacional IEEE sobre Ingeniería de Software . págs. 403–414 . CiteSeerX 10.1.1.709.6783 . doi : 10.1109/ICSE.2015.59 . ISBN 978-1-4799-1934-5. S2CID 59100195 .
- ↑ Fowler, Martin. "CodeSmell" . martinfowler.com/ . Consultado el 19 de noviembre de 2014 .
- 1 2 Beck, Kent. "Code Smells" . WikiWikiWeb . Ward Cunningham . Consultado el 8 de abril de 2020 .
- ↑ Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code . Addison-Wesley. ISBN 978-0-201-48567-7.
- ↑ Binstock, Andrew (27 de junio de 2011). "Elogio del código pequeño" . Information Week . Recuperado el 27 de junio de 2011 .
- ↑ Suryanarayana, Girish (noviembre de 2014). Refactoring for Software Design Smells . Morgan Kaufmann. pág. 258. ISBN 978-0128013977.
- ↑ Martin, Robert C. (2009). "17: Olores y heurísticas". Clean Code: A Handbook of Agile Software Craftsmanship . Prentice Hall. ISBN 978-0-13-235088-4.
- ^ Suryanarayana, Girish, Ganesh Samarthyam y Tushar Sharma. Refactorización para olores de diseño de software: gestión de la deuda técnica / Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma. 1ª edición. Waltham, Massachusetts; Morgan Kaufmann, 2015. Imprimir.
- ↑ "Constantes y números mágicos" . Consultado el 3 de noviembre de 2020 .
- ↑ Miller, Jeremy. "El downcasting es un olor a código" . Archivado del original el 16 de febrero de 2019. Recuperado el 4 de diciembre de 2014 .
- ↑ Fowler, Martin. "DataClump" . Consultado el 3 de febrero de 2017 .
- ↑ "Patrones de diseño y refactorización" . sourcemaking.com . Consultado el 4 de febrero de 2017 .
- ↑ "Mal olor a código 10: Demasiados argumentos" .
Lecturas adicionales
- Garousi, Vahid; Küçük, Barış (2018). "Mal olor en el código de prueba de software: una revisión del conocimiento en la industria y la academia". Journal of Systems and Software . 138 : 52–81 . doi : 10.1016/j.jss.2017.12.013 .
- Sharma, Tushar; Spinellis, Diomidis (2018). "Un estudio sobre los malos olores del software" . Journal of Systems and Software . 138 : 158–173 . doi : 10.1016/j.jss.2017.12.034 .
Enlaces externos
- "CodeSmell" . martinfowler.com . Consultado el 1 de marzo de 2022 .
- Boundy, David, Cáncer de software: las siete señales de alerta temprana o aquí , ACM SIGSOFT Software Engineering Notes, Vol. 18 No. 2 (abril de 1993), Association for Computing Machinery, Nueva York, NY, EE. UU.
- Folclore de la programación informática
- Folclore de la ingeniería de software
