¿Cuáles son algunos malos olores en la programación?

Cuando me encuentro con estos olores de código “inmediato” sé “aquí hay dragones”.

• Formateo inconsistente: el formateo del código es importante. El código bien formateado ayuda al desarrollador a ver inconsistencias que podrían ser errores o detectar código repetitivo que podría expresarse de manera más concisa. O el codificador original era tan descuidado o inexperto, o había varios codificadores que trabajaban en un ámbito demasiado estrecho.
• Falta total de formateo: hoy en día no es un problema, pero cualquier código que carece de sangría grita “el novato simplemente hackeando las cosas”. Es casi imposible de leer por los mantenedores, y mucho menos el desarrollador original.
• Modificadores de acceso excesivamente público: cuando las propiedades y métodos de los miembros no están estrictamente bloqueados, hay dos problemas generales que parecen seguir:

• El desarrollador original ha abusado del acceso , rompiendo abstracciones y separando preocupaciones. El resultado es el clásico código de espagueti.
• El mantenedor de código usa métodos que cambian fraccionalmente el estado. ¡Loco!

Encuentro esta lista de Patrones de diseño y refactorización para cubrir “olores de codificación” fácilmente evitables razonablemente bien:

Estos son signos generales centrados en la codificación . También debe tener en cuenta cómo hacer las cosas bien al codificar en un idioma específico. Por ejemplo, hay muchas guías de estilo en línea específicas del idioma [1] [2] [3] [4] que pueden ayudarlo a identificar lo que podrían ser malos signos al aprender cuáles son buenos de la experiencia de los desarrolladores detrás del software utilizado por millones de personas diariamente.

Además, como otros han señalado, los antipatrones [5] son ​​”malos olores” de la ingeniería de software cuando se trata de escalar lo que sea que esté construyendo. Estos no se limitan a la codificación, sino que pueden estar presentes en otras partes del proceso (por ejemplo, diseño, pruebas, implementaciones, dependencias, escalado).

Notas al pie

[1] NYTimes / aim-c-style-guide

[2] http://google.github.io/stylegui …

[3] Guía de estilo de Google Python

[4] airbnb / javascript

[5] Patrones de diseño y refactorización

Hay pocas clases de olores, a medida que profundiza en un producto de software.

En el nivel de Arquitectura / Aplicación, encontré dos cosas que me molestaron más:

– Duplicación de código. Si trabaja en una gran organización, entregando una serie de productos, apuesto a que hay una duplicación de código innecesaria en todos los proyectos. Pero incluso dentro de un proyecto

– Complejidad innecesaria . Diseñe patrones que se usan por el simple hecho de usarlos, que simplemente complican el código y hacen el mantenimiento, agregando nuevas características extremadamente engorrosas. Cuanto más tiempo tenga que mantener el código, peor será. Otra forma de agregar complejidad, en un nivel de abstracción más bajo, es hacer que su código cubra todas las situaciones posibles: cubra todas las combinaciones de entrada teóricamente posibles, etc. Sin embargo, a menudo eso significa escribir “código muerto”, el código que nunca se ejecutará. Eso sucede a menudo cuando los codificadores pierden (o no tienen) el “panorama general”: no conocen el dominio de la aplicación lo suficientemente bien, cómo utilizará el software el usuario en el campo.

Si observa el diseño a nivel de clase, puede encontrar una descripción general bastante buena de los olores aquí.

Hay otra cosa más: “antipatrón”. Su pregunta se relaciona con los patrones de ingeniería de software, pero los otros también son interesantes: consulte aquí Anti-patrón

Hola,

Me acaban de asignar a un proyecto donde hay un fuerte abuso del mecanismo de señal / ranura de Qt. Si se usa bien, puede obtener objetos sueltos. Pero en el código actual, las señales y las ranuras aparentemente se usan deliberadamente para ofuscar el código. Tal vez el autor intentó trasladar su pensamiento de brainfuck a C / C ++. Las conexiones y desconexiones son ubicuas. Este es un software integrado, donde varios dispositivos deben comunicarse entre sí. La forma en que el software logra hacerlo tan bien dado su diseño es uno de los mayores misterios de este universo. Por supuesto, no hay tiempo para rediseñar todo y necesito hacer trucos sucios para que los clientes se quejen mucho después de que me haya mudado a otro trabajo.

También en este código: nombres cortos, ininteligibles, variables y una gran cantidad de constantes mágicas. Y nunca se puede saber qué hace la clase “EthernetClient”. Tiene algo de código alrededor de un QTcpSocket, pero para mayor claridad, todo esto ha sido comentado. En cambio, la clase hace una conexión en serie … Lo que falla es que no han redefinido el operador + () para hacer una resta.

Para terminar todo esto, hay muchos comentarios en los que no los necesita y no hay comentarios en los que hubiera sido muy útil.

En resumen, estoy trabajando en una colección de antipatrones. Parece que hay un patrón para usar antipatrones en todo el lugar.

Cuando la forma en que las personas hablan sobre su código, sus pruebas y su proceso de desarrollo, no coincide con la evidencia de sus propios ojos al leer el código.

Siempre lea el código fuente tan pronto como tenga la oportunidad, y decídase sobre su calidad. ¿Está bien factorizado en clases / métodos con un significado claro? ¿Son las piezas de tamaño manejable? ¿Existen funciones / métodos que tienen varios cientos de líneas de largo? ¿Hay comentarios útiles significativos? ¿Lo que dice en los comentarios realmente coincide con lo que hace el código? ¿Maneja los punteros nulos y otros casos de esquina de forma segura? ¿Hay pruebas? Si se encuentra con una combinación de circunstancias que no puede manejar correctamente, ¿falla de una manera fácilmente reconocible? ¿Tiene un enfoque coherente y plausible para todas las fases de la vida útil de un objeto, por ejemplo, inicializar a todos los miembros, tener alguna política comprensible para que el objeto se limpie y libere correctamente todos los recursos? ¿Prueba los códigos de retorno / error en todas las llamadas del sistema o llama a otras bibliotecas y maneja los errores de manera adecuada?

Está bien que algunos tipos de código no sean perfectos en todas estas preguntas. Lo que debería ser una gran bandera roja es leer el código y juzgar que es escamoso / incompleto / con errores / desordenado en varios aspectos, y luego hablar con los desarrolladores y gerentes que anteriormente tenían la responsabilidad sobre él y escucharlos decirle que todo es maravilloso.

Un corolario es que si ha escrito algún código, y alguien viene y le pregunta al respecto, debe estar bien preparado para decirle qué tiene de malo: qué casos no maneja, si va a escalar mal, lo que habría solucionado si hubiera tenido tiempo, brechas en las pruebas.

Ningún código es perfecto. Algún código está “bajo control”, ya que el código actualmente tiene deficiencias, pero esas deficiencias se entienden bien. Y la mayoría del código está fuera de control, porque fue escrito a medias por alguien que solo escribe un código a medias o alguien puede escribir un buen código pero no tuvo el tiempo (esas personas están en demanda de combatir incendios) por todo el lugar).

Como programador de computadoras, los siguientes son algunos malos olores en la programación que siento

1. Formateo
   El formato es muy importante en la programación, un programa debe estar escrito de tal manera que sea comprensible para todos. El uso de punto y coma o llaves en las posiciones correctas lo hace mucho más legible.

MAL ENFOQUE

BUEN ENFOQUE

1. Comentarios
   Los comentarios correctos deben ser el hábito de un programador, los comentarios hacen que el programa sea legible y comprensible, también hace que su programa sea fácil de diagnosticar. Además, si tiene algunos errores en los comentarios de salida, también le ayuda a comprender.
2. Programación procesal
   La programación de procedimientos en estos días es obsoleta, por qué uno debería escribir el mismo código muchas veces cuando puede escribirse una vez y usarse muchas veces con el enfoque OO.
3. Métodos inútiles
   La creación de métodos inútiles o irrelevantes o innecesarios también es común, por ejemplo, ¿crea un método para tomar dos entradas y luego crea otro método para realizar operaciones en ellas? ¿Por qué hacer eso? O, en otro caso, crea un método para tomar datos de entrada y crea otros 4 métodos para operaciones básicas (+ – / *), puede usar un interruptor o if / else para hacer todo eso en un método.

Hay muchos, pero aquí están mis dos favoritos:

1. La trampa booleana:

doSomething (false) // ¿Esto significa * no * lo haces?
doSomething (true) // ¿Esto significa * realmente * hacerlo?

función doSomething (booleanThatControlsSomethingMysterious) {
…
}

Funciones como esta casi siempre deberían ser:

doSomething ({someOption: true})

2. Ye Olde ‘Infinite Loop esperando que suceda’

while (verdadero) {
hacer algo()
si (condición) se rompe
}

Ahora, hay algunos casos en los que usar while (true) está bien, la mayoría de las veces estos son solo fragmentos de código frágiles que esperan causar bloqueos

• Métodos más largos que una pantalla más o menos.
• Métodos que toman parámetros booleanos para cambiar su comportamiento (en su lugar, tienen dos métodos separados y extraen el código común a un método privado).
• Método_y_nombre_de_variable_informable, incoherente e incorrecto. En general, creo que uno debería adherirse a algún estándar, como el esquema de nomenclatura de Java, que realmente funciona y está bien establecido.

En Java / orientado a objetos, los métodos estáticos son generalmente olor a código, aunque hay excepciones, es decir, java.lang.Math. Si todos sus métodos son estáticos, está haciendo algo mal.