Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




B

#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

#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

#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

#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

#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

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

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

#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

#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
#34449desu:

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

totalmente

Soltrac

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

2 respuestas
TheBrotha

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

1 1 respuesta
eondev

#34442 https://ziglang.org/

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

spoiler
1 respuesta
desu

#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

#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

#34452 No te puedes hacer rico sin robar algo

desu

#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

¿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

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

1 respuesta
Kaledros

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

1 respuesta
TitoBurns

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

B

#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

#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

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

1 respuesta
Lifecasi0

#34464 Eso usamos en mi equipo.

Kaledros

#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

#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

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

#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

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