paint-brush
Cómo encontrar las partes apestosas de su código [Parte XVI]por@mcsee
527 lecturas
527 lecturas

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

por Maximiliano Contieri2022/04/06
Read on Terminal Reader
Read this story w/o Javascript

Demasiado Largo; Para Leer

¡Huele a código infinito! 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. No son obligatorios fijos per se... (Deberías investigarlo).

People Mentioned

Mention Thumbnail

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - Cómo encontrar las partes apestosas de su código [Parte XVI]
Maximiliano Contieri HackerNoon profile picture

Foto de Filipe Resmini en Unsplash

¡Código infinito, huele!


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. No son obligatorios fijos per se... (Deberías investigarlo).

Olores de código anteriores

Continuemos...

Code Smell 76 - Afirmaciones genéricas

No haga pruebas débiles para crear una falsa sensación de cobertura.



TL; DR: las afirmaciones de prueba deben ser precisas. No demasiado vago y no demasiado específico. No hay bala de plata.

Problemas

  • falsos negativos
  • Falta de confianza

Soluciones

  1. Compruebe el caso correcto.
  2. Afirmar para un caso funcional.
  3. No pruebe la implementación.

Código de muestra

Equivocado

 square = Square(5) assert square.area() != 0 # This will lead to false negatives since it is too vague

Derecha

 square = Square(5) assert square.area() = 25 # Assertion should be precise

Detección

Con las técnicas de Mutation Testing podemos encontrar estos errores en nuestras pruebas.

Etiquetas

  • Pruebas

Conclusión

Deberíamos usar técnicas de desarrollo como TDD que solicitan casos comerciales concretos y hacen afirmaciones concretas basadas en nuestro dominio.

Relaciones

Code Smell 30 - Burlarse del negocio

Code Smell 52 - Pruebas frágiles

Más información

Créditos

Este olor fue inspirado por @Mario Cervera y usado con su permiso .

Foto de Fleur en Unsplash


Un programa que produce resultados incorrectos el doble de rápido es infinitamente más lento.

Juan Osterhout



Code Smell 77 - Marcas de tiempo

Las marcas de tiempo son ampliamente utilizadas. Tienen una autoridad emisora central y no retroceden, ¿verdad?



TL; DR: no use marcas de tiempo para la secuencia. Centraliza y bloquea tu emisor.

Problemas

  • Falla de biyección.
  • Colisiones de marcas de tiempo.
  • Precisión de marca de tiempo.
  • Trastornos de paquetes.
  • Mala Implementación Accidental (Timestamp) para un Problema Esencial (Secuenciación).

Soluciones

  1. Utilice un estampador secuencial centralizador. (NO, no es un Singleton ).
  2. Si necesita modelar una secuencia, modele una secuencia .

Código de muestra

Equivocado

 # using time module import time # ts stores the time in seconds ts1 = time.time() ts2 = time.time() #might be the same!!

Derecha

 numbers = range(1, 100000) #create a sequence of numbers and use them with a hotspot #or sequence = nextNumber()

Detección

Las marcas de tiempo son muy populares en muchos idiomas y son omnipresentes.

Necesitamos usarlos solo para modelar... marcas de tiempo.

Etiquetas

  • biyección

Conclusión

Este olor se inspiró en una falla reciente del software Ingenuity .


Si no seguimos las reglas de MAPPER y las secuencias de modelos con el tiempo, nos enfrentaremos a problemas.


Afortunadamente, Ingenuity es un vehículo autónomo sofisticado y tiene un sólido software de aterrizaje a prueba de fallas.


Este video describe la falla.

https://www.youtube.com/watch?v=6IoMiwxL2wU

Relaciones

Código olor 39 - nueva fecha ()

Código Olfato 32 - Singletons

Code Smell 71 - Flotadores mágicos disfrazados de decimales

Más información


El código más hermoso, las funciones más hermosas y los programas más hermosos a veces no están allí.

jon bentley


Code Smell 78 - Infierno de devolución de llamada

Procesar un algoritmo como una secuencia de devoluciones de llamadas anidadas no es inteligente.


TL; DR: no procese las llamadas en forma de devolución de llamada. Escribe una secuencia.

Problemas

  • Legibilidad
  • Difícil de depurar.
  • Complejidad

Soluciones

  1. Cambie las devoluciones de llamadas a secuencias de llamadas.
  2. Extraer código repetido
  3. Refactorizar.

Código de muestra

Equivocado

 var fs = require('fs'); var fileWithData = '/hello.world'; fs.readFile(fileWithData, 'utf8', function(err, txt) { if (err) return console.log(err); txt = txt + '\n' + 'Add Data!'; fs.writeFile(fileWithData, txt, function(err) { if(err) return console.log(err); console.log('Information added'); }); });

Derecha

 var fs = require('fs'); function logTextWasAdded(err) { if(err) return console.log(err); console.log('Information added'); }; function addData(error, actualText) { if (error) return console.log(error); actualText = actualText + '\n' + 'Add data'; fs.writeFile(fileWithData, actualText, logTextWasAdded); } var fileWithData = 'hello.world'; fs.readFile(fileWithData, 'utf8', addData);

Detección

Este problema brilla a simple vista. Muchos linters pueden detectar esta complejidad y advertirnos.

Etiquetas

  • Legibilidad
  • Complejidad

Conclusión

Callback Hell es un problema muy común en los lenguajes de programación con futuros o promesas.

Las devoluciones de llamada se agregan de forma incremental. No hay mucho desorden al principio.

La complejidad sin refactorización los hace difíciles de leer y depurar.

Relaciones

Code Smell 06 - Programador demasiado inteligente

Código Olor 102 - Código de flecha


Hay dos formas de escribir código: escribir código tan simple que obviamente no tiene errores, o escribir código tan complejo que no tiene errores obvios.

tony hoare



Código olor 79 - El resultado

Si ya se usa un nombre, siempre podemos prefijarlo con 'the'.



TL; DR: no anteponga sus variables.

Problemas

  • Legibilidad
  • nombres sin sentido

Soluciones

  1. Usa nombres reveladores de intenciones.
  2. Evite las palabras ruidosas indistintas .

Código de muestra

Equivocado

 var result; result = getSomeResult(); var theResult; theResult = getSomeResult();

Derecha

 var averageSalary; averageSalary = calculateAverageSalary(); //.. var averageSalaryWithRaises; averageSalaryWithRaises = calculateAverageSalary();

Detección

Al igual que con muchas de nuestras convenciones de nomenclatura, podemos indicar a nuestros linters que prohíban nombres como theXxx... .

Etiquetas

  • Legibilidad

Conclusión

Utilice siempre nombres que revelen la intención.

Si sus nombres chocan, use nombres locales, extraiga sus métodos y evite los prefijos 'the'.

Relaciones

Code Smell 38 - Nombres abstractos

Más información

Créditos

Foto de Josue Michel en Unsplash


Una diferencia entre un programador inteligente y un programador profesional es que el profesional entiende que la claridad es el rey. Los profesionales usan sus poderes para el bien y escriben código que otros pueden entender.


Roberto C. Martín


Code Smell 80 - Prueba/captura anidada

Las excepciones son una excelente manera de separar el camino feliz del camino problemático. Pero tendemos a complicar demasiado nuestras soluciones.




TL;DR: No anidar Excepciones. A nadie le importa lo que hagas en los bloques interiores.

Problemas

  • Legibilidad

Soluciones

  1. refactorizar

Código de muestra

Equivocado

 try { transaction.commit(); } catch (e) { logerror(e); if (e instanceOf DBError){ try { transaction.rollback(); } catch (e) { doMoreLoggingRollbackFailed(e); } } } //Nested Try catchs //Exception cases are //more important than happy path //We use exceptions as control flow

Derecha

 try { transaction.commit(); } catch (transactionError) { this.withTransactionErrorDo( transationError, transaction); } //transaction error policy is not defined in this function //so we don't have repeated code //code is more readable //It is up to the transaction //and the error to decide what to do

Detección

Podemos detectar este olor utilizando árboles de análisis.

Etiquetas

  • Excepciones

Conclusión

No abuse de las excepciones, no cree clases de excepción que nadie detectará nunca y no esté preparado para todos los casos (a menos que tenga un buen escenario real con una prueba de cobertura).

El camino feliz siempre debe ser más importante que los casos de excepción.

Relaciones

Code Smell 73 - Excepciones para casos esperados

Code Smell 26 - Excepciones Contaminantes

Más información

Créditos

Foto de David Clode en Unsplash

Gracias a @Rodrigo por su inspiración


Pío


Escribir software como si fuéramos la única persona que tiene que comprenderlo es uno de los mayores errores y suposiciones falsas que se pueden cometer.


Carolina Szczur


Y eso es todo por ahora…

¡El próximo artículo explicará 5 olores de código más!