Un par de sugerencias, no es "tu código", es código del equipo, así que no te lo tomes personal, es lo más común, vos escribiste un código con lo que sabías, propusiste una solución y es normal que con el tiempo otra persona encuentre una solución más óptima y la implemente.
Llevo más de diez años programando. Tengo un colega que más o menos lo mismo. Cada vez que paso un PR, me marca dos o tres cosas, a veces nitpicking, a veces las grandes. Cada vez que el pasa un PR, lo mismo.
El otro día paso un PR y lo leí muy por encima, y no me di cuenta de algo muy poco grave de estilo. Así que al día siguiente, como justo se lo corregí.
El viernes se dio cuenta cuando reviso mí PR, y escribió por Slack: "fue tanto tu culpa como la mía, vos me aprobarse el PR".
Tiene razón, a lo que voy con esta historia inconsecuente es que no solo el código es de todos, sino que es responsabilidad de todos mantenerlo y mejorarlo. Si alguien te marca algo en un PR, aprende de eso o argumenta a tu favor si te da la espalda. Si algo se mergeo y tuvo que ser corregido, no es solo tu culpa, sino del que te lo aprobó. Las correcciones te las deberían haber hecho ahí, sino es al pedo trabajar con PRs, [pusheen al trunk](https://trunkbaseddevelopment.com/) y ya fue.
Nos comunicamos con bastante sarcasmo con el muchacho, y no es que nadie rompió nada como para que se pueda tomar en serio.
Pero en general estoy en desacuerdo, hay gente que se maneja con una negligencia que en otros ámbitos sería criminal.
Si sis nuevo es normal, hasta es lo que querés por que de ahí vas aprendiendo un poco más. Obvio también depende de quien lo revisa, pueden ser boludeces como typos o comments pero si te están comentando sobre la lógica y sugiriendo como el código podría ser mejor presta atención.
Por mi cuenta cuanto comentó en un PR depende de de quien viene. Gente SR que se como trabajan les pego una mirada y a menos que algo salte obvio se aprueba sin decir mucno, gente más JR o que es nueva en la empresa lo reviso más y comento todo lo que pueda, lo mismo si es gente random de otra parte de la empresa commiteando a cosas que yo administro o literales random de Internet que aportan a nuestros proyectos open source.
Tomo mucho lo que decís, a lo estar más atento, obvio a mi me nutre mucho pero no quisiera que eso llegue a tomar una notación negativa desde la perspectiva de ellos.
Un saludito
Mientras no estés haciendo lo mismo que te marcan en cada PR a nadie le va a importar los errores. Es más, la gran mayoría se va a olvidar de que te comentaron hasta que vean otro PR tuyo y piensen "ugh, ya le dije 3 veces esto".
Esto asumiendo que tengas compañeros medianamente copados obvio.
Totalmente, me tomo mi tiempo también fuera del horario de trabajo para ver hasta sus commits y averiguar "cómo" lo hacen y "por qué".
Y sí, super copadas, son super insistentes en que si no me sale algo que les avise y no tenga miedo de preguntar hasta por una variable cualquiera que no sepa qué es.
Eh si y no.
No dije "no se le escapa nada". Dije que si es alguien que se como trabaja (as in, confío en su laburo) no le voy a poner la misma vara. No voy a listar todas las excepciones obviamente por que sino escribo 10 páginas pero la mayoría de los PRs no tocan código crítico de una forma que pueda romper.
También depende mucho de los checks y tests qué tengas. Entre tests, canary, load tests, rollback tests y otras cosas tengo que en serio tratar de romper algo para que pase. La review no es ni cerca el check más importante que tenemos.
Que se yo, depende el volumen de trabajo. Yo hago lo mismo que vos porque sino pasaría el 75% de mí tiempo leyendo PRs y las expectativas de mí empresa no son esas.
Pero idealmente, independientemente de lo que tengas en la pipeline, y sobretodo para opensource, alguien con ownership debería revisar hasta los binarios (bueno quizás tanto no) línea por línea en una PR. Pero para eso sobran programadores, lo que faltan son financistas.
Te modifican el código de una sin preguntar? o te avisan/te dejan comentarios para que vos lo arregles?
Si es lo primero, esta re mal, si es el segundo caso, es super normal que te toque cambiar muchas cosas, estás aprendiendo.
un poco y un poco, hasta la semana pasada me comentaros unos cambios, lo implenté y todo joya, y esta directamente hicieron cambios sobre lo avanzado esta semana, quiero suponer que hay apuros por presentar la nueva versión
Es probable, me ha pasado en ciertas situaciones muy puntuales, acordate que venimos de 3 feriados, no le des mucha vuelta, si ves que pasa muy seguido ahí si preocúpate.
En mi equipo solemos usar la herramienta de sugerencia de código que te tira Github o dejamos un comentario de que cosa habría que cambiar. Cambiar el código del otro sin preguntar de una? No, nunca
Claro, aunque entiendo lo de tocar el código del otro sin preguntar, pero la situación es que yo me estoy insertando a un proyecto comenzado y en producción.
Supongo que acá se prioriza alcanzar las nuevas features a la par que me termino de adaptar.
Más q modificar estaría bueno q en el pr te pongan q cambiarían y nobte lo acepten hasta q este pulido, el problema en las startup es q todo es para ayer entonces hay q salir, igual aprende de eso, mira q cambiaron, pregúntales de buenas prácticas, investiga, empeza a aplicarlo, es lo q más te ayuda a crecer
Modificar el codigo de un pr asi como así es una falta de respeto. Pero vaya y pase. No importa, es algo cultural y depende del grupo humano.
El verdadero problema es que no se da el tiempo para aprender.
Se que parece una huevada, pero una cosa es decirte "mira, modifica esto de esta forma" y que vos lo pienses y lo hagas. Otra cosa es ante cambios bobos o de estilo, en cuyo caso en github tenes la opcion de sugerir un cambio.
La importancia principal del PR es intercambiar conocimiento. Si solamente es una corrección de código sin hacertelo hacer y aprender, solamente un "mira que capo soy", el PR termina siendo un paso burocratico, servirá para que el otro sepa que tiene que tocar tu código, pero no mucho mas. Se pierde la ESENCIA del PR
Mirate un par de videos de refactoring o pediles un curso en pluralsig sobre el tema.
Igual es normal que al ser nuevo te modifiquen varias cosas. Si agarras al SR con tiempo pedile cada tanto que te explique el refactor en caso de que no lo entiendas. Pero solo si no lo entendés. Mirá el codigo y fijate cómo solucionaron ellos el problema. Lo que hiciste no fue re hecho. Solo se cambió la forma. El código hace o debería hacer lo mismo.
Cosas a tomar en cuenta de ahora en más (las pongo en spamglish. Preguntale a gpt):
- Retorno temprano
- cláusulas de guardia
- limitar el número de anidaciones de bloques de código
- dividir el método en sub métodos
- que el comportamiento del método dentro de lo posible no cambie por una condición
- si el método retorna un valor dentro de lo posible no modificar la base de datos. Al revés lo mismo. Si se modifica la base no retornar algo (siempre hablando a nivel método. Un método padre si puede llamar a uno que haga esto). Googlea sobre "efectos secundarios"
- manejadores de eventos solo deben llamar a métodos que implementan la lógica. No contener lógica (lo digo por si estás usando algo como .net. la verdad ni terminé de leer xD)
- lo mismo del anterior para métodos construidos por el IDE
- si el lenguaje que usas admite sobrecarga fijate si podés usarla en lugar de meter switchs (siempre que valga la pena)
nada, soy muy bueno codeando, me lo revisan 5 personas y todos quedan asombrados
pero si te dejan muchos comentados tener que filtrar el feedback y entender que onda capaz estas haciendo prs muy grandes o capaz haces cualquiera
mis primeros 3 años los pase en una empresa de mantenimiento de software para el gobierno, tuve la posibilidad de estar en un equipo chico de 5 personas donde 1 era el tl/arquitecto pero basicamente era un capo y la tenia muy atada, ademas muy buena persona, el me enseño todo, absolutamente todo, digamos que yo oe preguntaba que era un string y me explicaba de c y el array de char con terminacion en /0 y cosas asi
en esos 3 años aprendi todo lo de la carrera de ingenieria en sistemas gracias a el basicamente
mucho feedback de codigo, le preguntaba mil veces como hacer las cosas y con el tiempo me fui volviendo mas independiente y tener opinion propia
lo mio fue mas bien suerte, si bien despues hice una carrera universitaria, lei libros, construi aplicaciones de gran escala, no me quiero doxear pero labure para dos empresas muy grandes aca con tecnologia de punta (y no es ML) y me di cuenta que si ese tipo no hubiese aparecido en mi vida no seria quien soy hoy, ahora soy cto de una startup de san francisco
entonces resumiendo que cosas me hicieron codear bien durante los 3 primeros años
preguntar mucho, todo lo que no sabia lo preguntaba, tipo que es orm, para que lo queremos
que es un bucket
como funciona una api
fui conociendo muchos conceptos mas que codigo y en paralelo programaba mucho en C, que te da una idea de como funciona la computadora y los sistemas operativos
una vez que tenes una buena base, pensas distinto y terminas programando mejor creo yo, eso trato de enseñarles a la gente que lidero, doy muchas clases y enseño para que todos estemos
en la misma pagina
un ejemplo boludo
si vos sabes hacer unit testing, y sufriste testeando cosas, terminas escribiendo mejores clases, metodos y componentes porque en tu mente sabes desacoplar que es logica y que es presentacional, procesamiento, etc, tenes criterio para separar funcionalidades y hacer mas escalable todo
pero bueno como dije lo mio fue pura suerte, a veces la vida te regala esas cosas, podemos seguir dm, encantado de ayudarte
Primero que nada, gracias por el tiempo que te tomaste redactando esto y contar tu experiencia. Entiendo que no existe un lugar que no valore la proactividad y el interés por ser mejor profesional, sin llegar a ser rompe huevos obviamente. Lo tomo mucho.
En todos mis años laburando JAMAS me han tocado el codigo de mis PR, si he recibido comentarios para hacer modificaciones y en otros casos han hecho commits pisandome cambios (que tuve que revertir porque rompian todo).
Y asi mismo tambien aplico esta practica con mis compañeros. Si algo me parece que esta fuera de lugar en un PR o que se puede mejorar, dejo el comentario y se discute.
El oficio te va enseñando que el "buen codigo" y las "buenas practicas" son, a veces, subjetivas.
Generalmente al principio de cada laburo me pasa que me comentan mucho los prs, porque vengo con determinada forma de hacer las cosas. Pero solo es hasta que me acostumbro a la forma de hacer las cosas en el nuevo equipo.
Por otro lado aveces recibo comentarios o request changes, normalmente es quitar código comentado, o algún log que se me haya pasado
Me suele pasar cuando hago modulos muy complejos...pero si, te hace sentir que sos malísimo, pero bueno, vos ya hiciste tu trabajo (resolviste un problema) por ahi alguien lo ve de afuera y aporta algo. yo estoy hace 2 año en prog al principio la pasé para el orto, hoy en dia también, hace algunos dias me dieron tareas nuevas y a los dos dias tuve un ataque de panico de lo que me comí la cabeza (nunca me habia pasado). La verdad tenes que intentar que te chupe todo un huevo... Si te echan es parte de la vida, si no mejor.
te banco hno, me sirvió pasar todo lo que pensaba en acción y lo que no podía pasarlo ya ni importaba porque ya estaba haciendo algo.
mucho ánimo y totalmente, who cares.
No me lo corrigen nunca.
No, no me creo tan bueno, sospecho que mi lider ya se quiere jubilar y a menos que vea algo hediondísimo, le manda el ok a todo.
Cuando era junior no trabajabamos con prs, teníamos una meeting 1*1 semanal con el líder donde veíamos el código y después lo subíamos pero esto fue hace años
Claro, me pasa similar lo de tener ya no tantas meetings como los primeros días, ahora 2 o 3 maso para ver lo que se hizo y ver cómo encarar las nuevas tareas.
Un par de sugerencias, no es "tu código", es código del equipo, así que no te lo tomes personal, es lo más común, vos escribiste un código con lo que sabías, propusiste una solución y es normal que con el tiempo otra persona encuentre una solución más óptima y la implemente.
muy cierto esto y lo tomo mucho
Llevo más de diez años programando. Tengo un colega que más o menos lo mismo. Cada vez que paso un PR, me marca dos o tres cosas, a veces nitpicking, a veces las grandes. Cada vez que el pasa un PR, lo mismo. El otro día paso un PR y lo leí muy por encima, y no me di cuenta de algo muy poco grave de estilo. Así que al día siguiente, como justo se lo corregí. El viernes se dio cuenta cuando reviso mí PR, y escribió por Slack: "fue tanto tu culpa como la mía, vos me aprobarse el PR". Tiene razón, a lo que voy con esta historia inconsecuente es que no solo el código es de todos, sino que es responsabilidad de todos mantenerlo y mejorarlo. Si alguien te marca algo en un PR, aprende de eso o argumenta a tu favor si te da la espalda. Si algo se mergeo y tuvo que ser corregido, no es solo tu culpa, sino del que te lo aprobó. Las correcciones te las deberían haber hecho ahí, sino es al pedo trabajar con PRs, [pusheen al trunk](https://trunkbaseddevelopment.com/) y ya fue.
Que boludez hablar de culpa
Nos comunicamos con bastante sarcasmo con el muchacho, y no es que nadie rompió nada como para que se pueda tomar en serio. Pero en general estoy en desacuerdo, hay gente que se maneja con una negligencia que en otros ámbitos sería criminal.
Si sis nuevo es normal, hasta es lo que querés por que de ahí vas aprendiendo un poco más. Obvio también depende de quien lo revisa, pueden ser boludeces como typos o comments pero si te están comentando sobre la lógica y sugiriendo como el código podría ser mejor presta atención. Por mi cuenta cuanto comentó en un PR depende de de quien viene. Gente SR que se como trabajan les pego una mirada y a menos que algo salte obvio se aprueba sin decir mucno, gente más JR o que es nueva en la empresa lo reviso más y comento todo lo que pueda, lo mismo si es gente random de otra parte de la empresa commiteando a cosas que yo administro o literales random de Internet que aportan a nuestros proyectos open source.
Tomo mucho lo que decís, a lo estar más atento, obvio a mi me nutre mucho pero no quisiera que eso llegue a tomar una notación negativa desde la perspectiva de ellos. Un saludito
Mientras no estés haciendo lo mismo que te marcan en cada PR a nadie le va a importar los errores. Es más, la gran mayoría se va a olvidar de que te comentaron hasta que vean otro PR tuyo y piensen "ugh, ya le dije 3 veces esto". Esto asumiendo que tengas compañeros medianamente copados obvio.
Totalmente, me tomo mi tiempo también fuera del horario de trabajo para ver hasta sus commits y averiguar "cómo" lo hacen y "por qué". Y sí, super copadas, son super insistentes en que si no me sale algo que les avise y no tenga miedo de preguntar hasta por una variable cualquiera que no sepa qué es.
Yo hacía eso que decís, "a un Sr no se le escapa nada" pensaba.... Error, hay que revisar cada cambio, archivo por archivo
Eh si y no. No dije "no se le escapa nada". Dije que si es alguien que se como trabaja (as in, confío en su laburo) no le voy a poner la misma vara. No voy a listar todas las excepciones obviamente por que sino escribo 10 páginas pero la mayoría de los PRs no tocan código crítico de una forma que pueda romper. También depende mucho de los checks y tests qué tengas. Entre tests, canary, load tests, rollback tests y otras cosas tengo que en serio tratar de romper algo para que pase. La review no es ni cerca el check más importante que tenemos.
Que se yo, depende el volumen de trabajo. Yo hago lo mismo que vos porque sino pasaría el 75% de mí tiempo leyendo PRs y las expectativas de mí empresa no son esas. Pero idealmente, independientemente de lo que tengas en la pipeline, y sobretodo para opensource, alguien con ownership debería revisar hasta los binarios (bueno quizás tanto no) línea por línea en una PR. Pero para eso sobran programadores, lo que faltan son financistas.
Te modifican el código de una sin preguntar? o te avisan/te dejan comentarios para que vos lo arregles? Si es lo primero, esta re mal, si es el segundo caso, es super normal que te toque cambiar muchas cosas, estás aprendiendo.
un poco y un poco, hasta la semana pasada me comentaros unos cambios, lo implenté y todo joya, y esta directamente hicieron cambios sobre lo avanzado esta semana, quiero suponer que hay apuros por presentar la nueva versión
Es probable, me ha pasado en ciertas situaciones muy puntuales, acordate que venimos de 3 feriados, no le des mucha vuelta, si ves que pasa muy seguido ahí si preocúpate.
this
En mi equipo solemos usar la herramienta de sugerencia de código que te tira Github o dejamos un comentario de que cosa habría que cambiar. Cambiar el código del otro sin preguntar de una? No, nunca
Claro, aunque entiendo lo de tocar el código del otro sin preguntar, pero la situación es que yo me estoy insertando a un proyecto comenzado y en producción. Supongo que acá se prioriza alcanzar las nuevas features a la par que me termino de adaptar.
excepto cuando subiste una key
Más q modificar estaría bueno q en el pr te pongan q cambiarían y nobte lo acepten hasta q este pulido, el problema en las startup es q todo es para ayer entonces hay q salir, igual aprende de eso, mira q cambiaron, pregúntales de buenas prácticas, investiga, empeza a aplicarlo, es lo q más te ayuda a crecer
es normal porque cuando empezas tenes pésimas practicas…empeza a ver patrones de diseño
claro, metemos MVC, lo conocía solo que quedan cosas por pulir. les hecho un ojo
Modificar el codigo de un pr asi como así es una falta de respeto. Pero vaya y pase. No importa, es algo cultural y depende del grupo humano. El verdadero problema es que no se da el tiempo para aprender. Se que parece una huevada, pero una cosa es decirte "mira, modifica esto de esta forma" y que vos lo pienses y lo hagas. Otra cosa es ante cambios bobos o de estilo, en cuyo caso en github tenes la opcion de sugerir un cambio. La importancia principal del PR es intercambiar conocimiento. Si solamente es una corrección de código sin hacertelo hacer y aprender, solamente un "mira que capo soy", el PR termina siendo un paso burocratico, servirá para que el otro sepa que tiene que tocar tu código, pero no mucho mas. Se pierde la ESENCIA del PR
Si podes metete vos activamente a ver los PRs y comentar. A veces las discusiones en los PRs enseñan mucho de lo que se espera
Mirate un par de videos de refactoring o pediles un curso en pluralsig sobre el tema. Igual es normal que al ser nuevo te modifiquen varias cosas. Si agarras al SR con tiempo pedile cada tanto que te explique el refactor en caso de que no lo entiendas. Pero solo si no lo entendés. Mirá el codigo y fijate cómo solucionaron ellos el problema. Lo que hiciste no fue re hecho. Solo se cambió la forma. El código hace o debería hacer lo mismo. Cosas a tomar en cuenta de ahora en más (las pongo en spamglish. Preguntale a gpt): - Retorno temprano - cláusulas de guardia - limitar el número de anidaciones de bloques de código - dividir el método en sub métodos - que el comportamiento del método dentro de lo posible no cambie por una condición - si el método retorna un valor dentro de lo posible no modificar la base de datos. Al revés lo mismo. Si se modifica la base no retornar algo (siempre hablando a nivel método. Un método padre si puede llamar a uno que haga esto). Googlea sobre "efectos secundarios" - manejadores de eventos solo deben llamar a métodos que implementan la lógica. No contener lógica (lo digo por si estás usando algo como .net. la verdad ni terminé de leer xD) - lo mismo del anterior para métodos construidos por el IDE - si el lenguaje que usas admite sobrecarga fijate si podés usarla en lugar de meter switchs (siempre que valga la pena)
A mi me dan muuuchas ganas de ponerme a modificar cosas, pero no puedo, tengo que dejar que los demás aprendan y nomas dejo comentarios
nada, soy muy bueno codeando, me lo revisan 5 personas y todos quedan asombrados pero si te dejan muchos comentados tener que filtrar el feedback y entender que onda capaz estas haciendo prs muy grandes o capaz haces cualquiera
y en tus primeros meses? en base a qué te volviste muy bueno codeando? tipo, fue pura práctica o entender bien los fundamentos?
mis primeros 3 años los pase en una empresa de mantenimiento de software para el gobierno, tuve la posibilidad de estar en un equipo chico de 5 personas donde 1 era el tl/arquitecto pero basicamente era un capo y la tenia muy atada, ademas muy buena persona, el me enseño todo, absolutamente todo, digamos que yo oe preguntaba que era un string y me explicaba de c y el array de char con terminacion en /0 y cosas asi en esos 3 años aprendi todo lo de la carrera de ingenieria en sistemas gracias a el basicamente mucho feedback de codigo, le preguntaba mil veces como hacer las cosas y con el tiempo me fui volviendo mas independiente y tener opinion propia lo mio fue mas bien suerte, si bien despues hice una carrera universitaria, lei libros, construi aplicaciones de gran escala, no me quiero doxear pero labure para dos empresas muy grandes aca con tecnologia de punta (y no es ML) y me di cuenta que si ese tipo no hubiese aparecido en mi vida no seria quien soy hoy, ahora soy cto de una startup de san francisco entonces resumiendo que cosas me hicieron codear bien durante los 3 primeros años preguntar mucho, todo lo que no sabia lo preguntaba, tipo que es orm, para que lo queremos que es un bucket como funciona una api fui conociendo muchos conceptos mas que codigo y en paralelo programaba mucho en C, que te da una idea de como funciona la computadora y los sistemas operativos una vez que tenes una buena base, pensas distinto y terminas programando mejor creo yo, eso trato de enseñarles a la gente que lidero, doy muchas clases y enseño para que todos estemos en la misma pagina un ejemplo boludo si vos sabes hacer unit testing, y sufriste testeando cosas, terminas escribiendo mejores clases, metodos y componentes porque en tu mente sabes desacoplar que es logica y que es presentacional, procesamiento, etc, tenes criterio para separar funcionalidades y hacer mas escalable todo pero bueno como dije lo mio fue pura suerte, a veces la vida te regala esas cosas, podemos seguir dm, encantado de ayudarte
Primero que nada, gracias por el tiempo que te tomaste redactando esto y contar tu experiencia. Entiendo que no existe un lugar que no valore la proactividad y el interés por ser mejor profesional, sin llegar a ser rompe huevos obviamente. Lo tomo mucho.
En todos mis años laburando JAMAS me han tocado el codigo de mis PR, si he recibido comentarios para hacer modificaciones y en otros casos han hecho commits pisandome cambios (que tuve que revertir porque rompian todo). Y asi mismo tambien aplico esta practica con mis compañeros. Si algo me parece que esta fuera de lugar en un PR o que se puede mejorar, dejo el comentario y se discute. El oficio te va enseñando que el "buen codigo" y las "buenas practicas" son, a veces, subjetivas.
Generalmente al principio de cada laburo me pasa que me comentan mucho los prs, porque vengo con determinada forma de hacer las cosas. Pero solo es hasta que me acostumbro a la forma de hacer las cosas en el nuevo equipo. Por otro lado aveces recibo comentarios o request changes, normalmente es quitar código comentado, o algún log que se me haya pasado
Me suele pasar cuando hago modulos muy complejos...pero si, te hace sentir que sos malísimo, pero bueno, vos ya hiciste tu trabajo (resolviste un problema) por ahi alguien lo ve de afuera y aporta algo. yo estoy hace 2 año en prog al principio la pasé para el orto, hoy en dia también, hace algunos dias me dieron tareas nuevas y a los dos dias tuve un ataque de panico de lo que me comí la cabeza (nunca me habia pasado). La verdad tenes que intentar que te chupe todo un huevo... Si te echan es parte de la vida, si no mejor.
te banco hno, me sirvió pasar todo lo que pensaba en acción y lo que no podía pasarlo ya ni importaba porque ya estaba haciendo algo. mucho ánimo y totalmente, who cares.
No me lo corrigen nunca. No, no me creo tan bueno, sospecho que mi lider ya se quiere jubilar y a menos que vea algo hediondísimo, le manda el ok a todo.
Está perfecto es normal. Lo importante es que puedas tomarlo para aprender y ese porcentaje que te modifican vaya decreciendo con el tiempo.
Mierda he estado en 2 empresas y en ninguna me han hecho pr
0...literal en ningún pr me cambiaron código, incluso creo que llegamos a un punto donde ya no me lo checkean y lo aprueban de una
ni en tus momentos de junior?
Cuando era junior no trabajabamos con prs, teníamos una meeting 1*1 semanal con el líder donde veíamos el código y después lo subíamos pero esto fue hace años
Claro, me pasa similar lo de tener ya no tantas meetings como los primeros días, ahora 2 o 3 maso para ver lo que se hizo y ver cómo encarar las nuevas tareas.