Feda /dev/ - No Javascript allowed

#45298desu:

https://taylor.town/black-holes

Este me ha encantado.

2023 y excel no puede abrir dos libros con el mismo nombre

como hariais para mejorar vuestro código si sois el que más sabe de vuestro equipo? (sin ser esto mucho)

Libros, cursos o simplemente seguir practicando e intentando mejorarlo?

Pienso en quizá aprender un lenguaje fuertemente tipado

#45311 uno hace los test y el otro los intenta satisfacer?

#45310 te voy a contar un poco lo que yo hago, no sé si funciona pero bueno xd

Primero define el aspecto concreto a mejorar, ejemplos, estás buscando que el código sea más fácil de testear? Reducir acoplamiento entre componentes? mejorar los tipos de datos de un algoritmo? Simplificar la arquitectura de un servicio? No sé, cosas así, intenta que sean pequeñas y bien acotadas, no quieres acabar con 2 problemas a resolver en vez de uno xd

Sobre contenidos en concreto yo creo que vale todo, blogs, tutoriales, libros, respuestas en stack overflow. Eso si, no se trata de que copies lo que veas, es más bien razonar sobre ello, piensa en cómo X solución de un tutorial afectaría a tu caso de uso concreto, en que se diferencia de lo que tienes montado, etc. Si ves que un contenido no te aporta next, no te fuerces a completarlo porque es perder el tiempo, y siempre puedes volver más adelante.

No sé, supongo que es todo tiempo y práctica

El consejo número uno es que si puedes evitar hacer algo, evítalo. La complejidad es la que mata los proyectos, el objetivo es aportar el máximo valor posible con lo mínimo.

Lo malo es que va totalmente en contra de todo lo que se suele enseñar.

#45325 Si os acordeis yo hace tiempo declare la peor funcion que un programador puede escribir. El anti pattern mas grande y habitual en la programacion.

Puede tener muchas formas pero viene a ser algo de este estilo:

fn some_foo(inputs: []Struct) []Struct {
  const result = []Struct;
  for input, i in inputs { 
     if is_valid(i) {
       result[i] = transform_valid(input);
    } else {  

       result[i] = transform_invalid(input)
   }
   return result
} 

Que da lo mismo si es asi:

fn some_foo(inputs: []Struct) []Struct {
  return inputs.filter(is_valid).map(transform_valid) ++ inputs.filter(is_invalid).map(transform_invalid);
}

O asa:

some_foo inputs = transform_valid filter_valid inputs ++ transform_invalid filter_invalid_inputs inputs

Donde da igual el lenguaje, si es gc o manual memory, la sintaxis, si es OOP o funcional o imperativo... Da igual si esto son arrays, slices o un channel de CSP... da igual si estas trabajando con structs o classes... Da igual.

Si tu ves este patron de codigo, lo que habitualmente es un for loop, iterado o stream... Y no te pitan los ojos. Eres mal ingeniero. Bueno, no eres ingeniero, eres un fpero. Un alinea divs como Miudev.

El anti pattern mas grande que existe.

#45327 En el primer ejemplo no lo hago. Y como digo, puedes suponer que el compilador te optimizara todo ese codigo para que sea la perfeccion absoluta a nivel de memoria, sin alocaciones, y ciclos de cpu. Como si lo escribes a mano en assembly.

Sigue siendo el peor codigo que un programador puede escribir.

No se si alguien se acordara de la solucion ni el porque...

Y te hace un MAL programador, porque como digo, puedes suponer que el compilador sera la perfeccion absoluta a todos los niveles y te hara un assembly optimo que seguira estando MAL.

Un BUEN ingeniero ve el problema al toque.