Puedes pulir el código que nadie toca mientras se queman los puntos fuertes reales 
 
 TL;DR: No pierdas el tiempo refactoring el código que nunca cambia; centrarse en áreas de problema modificadas con frecuencia. TL;DR: No pierdas el tiempo refactoring el código que nunca cambia; centrarse en áreas de problema modificadas con frecuencia. Problemas 
 
 
 
 
 
 
 Un esfuerzo perdido Prioridades equivocadas Problemas reales perdidos La productividad del equipo disminuye Desalocación de recursos Falso sentimiento de progreso Soluciones 
 
 
 
 
 
 Análisis de la frecuencia de cambio Identificar los hotspots Uso de los datos de control de versión Enfoque en áreas activas Código de medida churn Recuperación ️ https://hackernoon.com/refactoring-021-remove-dead-code?embedable=true Contexto Este es el olor anti-código. Usted se encuentra con código feo con condicionantes complejos, funciones largas y malos nombres. Recuerda el lema del tío Bob de dejar el campamento mejor que cuando lo encontró. Tu instinto de refacción se inicia, y pasas días limpiándolo. Te sientes productivo, pero estás perdiendo tu tiempo. El mal código sólo es problemático cuando . you need to change it El código estable, incluso si está mal escrito, no daña su productividad. La verdadera deuda técnica reside en los hotspots de código: áreas que son problemáticas y frecuentemente modificadas. La mayoría de las bases de código siguen una distribución extrema donde . 5% del código recibe el 90% de los cambios Sin analizar el historial de control de versiones, no se puede identificar qué código desordenado realmente importa. Usted acaba arreglando las cosas equivocadas mientras que los problemas reales permanecen intactos. Debe abordar la deuda técnica priorizando el código con mala calidad y alta frecuencia de cambios. Todo lo demás es optimización prematura disfrazada de artesanía. Código de muestreo equivocado 🙂 # This authentication module hasn't changed in 3 years
# It's deprecated and will be removed next quarter
# But you spend a week "improving" it

class LegacyAuthenticator:
    def authenticate(self, user, pwd):
        # Original messy code from 2019
        if user != None:
            if pwd != None:
                if len(pwd) > 5:
                    # Complex nested logic...
                    result = self.check_db(user, pwd)
                    if result == True:
                        return True
                    else:
                        return False
        return False

# After your "refactoring" (that nobody asked for):
class LegacyAuthenticator:
    def authenticate(self, user: str, pwd: str) -> bool:
        if not self._is_valid_input(user, pwd):
            return False
        return self._verify_credentials(user, pwd)

    def _is_valid_input(self, user: str, pwd: str) -> bool:
        return user and pwd and len(pwd) > 5

    def _verify_credentials(self, user: str, pwd: str) -> bool:
        return self.check_db(user, pwd)

# Meanwhile, the actively developed payment module
# (modified 47 times this month) remains a mess
 Derecho # You analyze git history first:
# git log --format=format: --name-only | 
# grep -E '\.py$' | sort | uniq -c | sort -rn

# Results show PaymentProcessor changed 47 times this month
# And it does not have good enough coverage
# LegacyAuthenticator: 0 changes in 3 years

# Focus on the actual hotspot:
class PaymentProcessor:
    # This gets modified constantly and is hard to change
    # REFACTOR THIS FIRST
    def process_payment(self, amount, card, user, promo_code,
                       installments, currency, gateway):
        # 500 lines of tangled logic here
        # Changed 47 times this month
        # Every change takes 2+ days due to complexity
        pass

# Ignore stable legacy code
# But you can use IA to cover existing functionality
# With acceptance tests validated by a human product owner

class LegacyAuthenticator:
    # Leave this ugly code alone
    # It works, it's stable, it's being deprecated
    # Your time is better spent elsewhere
    def authenticate(self, user, pwd):
        if user != None:
            if pwd != None:
                if len(pwd) > 5:
                    result = self.check_db(user, pwd)
                    if result == True:
                        return True
        return False
 Detección [X] Semi-automático Puede detectar este olor al analizar su historial de control de versiones. Siga qué archivos cambian con más frecuencia y correlacione eso con las métricas de calidad del código. Herramientas como , análisis de registro git, o scripts personalizados pueden mostrar sus puntos fuertes reales. Codificación Seguir su El código que cambia con más frecuencia. defectos excepciones A veces es necesario refactorar el código estable cuando: 
 
 
 
 
 El desarrollo de nuevas características requiere cambios adaptativos Las vulnerabilidades de seguridad requieren correcciones El cumplimiento de la normativa requiere cambios Estás a punto de reactivar las características dormidas La clave es la toma de decisiones intencionadas basadas en datos reales, no en suposiciones. Tags ️ 
 
 La deuda técnica Nivel [X] El Intermedio ¿Por qué es importante la bijeción ️ Mientras construyes una Entre tu código y el comportamiento del mundo real, notarás que algunas partes de tu sistema están cambiando más activamente que otras. Mapa tuya debe reflejar esta realidad. Bijeción Cuando refactor código estable, rompe la correspondencia entre el esfuerzo de desarrollo y el valor real del negocio. Usted trata todo el código de la misma manera en su modelo mental, pero el mundo real muestra patrones de uso extremos donde un pequeño porcentaje de código maneja la gran mayoría de los cambios. Usted se optimiza para un mundo imaginario donde todo el código importa igualmente. La generación Algunos generadores de código sugieren refactoring sin considerar la frecuencia de cambio. Las herramientas de IA y las linternas analizan el código de forma estática y recomiendan mejoras basadas únicamente en patrones, no en el uso. No acceden a su historial de control de versiones para entender qué mejoras realmente importan a menos que usted Diles que lo hagan. explícitamente La IA podría marcar cada función larga o compleja condicional, tratando un método de legado de 500 líneas dormido igual que una función igualmente confusa que modificas diariamente. Detección La IA puede ayudarle a corregir este olor de código si le proporciona el contexto adecuado. Sin esa información, la IA cometerá los mismos errores que los humanos hacen: recomendar refactorings basados puramente en la estructura del código. ¡Pruébelo! Recuerda: los asistentes de IA cometen muchos errores 
 
 Prompt sugerido: Analice el historial de git de esta base de códigos para identificar archivos con alta frecuencia de cambio. Luego revisa las métricas de calidad del código para esos archivos. Recomienda refactorizar sólo la intersección de códigos de alta calidad y de baja calidad. Ignore códigos estables de baja calidad. Prompt sugerido: Analice el historial de git de esta base de códigos para identificar archivos con alta frecuencia de cambio. Luego revisa las métricas de calidad del código para esos archivos. Recomienda refactorizar sólo la intersección de códigos de alta calidad y de baja calidad. Ignore códigos estables de baja calidad. Sin instrucciones adecuadas 
 
 
 
 
 
 
 
 
 
 
 ChatGPT Claude Perplejidad piloto tú Gemini profundidad El objetivo es Grúas Quien Con instrucciones específicas 
 
 
 
 
 
 
 
 
 
 
 ChatGPT Claude Perplejidad piloto tú Gemini profundidad El objetivo es Grúas Quien Conclusión No se puede mejorar la productividad polizando el código que nunca cambia. Sólo importa cuando te ralentiza, lo que ocurre en el código que realmente modificas. La deuda técnica Concéntrese en sus esfuerzos de refactoring donde multiplican su impacto: los puntos calientes donde la mala calidad se encuentra con el cambio frecuente. Todo lo demás es disfrazado de ingeniero de excelencia. procrastination Deja que el código feo estable descanse en paz. Tu tiempo humano es demasiado valioso para desperdiciar en problemas que no existen. Relaciones https://hackernoon.com/code-smell-06-trying-to-be-a-clever-programmer?embedable=true https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-iv-7sc3w8n?embedable=true https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxx?embedable=true https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xii?embedable=true Más información https://www.youtube.com/v/F5WkftHqexQ?embedable=true Disclaimer Los olores son míos . Opinión Créditos Fotografía por es Víctor Keri Unosplash 
 
 La primera regla de la optimización es: No lo hagas; la segunda regla es: No lo hagas todavía. La primera regla de la optimización es: No lo hagas; la segunda regla es: No lo hagas todavía. por Michael A. Jackson https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true Este artículo es parte de la serie CodeSmell. https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

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

Código Olor 318 - Pérdida de tiempo refactoring código sucio

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

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

Telegram: el puente de Crypto Island hacia el continente

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

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

Telegram: el puente de Crypto Island hacia el continente

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps