Feda /dev/ - No Javascript allowed | Página 1149

B

[Borrado] #34441 May '22

#34440 yo me leí el clean code en su día, y como todo, algunas cosas están bien porque claro, alguna tienes que acertar después de escribir tanta letra xddd

Pero solo hay que ver a todas las peliazules adorarlo como su dios, ahí sabes que tienes que ir por el camino contrario, igual que si usas alguno de los lenguajes que menciona arnau

1 1 respuesta

desu #34442 May '22

#34441 Decidme cosas que creeis que esta bien.

porque entre que java no es oop real
y la oop esta deprecated ...

que puede estar bien?

lo digo en serio, si alguien quiere pasarme algo lo miro.

3 respuestas

Kaledros #34443 May '22

#34442 Bien en el sentido de aguantar cualquier caso de uso, ninguno. Bien de aguantar bastante tralla antes de desmontarse, conceptos como que un método sólo debería hacer una cosa, pero claro, es lo que dice el artículo: define "cosa" y luego hablamos.

1 respuesta

desu #34444 May '22

#34443 voy a hacer un matiz.

para un programador experto, ese libro es una mierda.

cuanto mas novato eres, obviamente mas puedes aprender de ideas "generales".

pero estas ideas generales cuando entramos en performance... optimizacion... compiladores... networking... programacion funcional u otros paradigmas como arrays... pues se van a la mierda.

por eso recomiendo aprender un poquito de todo.

B

[Borrado] #34445 May '22

#34442 básicamente que las funciones deben tener como mucho 20 líneas, que no deben tener side efects, que se enseña con práctica y no con teoría, recuerdo una página que decía algo como:

Puedo enseñarte toda la teoría sobre montar en bicicleta, pero la primera vez que te subas te caerás

También tiene razón en lo de pasar valores booleanos como parámetros a las funciones para que hagan o dejen de hacer algo en función de ese valor.

Con lo de los comentarios también acierta, los usamos para intentar explicar lo que hace la mierda de código que hemos programado.

En fin, que hay cosas que comparto

1 1 respuesta

Fyn4r #34446 May '22 Inocente

para un programador experto, ese libro es una mierda.

Me acabas de recordar a que hace un par de semanas estaba mirando comentarios sobre noséquelibro que no recuerdo ahora mismo. Y me encontraba cosas en plan "es que si ya sabes de X, Y, Z y \alpha este libro no te va a aportar nada". Ajam, gran ayuda

desu #34447 May '22

lo de las lineas es una tonteria... y lo de los side effects pues mas o menos, lo imoprtante es tenerlos controlados y usar el sistema de tipado para ayudarte si puedes. Optional, Result... Ambas cosas son teoria de dise;o de compiladores....

#34445vago_21:
También tiene razón en lo de pasar valores booleanos como parámetros a las funciones para que hagan o dejen de hacer algo en función de ese valor.

en desacuerdo 100%. de hecho es un anti pattern. puedes explayar mas?

1 respuesta

B

[Borrado] #34448 May '22

#34447 me refiero, que pasar booleanos dice en el libro que es una mala práctica, y lo comparto 100%, ensucia el código y lo hace menos autoexplicativo

1 respuesta

desu #34449 May '22

#34448 pff es que ese tema de booleanso tiene que ver con el compilador y la performance sabes?

si luego le pasas en lugar de un booleano una clousure y lo llama strategy pattern ya esta bien? porque segun el seguramente hay que hacer algo de OOP como solucion no?

en fin, que estos libros no valen para nada porque no son especificos. nuestro dia a dia es concreto. resolvemos problemas. no hacemos mierda de clases abstractas para limpiarnos el culo.

1 respuesta

B

[Borrado] #34450 May '22

#34449desu:

nuestro dia a dia es concreto. resolvemos problemas. no hacemos mierda de clases abstractas para limpiarnos el culo

totalmente

Soltrac #34451 May '22 MV Wizard

First world problems...que de vueltas para una chorrada xD

2 respuestas

TheBrotha #34452 May '22

#34451 Pero tu que opinas, debería #34435 ir a dejar el dinero que se ha encontrado a comisaria?

1 1 respuesta

eondev #34453 May '22

#34442 https://ziglang.org/

Recomendar zig con esa puta mierda de sintaxis lmao, eso si que no está bien

spoiler

const std = @import("std");
const json = std.json;
const payload =
    \\{
    \\    "vals": {
    \\        "testing": 1,
    \\        "production": 42
    \\    },
    \\    "uptime": 9999
    \\}
;
const Config = struct {
    vals: struct { testing: u8, production: u8 },
    uptime: u64,
};
const config = x: {
    var stream = json.TokenStream.init(payload);
    const res = json.parse(Config, &stream, .{});
    // Assert no error can occur since we are
    // parsing this JSON at comptime!
    break :x res catch unreachable;
};
pub fn main() !void {
    if (config.vals.production > 50) {
        @compileError("only up to 50 supported");
    }
    std.log.info("up={d}", .{config.uptime});
}

1 respuesta

desu #34454 May '22

#34453 esa sintaxis te parecer fea.

pero todo encaja a la perfeccion. es una sintaxis que leyendo interpretas la semantica a la perfeccion. es un lenguaje donde no hay "excepciones" ni cosas raras. no te protege de undefineds como Rust. pero te dice en todo momento lo que pasa. lo que lees es lo que hay.

y esto para la gente que queremos trabajar y hacer nuestras cosas sin perder el tiempo en entender porque algo no funciona. es la clave.

fijate como hace const std para importar la std lib... da igual si es un modulo, una variable, un struct... siempre es lo mismo.

que quieres un struct con un metodo dentro?

const Room = struct {
    active_connections: std.ArrayList(?Connection),

pub fn init(allocator: std.mem.Allocator) Room {
    return Room{
        .active_connections = std.ArrayList(?Connection).init(allocator),
    };
}
};

que quieres hacer OOP? pues dentro de un struct metes otro struct.

que quieres hacer dynamic dispatch? pues en el struct de dentro, usas la funcion del padre... y asi.

es todo intuitivo y facil de seguir. si quieres una interface pues te haces un map y te guardas los punteros de las funciones. enhorabuena, tu primera vtable pajeet.

el problema que tiene es la stdlib de momento.

1 respuesta

Soltrac #34455 May '22 MV Wizard

#34454

#34454desu:
si quieres una interface pues te haces un map y te guardas los punteros de las funciones. enhorabuena, tu primera vtable pajeet.

No, si va a parecer que estoy abriendo el IDA. Que loco j3j3.

Soltrac #34456 May '22 MV Wizard

#34452 No te puedes hacer rico sin robar algo

desu #34457 May '22

#34451 estoy completamente de acuerdo contigo por cierto.

yo nunca suelo hablar de estilo o cosas asi, cargo fmt, go format... y demas herramientas y lo que salga.

luego el codigo si veo que puedo mejorar algo porque es mas testeable o arregla un bug lo hago, sino pues me la pela.

si alguien hace algo raro, paso de comentarlo a no ser que sea bug (performance y eficiencia tambien). ya lo arreglare otro dia XD

creo que la mayoria de gente presta demasiada atencion a estas cosas... hoy yo refactorizo y lo hago asi, otro dia tu lo tocas y lo haces asa... mientras al final hagamos el curro esta bien.

Kaledros #34458 May '22

¿Vosotros cuando tenéis que implementar algo que no sabéis hacer hacéis una prueba de concepto guarra y luego comiteais antes de refactorizar? ¿Soy yo el único?

4 respuestas

Leos #34459 May '22

#34458 Yo siempre lo hago funcionar, después ya se refactoriza, etc

1 respuesta

Kaledros #34460 May '22

#34459 ¿Pero haces un commit antes de refactorizar por si acaso te toca deshacer o te tiras al ruedo?

1 respuesta

TitoBurns #34461 May '22

#34458
Why not? Y luego push just in case de no perder la faena, son 3 sec literal

B

[Borrado] #34462 May '22

#34458 Consulta con el equipo, si el equipo no responde pues imputo tiempo tiempo a documentarme... si veo que se me va a mas de tres horas informo por la tarea de que se me va a ir de madre. Pero al final termina comiteado... y el tema de refactorizar, en principio no... ya que me diga algo quien revise mi código. No tengo tiempo para refactorizar cosas por amor al arte... tengo que pasar a la siguiente tarea. Pero lo dicho... nuestra forma de trabajar es modular... y si queda "guarrete" en la version 10.0, seguro mejorará en la 11.0 ... ademas que el que lo hizo para 10.0 no tiene que ser el mismo que el que lo hace para 11.0.

Respecto al libro de código limpio me quedo con:

Aprender a crear código limpio es complicado. Requiere algo más que conocer pincipios y patrones. Tiene que sudar. Debe practicarlo y fallar. Debe observar cómo se caen y recuperan el paso. Debe ver cómo agonizan en cada decisión y el precio que pagan por tomar decisiones equivocadas.

Leos #34463 May '22

#34460 Hago commit una vez funciona, después voy refactorizando. Pero es que vivo en una startup que tenemos que sacar las cosas cuanto antes para empezar a vender el producto, así que primero se hace funcionar y luego ya se deja bonito xD

Make it work, Make it right, Make it fast

1 respuesta

B

[Borrado] #34464 May '22

Programación extrema: https://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema la verdadera salud

1 respuesta

Lifecasi0 #34465 May '22

#34464 Eso usamos en mi equipo.

Kaledros #34466 May '22

#34463 Ya, yo lo hago igual, pero me han dicho antes que no debería hacer tantos commits y me he quedado un poco así. Se ve que ahora igual te cobran por commit o algo.

1 respuesta

Leos #34467 May '22

#34466 Pues siempre si es una rama de una task puedes hacer un rebase interactivo o un squash para dejar solo un commit explicativo

desu #34468 May '22

otro dia, otro bug en open source que encontramos

https://github.com/apache/tika

quiero hacer una PR para solucionarlo, es literalmente 1 linea de codigo...

https://github.com/vrnvu/tika/commit/36b0379ffb73b6712dd58156b87f1df5d556b019

pero me obligan a crear un ticket en jira... pues nada que les den por culo.

el bug es que tienen una priority queue, pero no usan la priority para nada XDDDDDDD toma leetcode. devuelven siempre el primer elemento de la lista... y lo que deberian hacer es a;adir al principio.

https://github.com/vrnvu/tika/blob/36b0379ffb73b6712dd58156b87f1df5d556b019/tika-core/src/main/java/org/apache/tika/mime/MimeTypes.java#L580

he creado la PR... a ver si se portan y hacen merge o lo arreglan ellos... es una puta linea de codigo joder.

edit: otro encontrado...

JuAn4k4 #34469 May '22

#34458 Si, pero sin commits, hasta que lo rompo una vez y me cuesta volver a hacer que funcione, es raro pero pasa, y entonces arreglo y hago commit. Luego rebase y listo

LLoid #34470 May '22

Nosotros al mergear a master el GitHub hace squash y se queda todo limpito, así que excepto para el code review que hagas un commit o 2000 nos la zurra

Y casi que ni para el code review te importan los commits, porque al final miramos la tab de code changes que está ahí todo junto y lo miras por encima y compruebas que haya algún test, le pones un LGTM y al carrer

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales