Feda /dev/ - No Javascript allowed

#10494desu:

Todo en un fichero, mover el código donde toque, refactor en función, pasarlo por parámetro y al toque.

Mira, eso lo tenían así en mi último curro.

Luego los de negocio quisieron meter una llamada a un validador (una mierda de business intelligence) y que dependiendo de lo que devolviera siguiera el flujo normal o se modificaran valores del objeto original (temas de ofertas en negocios). ¿El problema? Era una lista de objetos en la que podían haber perfectamente 5000. Luego 5000 modificaciones de objeto en un forEach después de validar la respuesta de una llamada a servicio. Todo en la misma función de la misma clase que lo hacía todo. "Enrutador", la llamaban, los hijos de puta.

Porque hacer las cosas así, o tienes una buena excusa (que la puede haber, como puede haber un gitano médico) o eres un hijo de puta.

Que gran verdad ha dicho

#10510 a saber la mierda que hiciste que hasta te cambiaste de país

#10515 Comittear con el usuario de otro

#10506 No entiendo tu problematica.

Lo que dices literalmente deberia ser a;adir una funcion a la pipeline.

def pipeline (input) { 
   return getData(input)
   .map(TU_NUEVA_FUNCION)
   .map(f0)
   .map(f1)
}

def TU_NUEVA_FUNCION(elementOfData) {
  return (validador(elementOfData) ? xxxxxxx : yyyyyyyyyyy;
}

A ver que no sepas programar no tiene nada que ver en como organizas el codigo. Depende del lenguaje hay mejores y peores maneras de hacerlo por temas de compilados, namespaces, dependencias...

Si he entendido mal y son dos flujos muy distintos que no puedes seguir con transformaciones... tan solo haces un split, no veria la dificultad, hago cosas asi a diario y no me deberia llevar mas de 10 minutos. Si tus funciones son una puta mierda y no las puedes reutilizar es otro tema.

Tambien me tienen hasta los huevos ultimamente las "funciones" asi:

   sumarNumeros(a, b) {
     return a + b;
}

  restarNumeros(a, b) {
   return a - b;
}

Las extraen porque como como escribes el nombre es legible para el humano, esto es literal del clean code. Esto estaria mal para los clean coders y demas ooperos:

  numericOp(fn, a, b) {
   return fn(a, b);
}

Porque el numericOp no forma parte del dominio..... yo esto reconozco que en su dia lo hacia mucho. Se me quito por suerte rapido la tonteria de funciones concretas para que sean legibles y demas soplapolladas cuando tuve que refactorizar.

Tambien mención especial al que se ha hecho un curso de haskell y hace todo con "Monads" pero solo implican mas trabajo porque en su vida ha picado mas de 1k LOC en haskell y no sabe cuando hay que usarlos. Que esto también me lo encuentro y también lo he hecho.

De nuevo lo que digo se aplica si llevas un proyecto estatico que casi no tocas no pasa nada, pero para dev no puedes hacerlo porque solo perderas tiempo a la larga. Si eres @eondev pues tiene mas sentido tener tonterias de este palo de carnicas, supongo que por eso te lo ense;an en la uni.

#10522desu:

Las extraen porque como como escribes el nombre es legible para el humano, esto es literal del clean code. Esto estaria mal para los clean coders y demas ooperos:

numericOp(fn, a, b) {
return fn(a, b);
}

Vete tú a explicar al típico masilla que coño es una función de orden superior. Además, no todos los lenguajes te permiten esas funcionalidades.

Por otra parte, en la informatica empresarial típica es bastante jodido implementar una aplicación entera como una serie de pipelines, no porque los programas sean complejos, sino porque nunca tienes una especificación de requisitos ni fiable, ni estable.