Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Ranthas
#38430PiradoIV:

¿Mongo se sigue usando en producción hoy en día? :-/

¿Te acuerdas cuando las no-SQL mataron las bases de datos relacionales? The Buggles ya hicieron una canción parecida en su día, no debe ser coincidencia.

1 1 respuesta
Konishi

#38430 React sigue sin acabar su nueva documentación, para eso en concreto tiré de un cursillo en Udemy.

Lo que creo que me falta más es buenas prácticas y diseño (dentro de lo que debería saber un junior, que sinceramente ya no sé hasta qué punto debería).

Como se podrá intuir mi curro actual es un desmadre donde no hay nadie que de referencia ni marque nada, y de alguna forma el proyecto todavía flota a base de darse de hostias con el u perder la cordura. Esto me lleva a tener muchas dudas sobre mis conocimientos actuales.

(Lo de Mongo también en parte es por probar algo nuevo, ya que todo lo que he hecho ha sido con relacionales)

Kaledros

#38431 Bueno, aún hay gente que cree que puedes usar una NoSQL cuando tus entidades se relacionan entre ellas.

1 respuesta
Lifecasi0

#38433 por poder lo puedes usar, ahi tienes populate() y el aggregator con el $lookup.

1 respuesta
Kaledros

#38434 También puedes usar un .txt XDDD

B

La NoSQL más usada hoy en día debe ser IndexedDB... no tengo pruebas, pero tampoco dudas.

LR

Vosotros aquí hablando de mean, mongo, Next y demás y yo intentando sacar tiempo para ver que ha cambiado desde php 5.2 hasta hoy y montarme algo con lamp en casa.... -_-

1 respuesta
eondev

#38437 anims que todos pasamos por ahí, es la senda del novato. Yo ya no soy ñaper developer, soy mobile ñaper developer y ya me levanto 2k netos al mes.

1 respuesta
LR

#38438 si el problema es que me da toda la pereza volver a php, y cada vez que me pongo termino mirando cosas de Django o node y cuando me centro, son las tantas y toca tirar a la cama xD

1 respuesta
eondev

#38439 pero pq es cosa del curro? Pos lo miras en el curro

1 respuesta
LR

#38440 que va, porque quiero volver a picar código y lo que más use en su día fue php, pero me trae recuerdos del Vietnam... llevo años sin tocar un pc hulio

1 respuesta
_gideon

Vengo a preguntar y a desahogarme.

¿Cómo lidiáis con que vuestros compañeros programen MIERDA? En mi trabajo no ponen más que excusas para implementar PR y code reviews, y aquí todo el mundo sube lo que le da la gana. Mientras funcione, parece que todo el mundo está feliz. Hoy me está tocando añadir una nueva feature a un código spaguetti que parece hecho a mala hostia de lo putamente enrevesado que está y no puedo, no puedo centrarme, solo quiero pegarle un puñetazo a la mesa.

¿Qué hacéis aquí? ¿Habláis con el compañero en cuestión? ¿Refactorizáis? ¿Os tragáis la mala hostia, lo hacéis y pasáis a otra cosa? Dios, es que no puedo.

6 respuestas
B

#38442 en la medida de lo posible intento no refactorizar código que no es mío, si lo rompes pasa a ser problema tuyo. Estas cosas se previenen con buen code review antes de mergear la PR, pero no todas las empresas lo hacen

5
neil90

#38442 Buscar otro trabajo. Es muy difícil cambiar eso sin tener algo de influencia en la empresa

2
Earh

#38442 I know that feel bro

pantocreitor

#38442 yo me cago directamente en el compañero. Estos días está uno de vacaciones y justo antes de irse dejó unas tareas en Jira de unos "bugs" que había, por si podíamos echarle un ojo.
Los bugs son que ha tocado cosas que no tenía ni puta idea de que eran, se las ha cargado y a la hora de mergear la ha liado mas...
Le he dejado un correo diciéndole que qué cojones ha hecho y por qué reporta sus cagadas como bugs y he pedido que lo saquen del proyecto (por mi de la empresa).

En mi caso, si no sé que hace algo pregunto e intento no tocar nada que no sea mío a menos que me lo pidan. Mucho cuidado siempre al mergear (aunque se supone que lo que está tocando uno no lo debería estar tocando otro...) y un palo, que siempre es efectivo contra los que están apoyardados.

2
Fyn4r

#38442 En mi caso refactorizar, avisar de que lo voy a hacer y por qué creo que es necesario hacerlo.
También te digo que las 2 veces que me pasó el "culpable" ya no estaba en el equipo asi que fueron cosas de 1 sola vez.
Y si alguien tiene algún problema pues lo apunto en mi máquina de escribir invisible

1
TheBrotha

Ponerlo en común con el equipo, elegir una estrategia para abordar la mierda que hemos creado por lo que sea, ponerlo como tarea en el sprint, que uno de nosotros lo haga, y ya. Nunca me he visto en la tesitura de decir "esto es una mierda, pero bueno yo dejo mi mierda por aqui arriba y ya el siguiente que se queje"

Y eso que el proyecto en menos de un año que lleva de recorrido ha sufrido mas cambios de vision y de objetivo que el multiverso de DC

Kaledros

Es un problema de la cultura de la empresa/equipo, lo que significa que ni lo vas a cambiar tú ni vas a conseguir nada más que cabrearte. Esos proyectos no suelen ir nunca a a ninguna parte y lo mejor que puedes hacer es ir buscando otra cosa.

2
JuAn4k4

Lo primero verlo como una oportunidad para refactorizar y pasárselo bien refactorizandolo.

Lo Segundo no echar mierda ni culpas, no conoces las circunstancias que hicieron escribir esa mierda de código.

Lo tercero es comentar que para realizar tu tarea es necesario eliminar la deuda técnica y tienes que refactorizar, y que para ello tienes que meter tests, y que llevará más tiempo del esperado inicialmente.

Lo cuarto es hacerlo en una o dos mañanas.

El quinto es disfrutar del resto de la semana en la piscina

19
Wei-Yu

En mi anterior curro yo pasaba bastante, como mucho iba refactorizando cosas simples para poder leer el código (ej meter early returns para quitarte 5 IFs anidados o mover de contexto unos datos para simplificar checks). Pero la verdad que hasta probaba ideas y dejaba el código más guarro por experimentar, porque total eso era una bola de mierda enorme e inasumible por la cultura que había.

Ahora más o menos como dice juanaka y también estamos pendientes de poder meter bloques de trabajo dedicados explícitamente a ir quitando deuda técnica que vamos metiendo en tickets analizados y estimados en grano gordo.

Lo que me parece super importante es tener un proceso definido para lidiar con deuda técnica (más allá de que en el momento te encuentres algo que está mal concebido). Últimamente he visto a varias empresas usando shape up y se me ha quedado la curiosidad metida en el cuerpo.

Kaledros

Lo que dice Juan es lo que se debería hacer en un mundo ideal (no va con segundas, me refiero a un trabajo con condiciones ideales). Si funciona pues mira, eso que tenéis ganado todos.

En mi experiencia, ningún manager va a permitir una tarea de refactorización en un proyecto que ha permitido que se monte ese lío porque la mera existencia de una deuda técnica como esa implica que la cultura del equipo deja mucho que desear.

Pero sí, yo intentaría lo que dice que como mucho pierdes diez minutos escribiendo un mail.

1 respuesta
freshnco

#38442 Lo primero paciencia, nunca se sabe por qué alguien acaba haciendo mierda, no siempre tenemos que pensar mal, aunque suela ser el caso...

No hace mucho me encontré con algo similar, la "solución" que surgió en el momento fue, comentarlo en la daily al día siguiente (que llevaría más tiempo del previsto) + propuesta de enviar por adelantado a todo el equipo (un día antes de los PBR) las nuevas tareas listas para estimar para tener un tiempo extra comprobando este tipo de cosas, por ahora parece que más o menos funciona, ver veremos a medio plazo.

También recalcar la importancia de las PR y las reviews que mucha gente, por desgracia se las pasa por el forro, esto suele ser más complicado.

A una mala, si la cosa no mejora, siempre puedes cambiar, dudo que te falten opciones a día de hoy sea cual sea tu stack o tu nivel

Ánimo

1
Fyn4r

El código puede acabar enrevesado por 1000 cosas y ser justificable, ahora, la sobreingeniería india es legendaria xD

PiradoIV
#38452Kaledros:

Lo que dice Juan es lo que se debería hacer en un mundo ideal (no va con segundas, me refiero a un trabajo con condiciones ideales). Si funciona pues mira, eso que tenéis ganado todos.

Yep, si el equipo tiene voluntad de hacer autocrítica y mejorar, pues genial. Refactorizar es entretenido y necesario.

Si no... como no es nuestra empresa, tampoco es un drama, te piras a otra menos frustrante y pista.

JuAn4k4

El otro camino, es que cuando pases del paso 3 te digan que no refactorices ni limpies la deuda técnica, entonces:

Solicitar permiso para meter la solución sin reducir deuda técnica poniendo explícitamente los riesgos que se afrontan (exagerar este punto) a tu manager directo.
Poner en copia a su manager (skip level)
Poner bien claro que tú opinión es que eso no debería hacerse así, dados los riesgos, pero que estás dispuesto a disagree and commit.

Meter la ñapa y meter bugs a propósito que causen un drama.

Dos caminos:
A ) Recoge tu finiquito
B ) Vuelve al paso 4 del happy path inicial

Repetir hasta que cambie la cultura a reliability y customer trust first

1 respuesta
B

#38456 vamos, tu solución es convertir al OP en desu

1
wdaoajw

Luego os quejáis de los SRE por aquí y vienen a salvaros el culo con la deuda técnica

2 1 respuesta
_gideon

Funcionando.

Lo hablé tranquilamente con el autor y acordamos refactorizarlo. No sin que antes me discutiera un par de principios básicos de programación, me preguntara sobre qué ganábamos no violando el DIP, y tuviera casi que recordarle lo que estudió en la universidad.

Estoy más con los que recomendais cambiar de trabajo, porque es consecuencia directa de una mala cultura de empresa. Esta es una batalla perdida y voy a acabar quemándome innecesariamente.

stuckED

#38441 No toques php. Se sigue buscando bastante el stack de Backend con PHP pero son sobre todo consultoras que hacen proyectos como churros. Yo empecé con PHP y con esfuerzo conseguí aprender lo básico de python como para poder hacer un cambio laboral y bueno, creo que mucho mejor.

1 respuesta

Usuarios habituales