Afortunadamente he tenido dos cargos que me dan puntos de vistas variados respecto al tema de "no son niños": Trabajé como líder técnico en múltiples proyectos de I+D con equipos pequeños de 3 o 4 programadores (y en compañía con otros equipos técnicos: mecánicos, electrónicos, telecos, etc). Y mi prioridad siempre fue enseñar y hacer que cada uno de mi equipo fuera capaz de tomar decisiones. ¿Que el junior decidió usar variables con nombres "a", "b", "c" en vez de nombres descriptivos? pues nada, reunión de 10 minutos solo con el (las correcciones siempre en privado, los halagos siempre en publico) señalandole la razón por la cual es mejor usar otro tipo de nombres. Y luego, lo acompaño mientras corrige el mismo el problema para que me pueda preguntar de ser necesario; En algunos casos volvían a "cagarla" pero al recordarles lo arreglaban ellos solos, y de hecho, con el tiempo y con la confianza en si mismos empezaban a arreglarse las cosas entre ellos e incluso a recomendarme cosas a mi. Por otra parte, ahora mismo trabajo como consultor de procesos de negocios, les he hecho consultoría a múltiples empresas (bancos, inversoras, fiscalías, productoras importadoras, etc). Y una regla primordial son los controles cruzados. Si una persona hace algo, el mismo no puede "revisar" lo que hizo, lo tiene que hacer otro, y dejar una evidencia de que lo hizo. Riesgos y Controles; para muchas empresas no es una "decisión", es una exigencia legal. Estoy de acuerdo con esto de "no son niños" y que cada uno sepa que hacer y como hacerlo, pero siempre debe haber un control. Si tenemos integración continua con pruebas bien hechas entonces perfecto: push a master y que un senior haga revisiones esporádicas cada tanto (idealmente dejando un comentario, correo o lo que sea como evidencia). ¿Que no tenemos buenas pruebas? pues lastimosamente veo necesario ir a punta de PRs en lo que arreglamos lo de las pruebas. Obviamente todo depende del proyecto, si estas haciendo la web comercial de aceitunas pepito, te puedes tomar ciertas licencias. Pero si estás desarrollando el sistema que opera un equipo médico que cuesta millones... mientras mas controles, mejor. En resumen: Estoy de acuerdo 100%: Seamos buenos profesionales y ayudemos al resto a ser mejores, pero siempre tengamos controles (si son automáticos mejor).
Actualmente comienzo como responsable de proyecto, que puede ser algo como líder técnico ya que tengo la responsabilidad de que las implementaciones de mis compañeros funcionen, y funcionen bien. Por ende, como las buenas prácticas era algo ausente en dicho proyecto (aún lo es pero, tenemos mucho por delante), mis compañeros no se esfuerzan demasiado en mejorar el código existente y a veces siguen las malas prácticas porque les es más fácil copiar y pegar (cosa que no paro de reclamarles). Como no tengo experiencia como líder estaba a punto de comenzar a pedir y revisar cada PR de mis compañeros a fin de corregir lo que viese mal. Pero entonces mencionaste que, en efecto, no somos niños. Es algo complicado de explicar cómo tus pocas palabras me empezaron a abrir los ojos, así que lo resumiré con que acabas de darme una bofetada que me aclaró bastante el panorama y te agradezco por ello
Mola lo que comentas y es una alternativa muy válida, lo que no haría es decir algo es blanco o negro, todo parte de un compromiso y hay que encontrar el criterio correcto. Git flow es otra estrategia totalmente válida que seguir y en algunos casos puede ser más productiva que lo que comentas, lo digo por la miniatura. Aparte, No entiendo por qué usar Ship/Show/Ask no permite usar ramas feature, develop, release, bugfix etc. puedes comitear en cualquier rama usando la regla del Ship/Show/Ask
En mi opinion aun siendo senior puede implementar malas practicas.. prefiero siempre crear PR y dependiendo de las prioridades se puede usar el "SHOW", pero nunca SHIP
Realmente lo que dice midu sobre la infantilización es real. Hace poco en un trabajo universitario estaba como líder de mi equipo y tuve que aprender por las malas que hay que delegar no solo trabajo sino también responsabilidades y confiar en el equipo (además de penalizar si se ha hecho mal). En mi caso trabaje con un grupo de personas sin mucha experiencia y al principio hacia de profesor y de guía un poco pero después se formo un bucle en el que además de hacer mi trabajo debía revisar el del resto y corregirlo, bucle que se genero tanto desde mi lado como el del equipo, que se enojaba si no estaba ahi para corregir. El tema es que al final aprendí que en vez de ese approach es muchísimo mejor simplemente delegar, las personas adultas son capaces de ver si tienen un error en develop o en producción y solucionarlo, y aunque tu podrías hacerlo más rápido... NO SOMOS SUPERMAN Así que, lo siento a mi equipo y también a mi mismo, espero que esta experiencia le ayude a otras personas que estén viviendo cosas similares.
Me he reído bastante viendo este video. Esto es solo recomendable para proyectos nuevos o pequeños o que no sean críticos, o en empresas cuyo proceso de contratación es lo suficientemente exigente como para que los equipos tengan recursos con un alto conocimiento, pensamiento crítico y responsabilidad. Mi buen amigo Murphy me ha enseñado que si algo puede salir mal, seguramente saldrá mal; además, los procesos de desarrollo de software deben minimizar los riesgos. Permitir que cualquier recurso haga cambios no supervisados que se reflejen a producción, bajo la bandera de "no son niños", atenta contra la continuidad del negocio que exige todo proyecto serio de software.
Para minimizar los riesgos hay mil formas mejores que controlar manualmente el código que se añade y seguir un proceso tan farragoso como Git Flow. Testing, CI/CD, rollbacks automáticos basados en métricas, Mob Programming…
@@midulive Te recomiendo leer nuevamente mi comentario, parece que te has confundido con otro.. Claramente estoy diciendo que en proyectos de verdad (grandes o críticos o que exigen una alta continuidad de negocio) no se puede dejar sin supervisión a los desarrolladores solo porque "no son niños", caso contrario se adquieren riesgos innecesarios contra la funcionalidad del sitio o contra la seguridad de los clientes que podrían repercutir en sanciones legales.. Jamás he dicho que el code review deba ser 100% manual, hay 10000 utilidades que permiten simplificar este proceso; pero, no por eso vamos a dar el poder a los recursos de autorevisarse y autoaprobarse.. Y puntos importantes que debes tener en cuenta: Los equipos deben tener integrantes con roles definidos. Que un desarrollador sea SR no significa que no cometa errores. Que un JR nunca llegue a SR es porque jamás salió de su zona de confort, ni se educó, ni mostró a su líder las habilidades para solucionar problemas eficientemente.. Obviamente sí hay líderes tóxicos y nocivos que centralizan todo y que no dejan crecer a sus recursos, pero eso ya es cosa de las empresas que mantienen líderes así, y no es el común denominador en el mercado.. Me asusta que digas que tu empresa va a implementar esta filosofía de "sube lo que quieras porque no eres un niño", porque eso solo significa que se ahorrarán dinero en los responsables de supervisión y les asignarán más responsabilidades a los desarrolladores innecesariamente, o que hacen puros desarrollos pequeños que no requieren seguir un proceso adecuado de software.
@@itenrioarq creo que el punto de midulive es muy bueno, yo creo que en esta industria no hay que ser cuadrados, yo pensaba como tú pero hay que evolucionar y la verdad es que con unos buenos pipelines bien implementados para tdd, bdd, etc... con sus respectivos rollbacks automatizados, el pull request es un cuello de botella innecesario
Esta estrategia funciona perfectamente para equipos pequeños y productos para startups donde los costes, los presupuestos y los tiempos de entrega tienen un peso mucho mayor a la calidad del producto, como por ejemplo cuando desarrollas un MVP. Pero para equipos grandes que gestionan productos maduros y que trabajan con múltiples microservicios que iteroperan y que pueden haber en un momento features que no son compatibles en determinadas versiones no es viable. No siempre el continous delivery es la estrategia conveniente para todos los proyectos. Cuando tienes que entrega un código con un estandard alto de calidad y un producto con buenos niveles de escalabilidad y resiliencia. Se podría argumentar que siempre se puede echar para atrás si algo explota, implementar estrategias de rollback o despliegues blue/green, para evitar que se caiga el servicio, pero entonces el tiempo que te ahorras en verificación y pruebas de tu código integrado, los vas a gastar en sacar fixes por desplegar en producción o en stage releases con bugs, que es en mi opinión hacer retrabajo pero con el riesgo de colar errores no identificados en producción.
Totalmente de acuerdo contigo, el micromanagement y ese pensamiento de yo, como lead, soy el único ser con capacidad e inteligencia universal para hacer las cosas bien solo llevan a frustración de los compañeros que ven que no avanzan, un cuello de botella increíble que se carga todo el agile y CI/CD que tiene la empresa jajaja. A mi muchas veces me preguntan sobre desarrollos en progreso y aunque sepa que esta mal les digo: si tú lo ves bien, adelante o no veo nada raro/mal a priori. Con la intención de que después de estar todo un día con eso llegan al punto en el que por ellos mismos se dan cuenta de que hay algo que hace inservible su estrategia y deben de empezar de 0. Es un poco putadita pero si no te equivocas a veces.... Hasta ahora he recibido más "gracias" que "joder ya me podrías haber avisado", porque así realmente aprenden varias cosas que les ayuda a subir de nivel, una de ellas es la de plantear si con esa estrategia va a funcionar todo, antes de ponerse a picar nada de código con lo primero que les parece "aceptable". Por supuesto soy coherente con el tiempo que sé que van a invertir en equivocarse y jamás se me ocurriría que perdieran 3 días de trabajo, en ese caso hay otras estrategias, como empezar a preguntar ¿Qué pasaría si....? para intentar guiarles hasta el fallo, etc.
Yo estuve en un proyecto grupal para un proyecto y bueno en cierto sentido estuve de apoyo si el equipo lo necesitaba y tal. pero aunque me inmiscuia un poco en como seria la logica del desarrollo no tenia pensado revisar el codigo de cada compañero. Pues llego el penultimo dia de desarrollo antes de entregarlo y me encontre que el codigo de un compañero no funcionaba nada y estaba absolutamente incompleto y fallos logicos. Los 2 dias de trabajo que me quede para mi se quedan
Creo de independiente del nivel que se tenga las revisiones de código son importantes tanto para el que genera el código como el que lo revisa, obviamente el revisor no puede tomar una postura cerrada siempre se puede crecer y aprender de todos revisando código y escenarios en donde le revisen el código a uno, esto con el objetivo de discutir y llegar a consensos de mejores practicas en la implementación del código.
Creo que este enfoque fuera correcto en un "mundo perfecto", tanton en recuso humano como en procesos de ingeniería. Yo al menos he estado en muchas empresas y ya me ha tocado liderar varios equipos, y es que los contextos son tan variables (porque como decimos, son personas, y las personas somos infinitemente diferentes en habilidades tanto blandas como técnicas) que es imposible que una fórmula "abierta" funcione bien en cada empresa. Por eso enfoques mas "guiados" siempre terminan siendo los mas adoptados de manera global. Me han tocado Devs con experiencia y excelentes habilidades en código, pero muy malos en la toma de decisiones, lo cual es medible solo a largo plazo (según cada quien vaya demostrando tal criterio). Muchos incluso me han pedido ser "explícito" en las instrucciones dado que sus mentes funcionan de manera bastante "literal", con esto quiero decir que no se trata de un concepto de que "son niños", si no de que todos tenemos distintas habilidades, unos para "seguir", "aprender", "ejecutar", otros para "liderar", "enseñar", etc... y bueno, a otros pues no se les da bien ninguna. ¿Que tienes que encargarte de que la gente "crezca" o avance?, estoy de acuerdo, pero creo que eso tiene que ver con liderazgo y no con el tema de conversación del video. Encasillar a todo el mundo en un marco de habilidades y asumir que todos son capaces de hacer algo lo encuentro fuera de la realidad (sobre todo en un mundo profesional donde somos bastante especiales en cuanto a personalidades jaja). Saludos!
gitflow para proyectos enano es un incordio, pero creeme como devops de varias apps de medio millon de lineas de codigo con casi 18 equipos en paralelo sobre esas mismas apps y con alta rotación, que o metiamos gitflow con ci/cd o moríamos de cara al cierre de sprint :D
Ya tengo el libro en casa para mi nueva andadura como DevOps Junior. Lo tendré a mano mientras me voy empapando de información sobre Kubernetes y Azure devops. En mi caso, usaré GitLab.
Me parece interesante lo que planteas, duda, dónde consigo tu libro, para empaparme más en el tema. Soy de la "vieja" escuela y lo que manejaba era TFS de Microsoft, ahora uso git flow, pero tú planteamiento me parece bueno. Saludos.
Estoy de acuerdo con la mayoría de las cosas que dijiste, solo levantaria un par de consideraciones, todos los años se duplica el numero de trabajadores en el sector IT, por ende todos los años la mitad de la gente tiene menos de un año de experiencia. Esto no necesariamente te va a traer demasiadas cuestiones a nivel tecnico, pero si a nivel conocimiento de dominio y las implicancias de ciertos "pequeños cambios" en el usuario final, si bien estoy de acuerdo con que no deberia haber 1 persona que deba ver todo el código antes de pasar, me parece que tener estrategias donde te puedan dar feedback constante sobre lo que subis (sin comprometer la entrega continúa) es a lo que deberiamos apuntar (para crecer todos en el equipo). Esto significa tener lineamientos (que apliquen a la mayoria de casos) y un consenso del equipo sobre cuando usar cada tipo de estrategia de branching. De igual manera, el video me parece super para equipos maduros 😃
Igual en esta estrategia puedes usar Ask, que sirve exactamente para lo que comentas. No es que está la gente obligada a usar Ship y Show. Además la idea es que las revisiones sigan ocurriendo aunque sea a posterior (Mob Programming)
@@midulive completamente de acuerdo, a lo que voy es que si me parece necesario una heurística consistente en el equipo para saber cuando usar uno u otro. Por ahi el criterio solamente individual puede generar conflictos en un trabajo colectivo (teniendo en cuenta que en los equipos hay, en gral, mucha diferencia en cuanto conocimiento de negocio)
Si no tienes soft skills el seniority no puede ser alcanzado. El problema del área de IT es que es muy difícil abordar dificultades grandes asumiendo la total responsabilidad como si pasa en otras industrias
Incluso en una traducción se puede ir una falta de ortografía o una palabra mal escrita y si hay algo que hace desconfiar de la calidad del software son ese tipo de cosas. Está bien, una falta de ortografía no va a tirar el sistema y meterán una corrección después, pero ¿por qué no hacerlo bien desde el principio?
Aquí el problema que le veo son los egos individuales, los cuales claramente abundan en nuestro sector...y tienes que ser prácticamente psicólogo como para saber si puedes confiar en tu equipo hasta ese punto. Lo veo inviable en equipos con alta rotación o muy inexpertos pero interesante en equipos con experiencia
En desarrollo de software no tenemos balas de plata, la mejor estrategia para el manejo de ramas en X proyecto, siempre va ser una con la cual el equipo tenga la mejor relación costo / beneficio. Lo anterior no significa que por eso gitflow o otro git workflow sea malo, simplemente va a depender del caso de uso y del contexto del proyecto, por eso siempre hay que analizar antes de...
Chavales, que no os engañen, Git Flow al completo es super versátil y hace predecible el versionado del código sin necesidad de llenarlo de condicionales. Aprended GitFlow de verdad. No os quedéis con develop/ + feature/, que es lo que suelen exponer estos creadores de contenido. Lo único que puedo decir en contra es que plataformas como GitLab y GitHub no hacen agradable el proceso a través de Pull Requests.
Me hubiese gustado encontrar una explicación de por qué no usar Git Flow. El contenido del canal es muy bueno, pero personalmente paso de los videos “Tienes que hacer esto” o “No tienes que hacer aquello” como abundan en HolaMundo.
Entiendo que el objetivo del ask vs show es el Review. Dicho esto: push sin Review es un no. Salvo que sea un typo en un comentario, nada justifica un push sin Review (y para mí un typo no justifica un push). El principal motivo es para tratar de garantizar que el menos otra persona este de acuerdo en que el código es fácil de entender. Ese es el objetivo de un Review. Ahora si el tema hace pair programming, el Review ya está hecho y no es necesario un pr.
Buenas Midu, a ver, tengo mis sentimientos encontrados con este video. Te doy la razón de que el desarrollador se tiene que responsabilizar de que el código que produce es de calidad y pasa todos los tests / estandares, pero en caso de que no lo haga y lo mergeen, qué es lo que dices que se tiene que hacer en ese caso? Decirle que lo arregle? bien, es obvio, pero cuando tienes plazos de entrega y el cliente apretandote, estos fallitos que ocurren porque obviamente son Juniors, retrasan la entrega y normalmente cargan de faena a los más seniors. Nosotros tenemos unas cuantas guías de los estándares de código que busca la empresa (evitar al máxima el código comentado, eliminar console.log residuales, etc) y hay desarrolladores Juniors que han hecho PRs y cuando la pruebas ves que no cumplen las guías de estandares, o que la funcionalidad está a mitad. Si les dejáramos mergear directamente a develop nos encontraríamos con que la plataforma sería demasiado inestable, y tendríamos que estar reviertiendo commits / arreglando código una buena parte del tiempo. Desde mi punto de vista, creo que no es tan perjudicial el que se le revisen las PR y se señalen los errores / cosas a cambiar y que sean ellos quienes los hagan (obviamente la tarea es suya) pienso que poco a poco el desarrollador Junior irá cogiendo soltura y sus PR cada vez serán más robustas y sin fallos hasta que llegue el día que sea él quien revise la de otros compañeros. De esta forma evitas que código incompleto llegue a develop y al entorno de PRE ayudando a los más juniors y sin sobrecargar a los más seniors.
Todo lo que comentas ya viene amparado sobre la posibilidad de usar Ask. Si un dev no tiene nivel, existe la posibilidad de hacer PRs y pedir ayuda al resto del equipo para que se asegure que está bien el código. También hay otra cosa: - Con los juniors se puede/debe hacer Pair Programming justamente para evitar mucho de lo que dices. - Cumplir los estándares debería estar lo más automatizado posible.
Hola, estoy viendo de comprar el libro pero en ningún lado dice que cantidad de páginas tiene? De cuántas páginas es? Y es formato libro donde hay 200 palabras por página o es formato tipo Powerpoint exportado a PDF/epub dónde lo terminas de leer en 20 solo minutos? Gracias
Gracias Midu por tus palabras del seniority hay que responsabilizarnos, ! como me gustaría algún día estar en un equipo tuyo o trabajar contigo! y crecer como debería!. Por lo de Ship / Show / Ask, creo que lo hago ya.
@@midulive que suerte tienen algunos jeje, es que la verdad no todos los desarrolladores tienen la madurez y responsabilidad como para pedir ayuda en caso de que sientan que algo falta.
pueeeeeeees, en una empresa que conoci, un programador hizo un cambio y lo subio directo a master sinconsultar porque segun el era consciente de que no iba a pasar nada malo y resulto en una perdida de 25 mil dolares en solo 4 horas
De tu historia lo más preocupante es que no exista un test que pueda evitar eso. Al final que lo suba a master o se haga merge desde una PR, hubiera pasado lo mismo.
Yo empecé con 13 años pero fue solo curiosidad y un hobby, ni enterado estaba que esto podía ser un trabajo jaja igualmente si impresiona niños que con 14 años ya desarrollaron un editor de imágenes como Canva para una hackathon, o que hablan de temas más complejos para mejorar el rendimiento y la arquitectura de una aplicación 🤯
Woo, en mi opinión es muy cuestionable esa opinión. Si se usa CI (con un sonarquve que vigile que no se hagan burradas, que todos hemos sido novatos) todo OK, pero en el mundo real hay multitud de proyectos que no saben de que va eso (y multitud de gente a la que no le importa no saberlo). Si hablamos de mundo real, no todo desarrollador de software tiene ese mínimo de ganas por aprender. Muchos ni se preocupan por hacer las cosas medio bien. Basta con que a final de mes, cobren. Esa es la pura realidad... más quisiera yo que no fuese así, no habría cambiado 3 veces de empresa en un año buscando de trabajar en un equipo (y proyecto) con un perfil decente que me pueda aportar algo.
Suena interesante, pero no la llamaría "la mejor estrategia" siempre es discutible eso. Y lo otro que dices tienes razón no se puede revisar el código de todo el mundo pero es cuestión de confianza y eso se va ganando de a poco en un equipo. Saludos!
Pues como que tampoco aporta mucho ese flujo, lo mas seguro es lo que se revisa, a veces por muy sabelo todo se te van curradas como un console.log, o algo que puede hacerse con alguna estructura mejor... por el momento en lo personal sigo con git flow
yo creo que eso de no poder confiar en alguien es por la competividad, yo creo que la neta es por algo y es por que sinceramente yo no puedo confiar en las demás personas
Me parece sumamente interesante tu punto de vista aunque estoy totalmente en desacuerdo, una parte de una buena gestión de proyectos es saber asignarle sentido a los commits con forme al desarrollo, claro que hay mucha maneras de gestionar el modo de versionar, ya sea con convencional commits, atomic commits, git flow, etc, sin duda mi preferencia va ser el gitflow, tomando el tema de revisión de código muchos desarrolladores toman la revisión de código como micromanagament ya que no les gusta que le revisen su código, ya sea para evitar si tiene code smell o algún bug que no se detecto en pruebas ya que las pruebas demuestran la presencia de ellos , no su ausencia, es bueno revisar todo antes de subir a pre producción y producción.
Pues creo que el punto de no usar Git Flow sería tener al día el CI y saber usar bien Git. El tema de la estrategia debe pasar primero por esa parte, de tener el testing y el CI bien cconfigurado para que todo esté en orden, así no hay temor de hacer merge a master ni hacer deploy los viernes, porque hay garantías antes de llegar a producción.
En ocasiones personas hacen cambios en el codigo, luego van a fixea el test, el test pasa pero en prod se rompe, porque el test se modifico, para permitir el cambio...
Me sorprende que este tipo digas cosas como "Cada quien sabe lo que tiene o debe subir", joder en serio? Estás hablando seguramente de un projecto pequeño, donde no hay rotaciones y todos se conocen desde hace mucho tiempo, tienen grandes habilidades y hay una gran sinergía. Y bueno, si este es el caso, felicitaciones, porque tu flujo de versionamiento puede funcionar y pueden ser más eficientes tal vez. Pero ese no es el mundo real amigo, así no es como lucen los proyectos allá afuera, tal vez aquí en youtube si, pero allá afuera no. Allá afuera te encuentras con empresas que tienen un producto "maduro" siendo usado por muchas otras empresas, con muchos módulos, con un flujo de CI/CD bastante automatizado, tal vez usando el model de Feature flags para hacer el delivery al cliente y con muchas rotaciones en el equipo ( despidos, renuncias, licencias x vacaciones, etc ). En un escenario como este, un nuevo team member, va a requerir incluso meses, para alcanzar una adpatación exitosa al proyecto.. y en serio de buenas a primeras le diras que suba a master lo que el crea conveniente? Joder
Creo que sería un buen desafío trabajar como freelancers un tiempo para no depender de que esten revisandote el codigo todo el tiempo, es decir, que uno haga lo que tiene que hacer y se autogestione. En mi parecer eso puede aportar bastante en cuanto a tomar responsabilidad.
@@midulivepruebas de integración, pruebas funcionales, pruebas unitarias (todo eso se puede con JEST dando como ejemplo JS/TS). Pruebas de comportamiento/componentes/e2e con Cypress. Con todo eso, pero hecho a conciencia y con todos los casos de uso necesarios, se puede reemplazar las pruebas manuales de QA, pero no en 100%. Pero depende de los recursos y prioridad de tu negocio.
@@paulomirandaarias9544para eso también existen los Feature Flags, las Canary Releases, los Rollbacks automáticos... Nunca nada es al 100%, pero se puede reducir la incertidumbre con cada paso. Por ejemplo, en la última empresa en la que yo estuve, se hacía despliegue a producción continuamente, sólo que muchas features estaban desactivadas y luego se activaban bajo demanda.
Cómo haces que la gente crezca si no sabe ponerle el nombre correcto a una variable? Es cierto que alguien puede ser muy picky, pero hay nombres que no van. Ese tema es tan importante que hay capítulos enteros de libros dedicados al nombre de una variable.
En realidad el flujo prohíbe ir a máster directo no por qué no confíes en la gente, si no para evitar errores humanos tontos, si alguien más ve lo que vas a subir es más probable que ves esos errores tontos y no van a ir a prod
Es infantil pensar que por muy responsable no te puedas equivocar, el tema del control del código y la revisión pasa por un tema que los programadores se equivocan, las maquinas no se equivocan son los programas con errores, y revisar y controlar los errores no es un tema de guardería, este tío tiene un tema ahí..
Un profesor de la uni nos comento una anecdota muy graciosa, que hace años el tenia un problema con linux, asi que uso una especie de libreria en el sistema operativo, la cosa fue que encontro la solucion en internet como un parche y le pregunto al que lo creo, todo normal le funciono, y desde entonces lo seguia en twitter, paso el tiempo y el creador de ese aprche publica en twiter feliz de cumplir 16 años, el profesor quedo como que en serio?, entonces le comento, a lo qu el le responde que es cierto, entonces es cuando uno se da cuenta que si esas materias las aplican desde las escuelas a temprana edad, tendras un nivel de desarrollo aceptable cuando ya empices la carrera o antes de ella :D, para hacer soluciones de S.O. es genial
Pues esta estrategia desde mi punto de vista serviria solo para aquellos que tienen la suficiente experiencia en el PRODUCTO y CONOCIMIENTO. Porque fallar en el SHIP puede ser algo tan sencillo como hacer un MENSAJE pero del cual puedas tener errores de ortografia, entonces luce a SHIP pero puedes tener un mejor mensaje de la salida de un code review. SHOW seria cuando tienes implementacion que vaya a extender tu codigo (sobre algo que ya existe) ASK seria cuando tienes una implementacion totalmente nueva relacionado a patrones de disenio, arquitectura. Suena bien pero creo que se necesita personas con muchos anios en el PRODUCTO y tener el TEAM bastante seguros para hacer un SHIP :)
@@midulive Sip entiendo, solo me puse analizar un SHIP que puede ser considerado tan sencillo pero a la vez no, porque depende el nivel de confianza que te tengas y la experiencia que tengas en el PRODUCTO y EQUIPO, porque al fallar en un SHIP seria algo muy terrible, porque tendrian que volver a crear otro PR para resolver lo que fue considerado muy sensillo.
creo que el ejemplo que pones de no somos niños, lo dices como si vivieras en un mundo de adultos responsables, xd que hasta me hace pensar ami que o wao yo quisiera saber dónde él trabaja que todos se hacen responsables de sus cosas y cuando hay un fallo ese da la cara por el fallo, nadie en su sano juicio quiere cargar con un error y más si este error genera pérdidas en la empresa que te echaran del empleo, la gente está muy cuidadoso con lo que hace y con lo suyo porque si no gana dinero quien le dara de comer algunas otras personas tiene más presión que tienen deudas, hijos, hipotecas y muchas otras cosas que cualquier mínimo mes sin empleo ya se quieren matar, y tu siendo una empresa que por un error de un programador va y falla a que no revisamos el código y que fulano tiene que arreglar lo que mando ósea las empresas no funcionan asi xD la mrd le cae al que más sabe del sistema para que lo corrija rápido y no se pierdan más dinero porque el sistema está fallando, esos sistema de revisar el pullrequest no estan por molestar, estan porque un sistema se cayó y se perdió millones, o alguien mando un código y lo mando con malas intenciones o para crear una desviación o una puerta trasera y nadie lo reviso, cada aviso que nosotros vemos en la calle es porque alguien ya hizo lo que ese aviso está prohibiendo o la peor situación paso por lo que se intenta prevenir que no pase de nuevo
cosas malas de aprender de jovenes. el 30% de lo que aprendi ya no sirve porque todo se actualiza. y tampoco podia trabajar con eso. ahora se 16 lenguajes y solo uso 2 ajjaja empezar de niño no sirvio para nada mas que para aprender a hacer jueguitos. y bueno si se quejan por no tener logica de algoritmos eso ya es un problema psicologico. los que veo que tienen ese problema veo que desde ya antes tenian ese problema de pensar con logica. basta con verlos discutir en sus casas, no son justos, son egoistas y toxicos. no se detienen a pensar y son impulsivos. desde un principio una chica sin conocimientos a lo mayor pude enseñarle y aprendio lo que yo aprendi en años de escuela en solo una semana o 2. que es programar? dar instrucciones. listo. no hay ni verbos ni conjugaciones. no es nada del otro mundo. todos pueden
creo que me baje bastante. no son 16 lenguajes son 20. pero los de programacion que se son 16. y en realidad go ya lo olvide pero aprendo rapido igual. solo que odio sus librerias poco intuitivas de ftm_nose que mas promp? no me acuerdo al 100% todo pero en un ide recuerdo y me manejo fluido en 7 lenguajes c++,java,processing,python,c#,javascript y c
Uy uy uy, eso de mergear sin revisar!? Como supongas que todos son responsables... Vamos buenos! No se si te habrá funcionado, pero yo diría que eso no va.
Claro que lo he probado. Y ha ido bastante bien . Obviamente cuando se trabaja con gente profesional y organizaciones maduras. No es que se pueda en todos los sitios, claro.
Si todos los programadores fuesen buenos entonces vale dejemos a los genios que hagan lo que quieran, un buen tech lead esta a cargo de la calidad de su software y su producto punto.
Por lo que dices entonces el Tech Lead debería mentorizar más que simplemente controlar. ¿No? O nunca serán buenos y tendrán que ser supervisados siempre.
Afortunadamente he tenido dos cargos que me dan puntos de vistas variados respecto al tema de "no son niños":
Trabajé como líder técnico en múltiples proyectos de I+D con equipos pequeños de 3 o 4 programadores (y en compañía con otros equipos técnicos: mecánicos, electrónicos, telecos, etc). Y mi prioridad siempre fue enseñar y hacer que cada uno de mi equipo fuera capaz de tomar decisiones. ¿Que el junior decidió usar variables con nombres "a", "b", "c" en vez de nombres descriptivos? pues nada, reunión de 10 minutos solo con el (las correcciones siempre en privado, los halagos siempre en publico) señalandole la razón por la cual es mejor usar otro tipo de nombres. Y luego, lo acompaño mientras corrige el mismo el problema para que me pueda preguntar de ser necesario; En algunos casos volvían a "cagarla" pero al recordarles lo arreglaban ellos solos, y de hecho, con el tiempo y con la confianza en si mismos empezaban a arreglarse las cosas entre ellos e incluso a recomendarme cosas a mi.
Por otra parte, ahora mismo trabajo como consultor de procesos de negocios, les he hecho consultoría a múltiples empresas (bancos, inversoras, fiscalías, productoras importadoras, etc). Y una regla primordial son los controles cruzados. Si una persona hace algo, el mismo no puede "revisar" lo que hizo, lo tiene que hacer otro, y dejar una evidencia de que lo hizo. Riesgos y Controles; para muchas empresas no es una "decisión", es una exigencia legal.
Estoy de acuerdo con esto de "no son niños" y que cada uno sepa que hacer y como hacerlo, pero siempre debe haber un control. Si tenemos integración continua con pruebas bien hechas entonces perfecto: push a master y que un senior haga revisiones esporádicas cada tanto (idealmente dejando un comentario, correo o lo que sea como evidencia). ¿Que no tenemos buenas pruebas? pues lastimosamente veo necesario ir a punta de PRs en lo que arreglamos lo de las pruebas.
Obviamente todo depende del proyecto, si estas haciendo la web comercial de aceitunas pepito, te puedes tomar ciertas licencias. Pero si estás desarrollando el sistema que opera un equipo médico que cuesta millones... mientras mas controles, mejor.
En resumen: Estoy de acuerdo 100%: Seamos buenos profesionales y ayudemos al resto a ser mejores, pero siempre tengamos controles (si son automáticos mejor).
Leerte me ha enseñado mucho, muchas gracias por tomarte la molestia de compartir desde tu experiencia este valioso conocimiento :)
xdxdxxdx
Gracias por ese comentario, tus puntos de vista me han ayudado a entender mejor un grande
Gracias por ese comentario, tus puntos de vista me han ayudado a entender mejor un grande
uff! que rica lección de vida! gracias
Actualmente comienzo como responsable de proyecto, que puede ser algo como líder técnico ya que tengo la responsabilidad de que las implementaciones de mis compañeros funcionen, y funcionen bien. Por ende, como las buenas prácticas era algo ausente en dicho proyecto (aún lo es pero, tenemos mucho por delante), mis compañeros no se esfuerzan demasiado en mejorar el código existente y a veces siguen las malas prácticas porque les es más fácil copiar y pegar (cosa que no paro de reclamarles).
Como no tengo experiencia como líder estaba a punto de comenzar a pedir y revisar cada PR de mis compañeros a fin de corregir lo que viese mal.
Pero entonces mencionaste que, en efecto, no somos niños. Es algo complicado de explicar cómo tus pocas palabras me empezaron a abrir los ojos, así que lo resumiré con que acabas de darme una bofetada que me aclaró bastante el panorama y te agradezco por ello
Mola lo que comentas y es una alternativa muy válida, lo que no haría es decir algo es blanco o negro, todo parte de un compromiso y hay que encontrar el criterio correcto. Git flow es otra estrategia totalmente válida que seguir y en algunos casos puede ser más productiva que lo que comentas, lo digo por la miniatura. Aparte, No entiendo por qué usar Ship/Show/Ask no permite usar ramas feature, develop, release, bugfix etc. puedes comitear en cualquier rama usando la regla del Ship/Show/Ask
Que crack Midu!! Me encantó la simpleza 👏
En mi opinion aun siendo senior puede implementar malas practicas.. prefiero siempre crear PR y dependiendo de las prioridades se puede usar el "SHOW", pero nunca SHIP
Qué maravillosa tu forma de transmitir conocimiento. Gracias.
Gracias, Javier!!!
@@midulive A ti por compartir tu vocación, de verdad.
Lo de asumir responsabilidades como profesionales y ese convencimiento... No podría estar más de acuerdo.
Realmente lo que dice midu sobre la infantilización es real.
Hace poco en un trabajo universitario estaba como líder de mi equipo y tuve que aprender por las malas que hay que delegar no solo trabajo sino también responsabilidades y confiar en el equipo (además de penalizar si se ha hecho mal).
En mi caso trabaje con un grupo de personas sin mucha experiencia y al principio hacia de profesor y de guía un poco pero después se formo un bucle en el que además de hacer mi trabajo debía revisar el del resto y corregirlo, bucle que se genero tanto desde mi lado como el del equipo, que se enojaba si no estaba ahi para corregir.
El tema es que al final aprendí que en vez de ese approach es muchísimo mejor simplemente delegar, las personas adultas son capaces de ver si tienen un error en develop o en producción y solucionarlo, y aunque tu podrías hacerlo más rápido... NO SOMOS SUPERMAN
Así que, lo siento a mi equipo y también a mi mismo, espero que esta experiencia le ayude a otras personas que estén viviendo cosas similares.
Me he reído bastante viendo este video. Esto es solo recomendable para proyectos nuevos o pequeños o que no sean críticos, o en empresas cuyo proceso de contratación es lo suficientemente exigente como para que los equipos tengan recursos con un alto conocimiento, pensamiento crítico y responsabilidad. Mi buen amigo Murphy me ha enseñado que si algo puede salir mal, seguramente saldrá mal; además, los procesos de desarrollo de software deben minimizar los riesgos. Permitir que cualquier recurso haga cambios no supervisados que se reflejen a producción, bajo la bandera de "no son niños", atenta contra la continuidad del negocio que exige todo proyecto serio de software.
Para minimizar los riesgos hay mil formas mejores que controlar manualmente el código que se añade y seguir un proceso tan farragoso como Git Flow. Testing, CI/CD, rollbacks automáticos basados en métricas, Mob Programming…
@@midulive Te recomiendo leer nuevamente mi comentario, parece que te has confundido con otro.. Claramente estoy diciendo que en proyectos de verdad (grandes o críticos o que exigen una alta continuidad de negocio) no se puede dejar sin supervisión a los desarrolladores solo porque "no son niños", caso contrario se adquieren riesgos innecesarios contra la funcionalidad del sitio o contra la seguridad de los clientes que podrían repercutir en sanciones legales.. Jamás he dicho que el code review deba ser 100% manual, hay 10000 utilidades que permiten simplificar este proceso; pero, no por eso vamos a dar el poder a los recursos de autorevisarse y autoaprobarse.. Y puntos importantes que debes tener en cuenta: Los equipos deben tener integrantes con roles definidos. Que un desarrollador sea SR no significa que no cometa errores. Que un JR nunca llegue a SR es porque jamás salió de su zona de confort, ni se educó, ni mostró a su líder las habilidades para solucionar problemas eficientemente.. Obviamente sí hay líderes tóxicos y nocivos que centralizan todo y que no dejan crecer a sus recursos, pero eso ya es cosa de las empresas que mantienen líderes así, y no es el común denominador en el mercado.. Me asusta que digas que tu empresa va a implementar esta filosofía de "sube lo que quieras porque no eres un niño", porque eso solo significa que se ahorrarán dinero en los responsables de supervisión y les asignarán más responsabilidades a los desarrolladores innecesariamente, o que hacen puros desarrollos pequeños que no requieren seguir un proceso adecuado de software.
@@itenrioarq creo que el punto de midulive es muy bueno, yo creo que en esta industria no hay que ser cuadrados, yo pensaba como tú pero hay que evolucionar y la verdad es que con unos buenos pipelines bien implementados para tdd, bdd, etc... con sus respectivos rollbacks automatizados, el pull request es un cuello de botella innecesario
Esta estrategia funciona perfectamente para equipos pequeños y productos para startups donde los costes, los presupuestos y los tiempos de entrega tienen un peso mucho mayor a la calidad del producto, como por ejemplo cuando desarrollas un MVP. Pero para equipos grandes que gestionan productos maduros y que trabajan con múltiples microservicios que iteroperan y que pueden haber en un momento features que no son compatibles en determinadas versiones no es viable.
No siempre el continous delivery es la estrategia conveniente para todos los proyectos. Cuando tienes que entrega un código con un estandard alto de calidad y un producto con buenos niveles de escalabilidad y resiliencia.
Se podría argumentar que siempre se puede echar para atrás si algo explota, implementar estrategias de rollback o despliegues blue/green, para evitar que se caiga el servicio, pero entonces el tiempo que te ahorras en verificación y pruebas de tu código integrado, los vas a gastar en sacar fixes por desplegar en producción o en stage releases con bugs, que es en mi opinión hacer retrabajo pero con el riesgo de colar errores no identificados en producción.
"El que decide eres TU, porque no eres un niño" Hermoso!
Y el link de tu libro de git?
Usar Feature Flags con unleash es una buena opción también.
Sip. De hecho es genial para integrar en la rama principal pero dejar la feature desactivada.
Totalmente de acuerdo contigo, el micromanagement y ese pensamiento de yo, como lead, soy el único ser con capacidad e inteligencia universal para hacer las cosas bien solo llevan a frustración de los compañeros que ven que no avanzan, un cuello de botella increíble que se carga todo el agile y CI/CD que tiene la empresa jajaja.
A mi muchas veces me preguntan sobre desarrollos en progreso y aunque sepa que esta mal les digo: si tú lo ves bien, adelante o no veo nada raro/mal a priori.
Con la intención de que después de estar todo un día con eso llegan al punto en el que por ellos mismos se dan cuenta de que hay algo que hace inservible su estrategia y deben de empezar de 0. Es un poco putadita pero si no te equivocas a veces....
Hasta ahora he recibido más "gracias" que "joder ya me podrías haber avisado", porque así realmente aprenden varias cosas que les ayuda a subir de nivel, una de ellas es la de plantear si con esa estrategia va a funcionar todo, antes de ponerse a picar nada de código con lo primero que les parece "aceptable".
Por supuesto soy coherente con el tiempo que sé que van a invertir en equivocarse y jamás se me ocurriría que perdieran 3 días de trabajo, en ese caso hay otras estrategias, como empezar a preguntar ¿Qué pasaría si....? para intentar guiarles hasta el fallo, etc.
Yo estuve en un proyecto grupal para un proyecto y bueno en cierto sentido estuve de apoyo si el equipo lo necesitaba y tal. pero aunque me inmiscuia un poco en como seria la logica del desarrollo no tenia pensado revisar el codigo de cada compañero. Pues llego el penultimo dia de desarrollo antes de entregarlo y me encontre que el codigo de un compañero no funcionaba nada y estaba absolutamente incompleto y fallos logicos. Los 2 dias de trabajo que me quede para mi se quedan
Creo de independiente del nivel que se tenga las revisiones de código son importantes tanto para el que genera el código como el que lo revisa, obviamente el revisor no puede tomar una postura cerrada siempre se puede crecer y aprender de todos revisando código y escenarios en donde le revisen el código a uno, esto con el objetivo de discutir y llegar a consensos de mejores practicas en la implementación del código.
Creo que este enfoque fuera correcto en un "mundo perfecto", tanton en recuso humano como en procesos de ingeniería. Yo al menos he estado en muchas empresas y ya me ha tocado liderar varios equipos, y es que los contextos son tan variables (porque como decimos, son personas, y las personas somos infinitemente diferentes en habilidades tanto blandas como técnicas) que es imposible que una fórmula "abierta" funcione bien en cada empresa. Por eso enfoques mas "guiados" siempre terminan siendo los mas adoptados de manera global. Me han tocado Devs con experiencia y excelentes habilidades en código, pero muy malos en la toma de decisiones, lo cual es medible solo a largo plazo (según cada quien vaya demostrando tal criterio). Muchos incluso me han pedido ser "explícito" en las instrucciones dado que sus mentes funcionan de manera bastante "literal", con esto quiero decir que no se trata de un concepto de que "son niños", si no de que todos tenemos distintas habilidades, unos para "seguir", "aprender", "ejecutar", otros para "liderar", "enseñar", etc... y bueno, a otros pues no se les da bien ninguna. ¿Que tienes que encargarte de que la gente "crezca" o avance?, estoy de acuerdo, pero creo que eso tiene que ver con liderazgo y no con el tema de conversación del video. Encasillar a todo el mundo en un marco de habilidades y asumir que todos son capaces de hacer algo lo encuentro fuera de la realidad (sobre todo en un mundo profesional donde somos bastante especiales en cuanto a personalidades jaja). Saludos!
gitflow para proyectos enano es un incordio, pero creeme como devops de varias apps de medio millon de lineas de codigo con casi 18 equipos en paralelo sobre esas mismas apps y con alta rotación, que o metiamos gitflow con ci/cd o moríamos de cara al cierre de sprint :D
Ya tengo el libro en casa para mi nueva andadura como DevOps Junior. Lo tendré a mano mientras me voy empapando de información sobre Kubernetes y Azure devops.
En mi caso, usaré GitLab.
Me convenciste, compraré tu libro
Me parece interesante lo que planteas, duda, dónde consigo tu libro, para empaparme más en el tema. Soy de la "vieja" escuela y lo que manejaba era TFS de Microsoft, ahora uso git flow, pero tú planteamiento me parece bueno.
Saludos.
Estoy de acuerdo con la mayoría de las cosas que dijiste, solo levantaria un par de consideraciones, todos los años se duplica el numero de trabajadores en el sector IT, por ende todos los años la mitad de la gente tiene menos de un año de experiencia. Esto no necesariamente te va a traer demasiadas cuestiones a nivel tecnico, pero si a nivel conocimiento de dominio y las implicancias de ciertos "pequeños cambios" en el usuario final, si bien estoy de acuerdo con que no deberia haber 1 persona que deba ver todo el código antes de pasar, me parece que tener estrategias donde te puedan dar feedback constante sobre lo que subis (sin comprometer la entrega continúa) es a lo que deberiamos apuntar (para crecer todos en el equipo). Esto significa tener lineamientos (que apliquen a la mayoria de casos) y un consenso del equipo sobre cuando usar cada tipo de estrategia de branching. De igual manera, el video me parece super para equipos maduros 😃
Igual en esta estrategia puedes usar Ask, que sirve exactamente para lo que comentas. No es que está la gente obligada a usar Ship y Show.
Además la idea es que las revisiones sigan ocurriendo aunque sea a posterior (Mob Programming)
@@midulive completamente de acuerdo, a lo que voy es que si me parece necesario una heurística consistente en el equipo para saber cuando usar uno u otro. Por ahi el criterio solamente individual puede generar conflictos en un trabajo colectivo (teniendo en cuenta que en los equipos hay, en gral, mucha diferencia en cuanto conocimiento de negocio)
Si no tienes soft skills el seniority no puede ser alcanzado. El problema del área de IT es que es muy difícil abordar dificultades grandes asumiendo la total responsabilidad como si pasa en otras industrias
No entendí, lo puedes explicar un poco más?
Incluso en una traducción se puede ir una falta de ortografía o una palabra mal escrita y si hay algo que hace desconfiar de la calidad del software son ese tipo de cosas. Está bien, una falta de ortografía no va a tirar el sistema y meterán una corrección después, pero ¿por qué no hacerlo bien desde el principio?
Aquí el problema que le veo son los egos individuales, los cuales claramente abundan en nuestro sector...y tienes que ser prácticamente psicólogo como para saber si puedes confiar en tu equipo hasta ese punto. Lo veo inviable en equipos con alta rotación o muy inexpertos pero interesante en equipos con experiencia
Hola, cuál es la web que dijo en el ultimo momento del video? 6:35
Me gustaria entrar a ver lo de los algoritmos.
Este vídeo vale oro
Señor senior, se cayó producción. Sernior: dejale eso al junior, todos somos grandes y responsables.
Me alegra que haya gente tan top como Midu. Gracias por compartir tu experiencia y puntos de vista, le sirven a muchos que apenas empezamos
En desarrollo de software no tenemos balas de plata, la mejor estrategia para el manejo de ramas en X proyecto, siempre va ser una con la cual el equipo tenga la mejor relación costo / beneficio. Lo anterior no significa que por eso gitflow o otro git workflow sea malo, simplemente va a depender del caso de uso y del contexto del proyecto, por eso siempre hay que analizar antes de...
Los que iniciamos temprano, es el hambre. Muchas veces es necesidad
Donde puedo aquirir tu libro de git?
Dónde vemos el libro o compramos el libro.??
Dodne se encontrá el libro?
Chavales, que no os engañen, Git Flow al completo es super versátil y hace predecible el versionado del código sin necesidad de llenarlo de condicionales. Aprended GitFlow de verdad. No os quedéis con develop/ + feature/, que es lo que suelen exponer estos creadores de contenido.
Lo único que puedo decir en contra es que plataformas como GitLab y GitHub no hacen agradable el proceso a través de Pull Requests.
Me hubiese gustado encontrar una explicación de por qué no usar Git Flow. El contenido del canal es muy bueno, pero personalmente paso de los videos “Tienes que hacer esto” o “No tienes que hacer aquello” como abundan en HolaMundo.
El vídeo esta cortado pero la explicación la tienes del propio autor de GitFlow: nvie.com/posts/a-successful-git-branching-model/
Básicamente, para aplicaciones web no tiene sentido.
Gracias por tomarte el tiempo para responder
Gracias por la exposición
Donde dijo que había ejercicios ???? En los últimos segundos 6:30
Cual silla usas máster ??
Entiendo que el objetivo del ask vs show es el Review. Dicho esto: push sin Review es un no. Salvo que sea un typo en un comentario, nada justifica un push sin Review (y para mí un typo no justifica un push). El principal motivo es para tratar de garantizar que el menos otra persona este de acuerdo en que el código es fácil de entender. Ese es el objetivo de un Review. Ahora si el tema hace pair programming, el Review ya está hecho y no es necesario un pr.
Como conseguir tu libro?
Buenas Midu, a ver, tengo mis sentimientos encontrados con este video. Te doy la razón de que el desarrollador se tiene que responsabilizar de que el código que produce es de calidad y pasa todos los tests / estandares, pero en caso de que no lo haga y lo mergeen, qué es lo que dices que se tiene que hacer en ese caso? Decirle que lo arregle? bien, es obvio, pero cuando tienes plazos de entrega y el cliente apretandote, estos fallitos que ocurren porque obviamente son Juniors, retrasan la entrega y normalmente cargan de faena a los más seniors.
Nosotros tenemos unas cuantas guías de los estándares de código que busca la empresa (evitar al máxima el código comentado, eliminar console.log residuales, etc) y hay desarrolladores Juniors que han hecho PRs y cuando la pruebas ves que no cumplen las guías de estandares, o que la funcionalidad está a mitad.
Si les dejáramos mergear directamente a develop nos encontraríamos con que la plataforma sería demasiado inestable, y tendríamos que estar reviertiendo commits / arreglando código una buena parte del tiempo.
Desde mi punto de vista, creo que no es tan perjudicial el que se le revisen las PR y se señalen los errores / cosas a cambiar y que sean ellos quienes los hagan (obviamente la tarea es suya) pienso que poco a poco el desarrollador Junior irá cogiendo soltura y sus PR cada vez serán más robustas y sin fallos hasta que llegue el día que sea él quien revise la de otros compañeros.
De esta forma evitas que código incompleto llegue a develop y al entorno de PRE ayudando a los más juniors y sin sobrecargar a los más seniors.
Todo lo que comentas ya viene amparado sobre la posibilidad de usar Ask. Si un dev no tiene nivel, existe la posibilidad de hacer PRs y pedir ayuda al resto del equipo para que se asegure que está bien el código.
También hay otra cosa:
- Con los juniors se puede/debe hacer Pair Programming justamente para evitar mucho de lo que dices.
- Cumplir los estándares debería estar lo más automatizado posible.
Hola midulive, donde puedo adquirir tu libro?
hay que hacer un merge de master a la rama funcional antes de hacer el pr? o solo hacer el pr y que la gente vea como resolver el merge?
Hola, estoy viendo de comprar el libro pero en ningún lado dice que cantidad de páginas tiene?
De cuántas páginas es? Y es formato libro donde hay 200 palabras por página o es formato tipo Powerpoint exportado a PDF/epub dónde lo terminas de leer en 20 solo minutos?
Gracias
Gracias Midu por tus palabras del seniority hay que responsabilizarnos, ! como me gustaría algún día estar en un equipo tuyo o trabajar contigo! y crecer como debería!. Por lo de Ship / Show / Ask, creo que lo hago ya.
Bonito mundo el que imaginas!
Así he trabajado los últimos años en una empresa de más de 1000 personas 😅
@@midulive que suerte tienen algunos jeje, es que la verdad no todos los desarrolladores tienen la madurez y responsabilidad como para pedir ayuda en caso de que sientan que algo falta.
pueeeeeeees, en una empresa que conoci, un programador hizo un cambio y lo subio directo a master sinconsultar porque segun el era consciente de que no iba a pasar nada malo y resulto en una perdida de 25 mil dolares en solo 4 horas
De tu historia lo más preocupante es que no exista un test que pueda evitar eso. Al final que lo suba a master o se haga merge desde una PR, hubiera pasado lo mismo.
Pregunta, si se hacen commits a master directamente ¿Se usan toggle flags como en trunk? o se tiene una rama dedicada a releases?
Midu, podrias hablar sobre django?
Yo empecé con 13 años pero fue solo curiosidad y un hobby, ni enterado estaba que esto podía ser un trabajo jaja igualmente si impresiona niños que con 14 años ya desarrollaron un editor de imágenes como Canva para una hackathon, o que hablan de temas más complejos para mejorar el rendimiento y la arquitectura de una aplicación 🤯
No estás buscando compañero para proyectos? Yo comencé joven también y ahora estoy llevando mi agencia de desarrollo
Cuál es la página web que dice en el último segundo?
Necesito pulir mis habilidades en git...(soy muy malo) creen que el libro de midu me sirva para ser "top" con git?
Hola! Alguien sabe donde consigo el libro de git de midu?
midu.link/git
Woo, en mi opinión es muy cuestionable esa opinión. Si se usa CI (con un sonarquve que vigile que no se hagan burradas, que todos hemos sido novatos) todo OK, pero en el mundo real hay multitud de proyectos que no saben de que va eso (y multitud de gente a la que no le importa no saberlo).
Si hablamos de mundo real, no todo desarrollador de software tiene ese mínimo de ganas por aprender. Muchos ni se preocupan por hacer las cosas medio bien. Basta con que a final de mes, cobren. Esa es la pura realidad... más quisiera yo que no fuese así, no habría cambiado 3 veces de empresa en un año buscando de trabajar en un equipo (y proyecto) con un perfil decente que me pueda aportar algo.
Suena interesante, pero no la llamaría "la mejor estrategia" siempre es discutible eso. Y lo otro que dices tienes razón no se puede revisar el código de todo el mundo pero es cuestión de confianza y eso se va ganando de a poco en un equipo. Saludos!
El que empieza joven, se vuelve canoso rapido .
Pues como que tampoco aporta mucho ese flujo, lo mas seguro es lo que se revisa, a veces por muy sabelo todo se te van curradas como un console.log, o algo que puede hacerse con alguna estructura mejor... por el momento en lo personal sigo con git flow
me caes tan bien...
Donde puedo conseguir tu libbro de git
yo creo que eso de no poder confiar en alguien es por la competividad, yo creo que la neta es por algo y es por que sinceramente yo no puedo confiar en las demás personas
Me parece sumamente interesante tu punto de vista aunque estoy totalmente en desacuerdo, una parte de una buena gestión de proyectos es saber asignarle sentido a los commits con forme al desarrollo, claro que hay mucha maneras de gestionar el modo de versionar, ya sea con convencional commits, atomic commits, git flow, etc, sin duda mi preferencia va ser el gitflow, tomando el tema de revisión de código muchos desarrolladores toman la revisión de código como micromanagament ya que no les gusta que le revisen su código, ya sea para evitar si tiene code smell o algún bug que no se detecto en pruebas ya que las pruebas demuestran la presencia de ellos , no su ausencia, es bueno revisar todo antes de subir a pre producción y producción.
Pues creo que el punto de no usar Git Flow sería tener al día el CI y saber usar bien Git. El tema de la estrategia debe pasar primero por esa parte, de tener el testing y el CI bien cconfigurado para que todo esté en orden, así no hay temor de hacer merge a master ni hacer deploy los viernes, porque hay garantías antes de llegar a producción.
Totalmente de acuerdo. Sin un buen CI o tests es imposible lo que digo. Pero vaya, tampoco haría Git Flow. 😅 si no que aprendería Git.
En ocasiones personas hacen cambios en el codigo, luego van a fixea el test, el test pasa pero en prod se rompe, porque el test se modifico, para permitir el cambio...
Me sorprende que este tipo digas cosas como "Cada quien sabe lo que tiene o debe subir", joder en serio?
Estás hablando seguramente de un projecto pequeño, donde no hay rotaciones y todos se conocen desde hace mucho tiempo, tienen grandes habilidades y hay una gran sinergía. Y bueno, si este es el caso, felicitaciones, porque tu flujo de versionamiento puede funcionar y pueden ser más eficientes tal vez.
Pero ese no es el mundo real amigo, así no es como lucen los proyectos allá afuera, tal vez aquí en youtube si, pero allá afuera no. Allá afuera te encuentras con empresas que tienen un producto "maduro" siendo usado por muchas otras empresas, con muchos módulos, con un flujo de CI/CD bastante automatizado, tal vez usando el model de Feature flags para hacer el delivery al cliente y
con muchas rotaciones en el equipo ( despidos, renuncias, licencias x vacaciones, etc ). En un escenario como este, un nuevo team member, va a requerir incluso meses, para alcanzar una adpatación exitosa al proyecto.. y en serio de buenas a primeras le diras que suba a master lo que el crea conveniente?
Joder
tienes toda la razon.
cual es tu libro? 🤭
Creo que sería un buen desafío trabajar como freelancers un tiempo para no depender de que esten revisandote el codigo todo el tiempo, es decir, que uno haga lo que tiene que hacer y se autogestione. En mi parecer eso puede aportar bastante en cuanto a tomar responsabilidad.
Recomiendo GitFlow
¿Donde consigo el libro? Gracias!
midu.link/git
¿llevar directamente a master sin pasar QA? estoy confundido, no lo se Rick
En master deberías tener QA automatizado antes de poder pasar a producción. Siempre.
@@midulivepruebas de integración, pruebas funcionales, pruebas unitarias (todo eso se puede con JEST dando como ejemplo JS/TS). Pruebas de comportamiento/componentes/e2e con Cypress. Con todo eso, pero hecho a conciencia y con todos los casos de uso necesarios, se puede reemplazar las pruebas manuales de QA, pero no en 100%. Pero depende de los recursos y prioridad de tu negocio.
@@midulive bueno Midu me tocaría estudiar más acerca del tema porque todavia tengo mis dudas 😅😅
@@paulomirandaarias9544para eso también existen los Feature Flags, las Canary Releases, los Rollbacks automáticos...
Nunca nada es al 100%, pero se puede reducir la incertidumbre con cada paso.
Por ejemplo, en la última empresa en la que yo estuve, se hacía despliegue a producción continuamente, sólo que muchas features estaban desactivadas y luego se activaban bajo demanda.
Cómo haces que la gente crezca si no sabe ponerle el nombre correcto a una variable? Es cierto que alguien puede ser muy picky, pero hay nombres que no van. Ese tema es tan importante que hay capítulos enteros de libros dedicados al nombre de una variable.
Midu contrátame
hablas mucho de tu libro pero, no dices como conseguirlo
En realidad el flujo prohíbe ir a máster directo no por qué no confíes en la gente, si no para evitar errores humanos tontos, si alguien más ve lo que vas a subir es más probable que ves esos errores tontos y no van a ir a prod
Para errores tontos, mejor los tests que tener un proceso como Git Flow.
Es infantil pensar que por muy responsable no te puedas equivocar, el tema del control del código y la revisión pasa por un tema que los programadores se equivocan, las maquinas no se equivocan son los programas con errores, y revisar y controlar los errores no es un tema de guardería, este tío tiene un tema ahí..
Un profesor de la uni nos comento una anecdota muy graciosa, que hace años el tenia un problema con linux, asi que uso una especie de libreria en el sistema operativo, la cosa fue que encontro la solucion en internet como un parche y le pregunto al que lo creo, todo normal le funciono, y desde entonces lo seguia en twitter, paso el tiempo y el creador de ese aprche publica en twiter feliz de cumplir 16 años, el profesor quedo como que en serio?, entonces le comento, a lo qu el le responde que es cierto, entonces es cuando uno se da cuenta que si esas materias las aplican desde las escuelas a temprana edad, tendras un nivel de desarrollo aceptable cuando ya empices la carrera o antes de ella :D, para hacer soluciones de S.O. es genial
O porque no hacer Trunk base development, todo en máster y punto, se trabaja haciendo pairing y ya está
Creo que Midu está cansado de revisar PRs ajenas jajaja
Pues esta estrategia desde mi punto de vista serviria solo para aquellos que tienen la suficiente experiencia en el PRODUCTO y CONOCIMIENTO.
Porque fallar en el SHIP puede ser algo tan sencillo como hacer un MENSAJE pero del cual puedas tener errores de ortografia, entonces luce a SHIP pero puedes tener un mejor mensaje de la salida de un code review.
SHOW seria cuando tienes implementacion que vaya a extender tu codigo (sobre algo que ya existe)
ASK seria cuando tienes una implementacion totalmente nueva relacionado a patrones de disenio, arquitectura.
Suena bien pero creo que se necesita personas con muchos anios en el PRODUCTO y tener el TEAM bastante seguros para hacer un SHIP :)
La estrategia es seguir las 3 a la vez y elegir en cada caso la que mejor encaje. No hace falta elegir sólo una.
@@midulive Sip entiendo, solo me puse analizar un SHIP que puede ser considerado tan sencillo pero a la vez no, porque depende el nivel de confianza que te tengas y la experiencia que tengas en el PRODUCTO y EQUIPO, porque al fallar en un SHIP seria algo muy terrible, porque tendrian que volver a crear otro PR para resolver lo que fue considerado muy sensillo.
creo que el ejemplo que pones de no somos niños, lo dices como si vivieras en un mundo de adultos responsables, xd que hasta me hace pensar ami que o wao yo quisiera saber dónde él trabaja que todos se hacen responsables de sus cosas y cuando hay un fallo ese da la cara por el fallo, nadie en su sano juicio quiere cargar con un error y más si este error genera pérdidas en la empresa que te echaran del empleo, la gente está muy cuidadoso con lo que hace y con lo suyo porque si no gana dinero quien le dara de comer algunas otras personas tiene más presión que tienen deudas, hijos, hipotecas y muchas otras cosas que cualquier mínimo mes sin empleo ya se quieren matar, y tu siendo una empresa que por un error de un programador va y falla a que no revisamos el código y que fulano tiene que arreglar lo que mando ósea las empresas no funcionan asi xD la mrd le cae al que más sabe del sistema para que lo corrija rápido y no se pierdan más dinero porque el sistema está fallando, esos sistema de revisar el pullrequest no estan por molestar, estan porque un sistema se cayó y se perdió millones, o alguien mando un código y lo mando con malas intenciones o para crear una desviación o una puerta trasera y nadie lo reviso, cada aviso que nosotros vemos en la calle es porque alguien ya hizo lo que ese aviso está prohibiendo o la peor situación paso por lo que se intenta prevenir que no pase de nuevo
cosas malas de aprender de jovenes. el 30% de lo que aprendi ya no sirve porque todo se actualiza. y tampoco podia trabajar con eso. ahora se 16 lenguajes y solo uso 2 ajjaja empezar de niño no sirvio para nada mas que para aprender a hacer jueguitos.
y bueno si se quejan por no tener logica de algoritmos eso ya es un problema psicologico. los que veo que tienen ese problema veo que desde ya antes tenian ese problema de pensar con logica. basta con verlos discutir en sus casas, no son justos, son egoistas y toxicos. no se detienen a pensar y son impulsivos. desde un principio una chica sin conocimientos a lo mayor pude enseñarle y aprendio lo que yo aprendi en años de escuela en solo una semana o 2. que es programar? dar instrucciones. listo. no hay ni verbos ni conjugaciones. no es nada del otro mundo. todos pueden
creo que me baje bastante. no son 16 lenguajes son 20. pero los de programacion que se son 16. y en realidad go ya lo olvide pero aprendo rapido igual. solo que odio sus librerias poco intuitivas de ftm_nose que mas promp? no me acuerdo al 100% todo pero en un ide recuerdo y me manejo fluido en 7 lenguajes c++,java,processing,python,c#,javascript y c
Me encanta :D
Uy uy uy, eso de mergear sin revisar!? Como supongas que todos son responsables... Vamos buenos! No se si te habrá funcionado, pero yo diría que eso no va.
Claro que lo he probado. Y ha ido bastante bien . Obviamente cuando se trabaja con gente profesional y organizaciones maduras. No es que se pueda en todos los sitios, claro.
jajaja, se supone que saben!!!
Work
mucho bla bla, deberías de ir directo al tema
Si todos los programadores fuesen buenos entonces vale dejemos a los genios que hagan lo que quieran, un buen tech lead esta a cargo de la calidad de su software y su producto punto.
Por lo que dices entonces el Tech Lead debería mentorizar más que simplemente controlar. ¿No? O nunca serán buenos y tendrán que ser supervisados siempre.