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

JuAn4k4 #51091 27 Nov

Para que quieres hacer rollback ? Si todo funciona perfecto.
Para que quiere logs ? Si el problema es de los demás servicios
Para que quieres saber hacer la O con un canuto?, si los demás no saben lo que es un canuto.

1

laZAr0 #51092 27 Nov Cofarde

#51075 pero para eso en el compose puedes poner directamente la policy restart: always/on-failure/etc, ¿no?

edit: vale ya he visto que se ha comentado.

desu #51093 27 Nov

"Se esta solo en la cima"

1 respuesta

GaN2 #51094 27 Nov Inocente

#51093 No te da ni para ventanas ni paredes, se debe de pasar frío en la cima

2

eXtreM3 #51095 27 Nov

La fina línea entre desarrollar echando hostias con acoplamiento y la sobreingeniería.

2 respuestas

desu #51096 27 Nov

#51095 define acoplamiento... porque el acomplamiento es bueno. como mas acoplado el codigo a la solucion mejor y mas eficiente. lo que quieres es que sea modular.

no hay ninguna fina linea, toda la arquitectura de software esta mal. es. una rama de la informatica erronea de base.

1 respuesta

laZAr0 #51097 27 Nov Cofarde

Alto acoplamiento y baja cohesión. Cualquier fpero sabe eso.

1 respuesta

hda #51098 28 Nov Agujeros negros ( ͡° ͜ʖ ͡°)

@desu vaya problema tienes con los "fperos" jajajajajaja. Indica en el muñeco dónde te han tocado

#51095 #51097 ¿A qué os referís con acoplamiento?, primera vez que escucho el término.

2 respuestas

eXtreM3 #51099 28 Nov

#51096 realmente acoplamiento es la dependencia entre módulos. Y no, el acoplamiento no es bueno (al menos no siempre).

¿Es bueno que tus casos de uso estén acoplados al framework?
¿Es bueno que en la capa de infraestructura introduzcas reglas de negocio?

#51096desu:
toda la arquitectura de software esta mal

¿Cómo? Explícate.

#51098 el acoplamiento es la dependencia que tienen unas partes del código con otras. Lo ideal es tener el menor acoplamiento posible para mejorar la mantenibilidad, escalabilidad y reutilización.

1 3 respuestas

laZAr0 #51100 28 Nov Cofarde

Si te tienes que desnudar entero para cagar, acoplamiento patológico.

hda #51101 28 Nov Agujeros negros ( ͡° ͜ʖ ͡°)

#51099 por ejemplo, en mi pipeline entran ficheros y salen ficheros en cada eslabón de la cadena. Estos ficheros son tablas de datos. Es requisito que los headers de esas tablas sean correctos para que los datos puedan seguir su curso. ¿Esto es acoplamiento? Si es así, ¿cómo minimizarlo?

1 respuesta

eXtreM3 #51102 28 Nov

#51101 diría que sí. Si cambias algo de código o de formato en alguna de las partes de la pipeline te implica automáticamente tener que cambiar más partes sí o sí para que funcionen?

¿Para minimizarlo? En tu caso para la pipeline no me atrevo a aventurarme mucho porque está fuera de mi ámbito, pero para el código podría darte un par de consejos concretos.
El primero sería que hicieras una capa que se encargue de la lectura y escritura de los ficheros (aquí podrías validar y transformar los headers, por ejemplo. Así si alguna vez te cambian, sólo los cambiarás aquí)
El segundo sería que, si has programado orientado a objetos, te fijes en la S de SOLID (una clase debe hacer una cosa y, por lo tanto, debe tener una sola razón para cambiar)

1

JuAn4k4 #51103 28 Nov

#51099 Creo que intenta decir que la cohesión es buena, o que sea simple ya que habla de acoplarse a la solución, que no se realmente que significa.

Tuskus #51104 28 Nov

Ojala acoplarme con alguna, que estoy muy solo.

2

Wei-Yu #51105 28 Nov

acoplamiento no sólo ocurre a nivel de código, diría que eso muchas veces es más un síntoma de, porque nace de algo conceptual u organizativo

al menos como normalmente se entiende el término, que hasta donde sé, se aplica a bounded contexts o responsabilidades de capas que se han mezclado

desu #51106 28 Nov

#51098hda:
A qué os referís con acoplamiento?, primera vez que escucho el término.

Nadie sabe a que se refieren con acoplamiento, encapsulamiento, bounded context, evento o dominio...

Cada maestrillo tiene su librito.

Los fperos hablan y hablan, y cuando hablan mucho se convierten en seniors, y cuando usan muchas palabras gordas digievolucionan a evangelistas del software. Mismo fpero sucio.

#51099 el acoplamiento es el numero de dependencias? lol pues llamalo numero de dependencias... es que...

todo esos conceptos solo son fumadas para fperos

estan mal y promocionan malas practicas

1 respuesta

Fyn4r #51107 28 Nov Inocente

No hay mayor síntoma de fperitis que decirle a desu que se explique

1

Wei-Yu #51108 28 Nov

hay que reconocer que desu ha entrado en otro estadio evolutivo porque ya no recurre al stream of consciousness

1 respuesta

desu #51109 28 Nov

es que estos fperos no se que se piensan. esto no es ninguna opinion. estoy diciendo lo que es. si tu no lo entiendes es porque eres un fpero. el dia que dejas de ser un fpero entenderas porque la arquitectura de software esta toda mal. el oop esta todo mal. y demas cosas de fperos.

hay dos tipos de personas, los fperos y los ingenieros.

tu a un bebe que se caga en los pañales no le explicas porque f = m*a. le cambias el pañal cagao y meao.

#51108 despues de sufrir acoso laboral durante un par de semanas prefiero no hacerlo

Wei-Yu #51110 28 Nov

que te ganen al futbolín no es mobbing

eXtreM3 #51111 28 Nov

#51106desu:
el acoplamiento es el numero de dependencias? lol pues llamalo numero de dependencias... es que...

No he dicho eso, a ver si mejoras esa comprensión lectora, ingeniero.

Las dependencias no son en absoluto malas. Lo que es malo, por ejemplo, es lo que ha comentado el compañero de mezclar responsabilidad de capas. Eso es malo y está mal, te guste o no, y se soluciona con una buen arquitectura. Eso es lo que en parte se conoce como acoplamiento.

Lo demás son fumadas tuyas.

1 respuesta

desu #51112 28 Nov

#51111eXtreM3:
mezclar responsabilidad de capas

que signfica eso? puedes traducirlo de "vende humos" / "fpero" a algo que entienda una persona normal?

"La arquitectura de software esta bien porque la arquitectura de software dice que esta bien y un profesor de arquitectura de software me lo ha explicado"

El nivel !!! Explicamelo o habla sin usar terminos de arquitectura de software por favor. Demuestrame tus frases objetivamente.

2 respuestas

Kaledros #51113 28 Nov

Ni siquiera el acoplamiento es siempre malo, pero no le digas eso a gente que se gana la vida enseñando lo contrario.

1 respuesta

eXtreM3 #51114 28 Nov

#51112 me lo estás diciendo en serio? Como sé que estás trolleando te voy a poner un ejemplo muy sencillo y ya corto el tema.

Arquitectura hexagonal, capas aplicación, dominio e infraestructura. ¿Harías la implementación del consumo de una API de terceros en la capa de aplicación?

No, verdad? Pues si lo haces te has acoplado.

Harías una mutación (por ejemplo un cambio de estado) de una entidad desde varios puntos distintos de tu aplicación? No, verdad? Lo unificarías y seguirías el principio de responsabilidad única.

Troll.

#51113 nadie habla de siempre o nunca. Hay casos y proyectos donde da igual.

1 respuesta

Wei-Yu #51115 28 Nov

alguien:

Arquitectura hexagonal

desu cuando tiene mucho tiempo libre:

11

eXtreM3 #51116 28 Nov

jajaja here we go

Wei-Yu #51117 28 Nov

En el equipo de $COMPANY te están buscando más que busco yo al Suchard

Hoooola Wei-Yu! Cómo va el cambio de hora? Yo eso de que a las 6 de la tarde anochezca nunca lo llevo bien, pero si te sirve de consuelo (a mí me funciona), pienso en que empieza la etapa de comer Suchard, y se me quita todo lo malo

En fin, no me quiero andar con rodeos! Después de ver tu perfil, no he podido evitar no hablarte de la posición Senior Backend Developer [...]

2 respuestas

Kaledros #51118 28 Nov

#51117 Estoy seguro de que hay un nombre para definir eso de que cuanto más emojis, más lenguaje colega y más rodeos, más puta mierda la oferta y la empresa.

1 respuesta

Fyn4r #51119 28 Nov Inocente

#51118 Teniendo en cuenta que le gusta el Suchard, o la empresa es Kraft o es gilipollas

1 respuesta

desu #51120 28 Nov

#51114eXtreM3:
¿Harías la implementación del consumo de una API de terceros en la capa de aplicación?

No tendria capa de aplicacion.

#51114eXtreM3:
Harías una mutación (por ejemplo un cambio de estado) de una entidad desde varios puntos distintos de tu aplicación? No, verdad? Lo unificarías y seguirías el principio de responsabilidad única.

No estoy de acuerdo. Por que no iba a mutar una variable? De hecho ya sabeis que yo defiendo que todo sea publico.

El encapsulamiento esun concepto que se quedo deprecated en el 1980-1984 o asi.. No tiene ningun sentido. Lo que quieres es modulos y eso se invento sobre el 1985. Año arriba, año abajo. Hablamos de principios de los años 80s.

No tienes ni idea de programar ni porque programas como lo haces, asi de simple. Sigues arquitectura de software porque es lo unico que conoces. No piensas por ti mismo ni razonas el porque.

1 respuesta

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales