Discrepo Programador X, llevo 40 años programando y en la actualidad la parte mas importante para un buen proyecto es documentar los procesos de forma clara y los diagramas de flujo son una herramienta que ayuda a visualizar el problema. Estas herramientas son para comunicar ideas no solo lógica y el problema es que a muchos no les gusta documentar o lo hacen de forma poco clara.
Si les gusta trabajar de forma desordenada y sin involucrar al cliente pues háganlo sin diagramas... Pero por mi propia experiencia con más de 10 años desarrollando software les puedo decir con toda certeza que "más que un diagrama que respalda la funcionalidad y lógica de un sistema, es un respaldo para el desarrollador qué el cliente debe comprender y firmar de aceptación, puesto que en la mayoría de casos el proyecto evolucionara a tal punto de que el cliente pensara que algo no funciona como se debe, pese a que así quedo establecido en el diagrama" entonces es un respaldo para que si el cliente desea hacer un cambio o simplemente no aceptar la funcionalidad que pidió y quedo plasmada, se deberá cobrar más por el esfuerzo extra al desarrollo... SEAN ORDENADOS, LOS PROCESOS ESTÁN PARA SEGUIRSE Y DOCUMENTAR SU EVOLUCIÓN QUE LES SERVIRÁ DE RESPALDO ANTE CUALQUIER CONTRARIEDAD...
los diagramas de flujo sirven para aprender. Pero los diagramas UML si se utilizan bastantes, pero creo que es super importante saber plasmar tu idea o tu arquitectura en un diagrama. Lo digo porque he leído comentarios de gente que dice que solo hay que saber echar codigo
Para comunicar ideas el más importante sería diagrama er y de clases, pero a parte de esos muy raro usar otros, el resto de diagramas uml son verbosos o aportan poco (secuencia, casos de uso, componentes). Pero vamos, que la burocracia por desgracia está en todo lado.
En mi opinion, los diagramas de flujo son un lenguaje de alto nivel que permite plasmar de manera clara y sencilla un proceso, donde no solo lo entienda un desarrollador, sino cualquier persona con pensamiento analitico. Para la empresa que trabajo lo utilizo mucho para presentar los procesos a la gerencia de como el software trabaja o esta diseñado de manera interna y sin conceptos tecnicos; de esta menera los demas departamentos logran comprender los procesos, no tanto como el software lo maneja sino como la empresa opera sobre los mismo, logrando asi y comunicacion mas efectiva cuando los demas departamentos nos envian los requerimientos. La falta de esta práctica es lo que ha provocado que la famosa metodología agil no sea tan efectiva (agil) porque al no tener los procesos definidos como se comunican unos con otro, hace que siempre se redunde en lo mismo. PD: Esto es un trabajo del analista o jefe de proyecto definir estos diagramas, no del desarrollador como tal como lo hacen una gran parte de las empresas.
Yo aprendi a programar a los 11 años y precisamente fueron los diagramas de flujo los que ayudan a aprender. Y en mis casi 30 años de experiencia como desarrollador, tengo que decirte lo siguiente. Los diagramas de flujo son herramientas increíblemente útiles para visualizar y entender procesos complejos, similar a cómo un mapa guía a los viajeros. Aunque no tienen un estándar único, muchos lenguajes de modelado como UML y BPMN incorporan sus conceptos. Esto significa que usar estos estándares es, en esencia, utilizar diagramas de flujo. Saber crear y leer diagramas de flujo puede ahorrarte tiempo y esfuerzo, mejorando la planificación, comunicación y ejecución de proyectos, sobre todo con el personal no tecnico. Tienes que entender que los diagramas de flujo tienen un proposito. Puedes describir flujos de programa, pero tambien de negocio. Y tambien puedes ir de lo general a lo particular. Y como todo, debe usarse en su justa medida, pero jamas va a ser una herramienta a desechar por mucha opinion que exista en el mundo al respecto.
Concuerdo, soy arquitecto de sw y esos diagramas son vitales para dar a entender el diseño de la arquitectura a mis compañeros, si bien no son como tal diagramas y a estas alturas son más garabatos pero funciona muy bien y no veo otra forma de explicar una arquitectura a un equipo multidisciplinario, posiblemente un desarrollador pueda evitarlos pero como arquitecto es vital. Pero tampoco creo diagramas de procesos específicos esos si no valen la pena, son muy mutables
Si son una herramienta útil para visualizar un problema o comunicar una idea y dependiendo del nivel de detalle se puede usar c4 model. Igual cualquier herramienta es buena con su uso correcto, el título debería ser algo como, no uses diagramas en estos casos o no usar diagramas para documentar detalles etc
El diagrama de flujo es el esquema de un algoritmo. No es código, es un programa universal en forma gráfica que sirve para cualquier lenguaje de programación. Los programadores que se van directo al código (la inmensa mayoría) tienen atrofiada la capacidad para hacer diagramas de flujo. Lo ideal es saber hacer diagramas de flujo antes de hacer el código, con esto es más fácil depurar el programa y corregir errores. Después hacer el código ya sería mero trámite.
En absoluto, llevo 30 años trabajando en desarrollo de software, he pasado por infinidad de proyectos y empresas, desde las más grandes hasta pequeñas y, nadie trabaja o documenta con diagramas de flujo. Simplemente es inaplicable al momento de trabajar en grandes proyectos con cientos y cientos de rutinas, en esos casos, lo más valioso es una buena documentación funcional, para entender el negocio y una alta calidad de código, bien estandarizado y bien modularizado.
No es que no sirvan, es que no sabes como usarlos. Alguna vez me paso tambien que dije: Tengo 10 años como project manager y mi experiencia me dice que no puedes administrar un proyecto de software con graficas de Gantt. Hasta que me enviaron a un curso donde me enseñaron como si se puede. Creo que es más importante investigar porque nacieron en primer lugar el uso de diagramas, que problemas habia y como solucionaban la problemática. Tal vez después de analizar te vas a dar cuenta que si es mejor usarlos y en vez de decir que no se usan en la vida real, puedes descubrir que son una gran herramienta y difundas la buena practica. Y solo por si te preguntas, tengo 25 años programando y no lo he dejado a pesar de dirigir los proyectos.
Yo uso flowgorithm para enseñarle a mis alumnos a programar y me da buenos resultados hasta que aprenden la lógica. Además convierte automáticamente los diagramas a distintos lenguajes como python o javascript
Yo soy arquitecto de sw y los uso mucho pero no son como tal diagramas de flujos son más como garabatos pero me sirven mucho para diseñar la arquitectura y abstraer procesos para modularizarlos pero uso mucho las cajas grises, esas cajas grises son procesos abstraidos y me sirve mucho para que el resto del equipo entiendan que se hace y en que ayuda lo que hacen o por que es importante lo que se hace
Más alla de si usas o no diagramas de flujo que puede ser una herramienta visual poderosa para hacer comprender las necesidades de negocio, es saber abstraer las necesidades desde alto nivel y bajarlas a nivel técnico y eso significa que debes entender los contextos acotados, entender el dominio que se expresa dividirlo en historias de usuario y determinar los casos de uso de cada uno con sus reglas de negocio. Eso es lo esencial, ya que estas reglas busquen expresarse con diagramas de flujo o lo que sea es distinto
Trabajo en proyectos pequeños, programo microcontroladores en lenguaje ensamblador. Los diagramas de flujo a veces ayudan, pero es verdad, el pseudocódigo es más rápido e igual de efectivo.
el que no sea comun no es que no sirva, además sirven para desarrollar la logica de programacion. Si bien cuando ya estas con el tiempo enciama ya debes llegar y programar, para hacer eso antes es necesario tener un nivel de abstraccion muy bueno, buena logica de programacion y conocer el lenguaje que utilizas. El pseudocodigo o los diagramas son buenos para ver como funciona una parte del codigo y para desarrollar logica de programacion. Obviamente no lo haras en todo el proyecto con el fin de documentar, solo la parte a entender para modificar o editar si no se ve claro a la primera.
Hay algo que estoy empezando a implementar para ayudarme a organizar y planificar código, de cosas que tal vez son complejas, es el uso de mapas mentales, lo voy mezclando con diagramas de clases/entidades. Para esto utilizo Miro, que es super práctico, y me está gustando mucho, me resulta más claro y ordenado visualmente. También utilizo mucho el bloc de notas para detallar algoritmos que tengo que hacer en el momento y tenerlos de guía a la hora de escribir código. En definitiva, hay que usar lo que a uno le resulte práctico, cómodo y efectivo!
Cuando solo trabajas con programadores tienes razón no sirven mucho. Pero si eres consultor. Entonces deberías entender que los usuarios de negocio no entienden mucho tecnología. Para mí son la clave entre alguien que entiende lo que hace y alguien que solo lo hace.
Todavía es muy joven para saber lo importante del diagrama de flujo, y cuando es necesario utilizarlo. El video está basado en lo empirico personal, saludos.
Desde el cariño, creo que para quedar mejor la grabación del vídeo, al igual que políticos presentadores de TV, etc. debieras utilizar gafas o lentes antireflejantes en las grabaciones de vídeo, es una sugerencia amigable para que te luzca mejor
Los diagramas de flujo o dfd están para aprender la lógica secuencial de la información para poder ser plasmada en una solución a una necesidad de información. Cuando la persona entiende dfd llega a un punto en que lo hace sin necesidad de uno. La experuencia lo lleva a ello. Así que si no viste uno en tu empresa es por la experiencia que lleva el equipo en su conocimiento. Son necesarios para adentrarse en este mundo.
Los diagramas de actividades o los de comportamiento como el de colaboración se pueden trasladar a diagramas de flujo. Los diagramas de flujo son para describir pasos de un algoritmo. Hay instrucciones de como salir de un edificio en formato de diagrama de flujos.
Que estrategias usan para mantener la documentación actualizada, en mi experiencia es de lo más complejo porque se tiende a priorizar la entrega como tal del software y la documentación termina relegada
Ami me toco crear una funcionalidad de alto impacto, donde hacia un sistema reutilizable ( de no hacerlo, el sistema solo serviria por un año y se desecharia). La lógica la separe en 2 partes e involucraba mas de 20 tablas y lo hice con un SP, y la otra parte con Funciones. Sentí la obligacion de usar diagramas en esa funcionalidad solamente, porque si lo escribia en un comentario o pseudocodigo, mis compañeros no lo entenderían. La funcionalidad involucraba recrear la estructura de todo un año del sistema y las leyes ministeriales de mi país. Soy junior, quizas este equivocado pero creo que el uso de diagramas en algunos casos es válido.
Si el equipo esta alineado y saben UML es completamente válido, siempre que sea necesario y aporte al equipo se deben usar, para usar bien los diagramas de flujo tan solo hay que hacer el diagrama macro e ir haciendo diagramas pequeños de los subprocesos. Nada de hacer un solo diagrama y meter todo en eso o nada mas usar pseudo. El diagrama de flujo es un mapa para una solución compleja y la capacidad visual de enlazar los puntos mediante líneas no se puede superar por el pseudocódigo. En general el pseudocódigo se usa la indentación si tienes un proceso medianamente grande no va a ser muy factible escribir pseudocódigo. Pero como dice Programador X es su opinión y se respeta , en mi opinión si son muy útiles sobre todo para comunicar algo complejo.
Según dice que Los diagramas de flujo no son estandarizados, que me dices del pseudo-código? Estoy muy poco de acuerdo con este video; los diagramas de flujo son muy útiles, estoy de acuerdo que en detalles de algoritmos puede usarse pseudo código, pero cuando se describen procesos macro los diagramas describen mejor y a todos los niveles la arquitectura de una solución.
Gracias por tremendo aporte, mi experiencia uso ambas técnicas el diagrama de flujo junto al pseudocodigo. Lo aprendí de un libro que es "programing logic & design by Tony Gaddis" con los buenos ejemplos y ejercicios aprendí a tomar requerimiento para hacer un algoritmos usando pseudocodigo para concentrar me en la lógica y no en el lenguaje, y los diagrama para hacer diagramas de jerarquía y los de flujo, también explican como hacer diagrama para programación orientada a objetos.
Tienes toda la razón con la opinión que tienes de los diagramas... A mi me paso una vez que se me ocurrió la fantástica idea de diagrama un proceso en donde trabajaba siguiendo las instrucciones que me daba un ingeniero industrial, el diagrama se hizo algo complejo, luego en esa semana me fui de vacaciones y cuando regrese ya no entendí casi nada del diagrama tuve que invertir esfuerzos en volverlo a entender a pezar de que yo mismo lo había hecho.
Gracias a ese video de "No tomes Notas, Haz esto" he mejorado mucho la forma en la que documento código, actualmente uso notebooks de Jupyter porque me permite documentar mi aprendizaje mientras codifico pequeños ejemplos en Python. además, me permite incrustar diagramas con archivos svg.
Los diagramas de flujo sirven como una documentación visual clara de los procesos, de cómo debe funcionar el software. Esto facilita la comunicación de adonde queremos llegar con las partes interesadas que no son técnicos, especialmente entre la comunicación del diseñador de software y los involucrados y/o participantes (usuario final). Ciertamente no es practico para el desarrollador en cuando a cada detalle de cada modulo, lo ideal es el seudocientífico, diagramas de casos de uso, diagramas de clases, etc. Cada proceso del diseño tiene un objetivo, esto evita cambios imprevistos y forma las bases para la cronología del diseño.
Los diagramas son el lenguaje de los ingenieros, es cierto que no se utilizan, pero no por eso no quiere decir que no sea correcto, el problema que nadie tiene tiempo para crear diagramas...
Tienes buenos argumentos para defender esa idea. Eso sí... ¿cómo puede alguien que está empezando en el mundo de la programación aprender todo lo que es la lógica de programación sin utilizar diagramas de flujo? ¡Excelente vídeo, Xavier! 👏🏼
Hola ingeniero, me gusta mucho PHP y ya tengo bases ... pero siento que a la hora de desarrollar algo me bloqueo, me confundo, las funciones y clases se me hace confusas... que me recomiendan por favor? Gracias
Ese episodio de TBBT es espectacular, especialmente cuándo Sheldon se cicla en su algoritmo para socializar y Howard lo tuvo que ayudar a salir del ciclo infinito.😂
A mi Llama ya me habla perfecto en español. Yo tengo Llama de forma local en Linux con la APP Ollama. Desde que instale < llama3.1:8b > (Ollama) ya me sigue toda la conversacion en español y comete, como mucho, un error minimo del articulo o del genero de una palabra; muy ocasionalmente. Se los recomiendo. Yo descague la version de 4,7 GB de RAM y me va todo perfecto.
Los diagramas de flujo son una herramienta potente para introducir a la persona en la lógica de programación una vez hecho esto la persona escribe pseudocodigo de forma casi natural y luego ya directamente código, los diagramas UML no tienen nada que ver en la etapa de codificación y menos en el aprendizaje de la misma
Me gustaría un video sobre los pro y contra de los sistemas tipo BPM como jbpm. Son sistemas basados en diagramas BPMN pero que sí ejecutan tareas, sin embargo en donde trabajo estamos renunciando al uso de ese tipo de sistema porque ha traído muchos problemas
Todo bien, pero, si te queres idiotizar, utiliza las IAS disponibles, deja que los emuladores de inteligencia busquen en sus grandes bases de datos software hecho por otros y no resuelvas el problema, de esa manera, tu capacidad para resolver problemas va a ser siempre la de un programador junior. Ahora, si queres evolucionar y ser cada vez más rápido y eficiente y eficaz para resolver problemas, usa tu cabeza.
Estoy de acuerdo cuando se dice que eso no lo usas en el trabajo, yo tampoco los he usado en el trabajo, sin embargo nadie te dice que lo vas a usar siempre, en realidad es una herramienta para aprender, al principio no necesitas saber programar sino generar y desarrollar la lógica que requieres para resolver un problema y el diagrama de flujo te ayuda en eso a aclarar los pasos cuando estás aprendiendo, ya después de 4 o 5 años en la universidad pues ya uno tiene más experiencia en desarrollar la lógica que ya no necesitas plasmarlo en un diagrama. Por otro lado mezclar diagramas de flujo con diagramas UML no se me hace adecuado siendo que esté último se usan para describir procesos más generales como la arquitectura de una aplicación o sistema más que el código del mismo. Saludos!
Gracias por compartir tu video, pero el título dice no PIERDAS el tiempo usando Diagramas, y los ejemplos que usas son diagramas (UML / AWS), es contradictorio.
Hola, buenas noches. Soy programador y tambien soy incapacitado visual. Resulta que como no puedo leer ni editar diagramas, término agotando me más de lo normal y lo recomendado. Hace tiempo que busco Busco una solución a este problema. Te agradeceria algunas sugerencias.
Me pase adelantando tu video porque no vi nada util para llevarme. Respeto tu opinion pero a mi me ha servido y sirven los diagramas de flujo desde el aprendizaje de mi carrera hasta ya profesionalizado; en tantos dominios, programacion, negocios, procesos, proyectos telcos, etc. Pseudocodigos? si estan ok, pero no reemplaza en todo a los df. En resumen, esto tambien es mi opinión, y cada usuario debe elegir lo que le sirva, lo que SI es errado es generalizar que LA FORMA es hacerlo como uno opina y que lo demas estan mal. Saludos
Yo estudio en el tec de monterrey y en ITC nos enseñan varias diagramas como los sigueintes: -Diagramas de actividades -Diagrama de casos de uso -Diagrama de despliegue -Diagrama de secuencia -MER -MR (Pero es curioso qu eno hayamos visto a profundidad el diagrama de flujo jajaja) en tu opinión o en los proyectos que haz trabajado, ¿Si los usan? lo pregunto porque actualemnte tengo un proyecto de investigación y quiero respetar el ciclo de vida del software, pero no se si si vale la pena invertirle demasiado detalle a esto ya que tengo un equipo de aproximadamente 15 personas, no digo que no vaya a documentar nada, pero como este es mi segundo proyecto más profesional con más personas a cargo no se como manejarlo muy bien (igual tengo una noción básica de ser PM, pero siento que no es suficiente)
Ciertamente, en los 30 años que llevo en el negocio de desarrollo de software, nunca vi un software documentado con diagramas de flujo o pseudocódigo. La realidad es que, al momento de resolver problemas, pueden servir para plasmar los pasos a seguir en una rutina determinada, pero, en grandes proyectos eso es inaplicable. Lo importantes es la claridad en el código, un código bien modularizado, es fundamental para su mantenimiento, localización de errores, modifications y seguimiento del mismo, odio cuando me encuentro con software donde meten toda la lógica en procedures inmensas, tocar eso es una locura, seguís su lógica es volverse loco.
Hasta ahora, en el mundo real, la compañía no usa diagramas de flujo. Sin embargo, para mi propia lógica y para identificar posibles fallos o mejoras, me resultan bastante útiles. Es más tedioso, sí, y no siempre vale la pena gastar el tiempo haciendo el diagrama, pero para cuestiones más complicadas, sí. También sirve para ver las cosas de manera abstracta. Por ejemplo, si tienes dos situaciones diferentes pero el diagrama de flujo de ambos casos se parece, ahí se puede vislumbrar la implementación de una solución general para todas esas situaciones que sigan un diagrama similar.
Excelente video estimado. Ya que mencionaste que trabajas en Amazon ¿Qué opinas respecto al Amazon Echo dot? Me enteré que van a cobrar proximamente una suscripción para poder usarlo, ya que implementarán una IA para mejorar los dispositivos. Yo, como usuario de un Echo Dot no sé que pensar, porque no quiero pagar una suscripción más al mes por algo que solo me encendía la luz de la habitación y funcionaba como parlante, siento que habré perdido dinero en su compra entonces.
Lo mejor que uno puede hacer antes de programar una sola línea de código es plasmar la idea en un diagrama, cuando estés seguro de tu diagrama allí si programa, te evitará dolores de cabeza. Te ayuda a asegurarte que tienes el requerimiento de negocio bien entendido.
Hola Xavier, tengo una duda y me gustaría saber tu opinión. Qué piensas sobre estudiar la carrera universitaria totalmente en línea, crees que sea una buena alternativa para aprender? o crees que lo mas conveniente es hacerla presencial?
Estos 3 videos te ayudarán con una respuesta: th-cam.com/video/JxnkqtqkXpQ/w-d-xo.html th-cam.com/video/aTFRt865jKw/w-d-xo.html th-cam.com/video/Sa6MWDPTbuU/w-d-xo.html
@@ProgramadorX Xavier ya ví los 3 videos y le dí like a los 3 jaja. En mi caso yo quiero ingresar a la universidad, eso lo tengo decidido, pero no sé si online sea una buena idea. Te expongo un poco mi caso ya que vas a entender porque también soy de Ecuador. La Universidad Politecnica Salesiana sacó una nueva carrera online en Ingeniería de software avalada por la senescyt y todo, el costo está muy conveniente (no me causaría problema pagarlo) e iniciaría en el mes de octubre, pero la otra opcion sería ir a la ESPOL que es una universidad presencial publica donde si paso por los examenes de admision iniciaria en el mes de marzo del 2025 recien. Ambas universidades tienen muy buen prestigio aqui en Ecuador (me imagino ya las conoces) y el titulo tiene la misma validez, sin embargo mis familiares me dicen que estudiar la universidad online no es bueno. Por esta razon te pregunto a ti, que ya estas dentro de la industria, si crees que sea algo contraproducente. Agradecería tu respuesta Xavier!
Yo trabajé en una empresa que usábamos diagramas de flujo, ahora en otra ya solo cierta forma de pseudocodigo, para integrar con otros, cuando es necesario, distintas partes de un proyecto grande. Veré las que mencionaste aquí. Saludos.
El Pseucodigo NO siempre es lo mejor. Hay que entender que en las compañias se presentan proyectos a diferentes departamentos por ejemplo UX no le vas a explicar algo en pseudocodigo, perderas tu tiempo. UML siempre sera la mejor manera de explicar un proceso en todos los niveles, y el diagrama de flujo es un tipo de UML. Aun cuando trabajas para terceros y el cliente desconoce terminos de programacion la mejor forma siempre sera un diagrama de flujo.
Bueno yo creo que si enfocas el diagrama de flujo a bajo nivel sería muy largo y tedioso. Un diagrama de flujo para mi es aplicable para la navegación de feature con sus actores y como fluyen los datos, del resto no es recomendable.
¿Realmente el pseudocódigo es una mejor alternativa? En mi experiencia, es más fácil empezar con diagramas de flujo para visualizar ideas antes de pasar al pseudocódigo.
Estoy de acuerdo contigo. Llevo 11 años en el área de seguridad informática , y nunca he visto y he usado un diagrama de flojo en el campo laboral, solo en la universidad y en el colegio de mis hijos 😅
en las empresas lo más parecido a un diagrama de flujo es un garabato en una pizarra con lluvia de ideas que explica más o menos cómo hacer el sistema o el módulo a desarrollar y a partir de eso programamos😁
En la universidad nos enseñaban diagramas de flujo , componentes y pseudo codigo era un rollo estar haciendo uno de cada uno nadie disfrutaba hacer todo eso era hacer las cosas 3 veces.
Hubiera sido interesante ver ejemplos no comprometidos con su trabajo para que los que no sabemos tanto de las alternativas a los diagramas de flujo podamos aprender incluso como se arman.
Siempre doy el ejemplo de LatinCoder el último video de su canal estaba trabajando en Microsoft y no tenia tiempo para subir contenido a su canal , a veces me pregunto si los que dicen trabajar en una empresa Grande tienen tiempo para otras cosas.
Claro. Yo tuve una conversión con él hace ya tiempo (enlace) y también trabajé en Amazon. La realidad es que no es solo el tiempo, el problema es que TH-cam no paga suficiente para que valga la pena el esfuerzo y tiempo. Mi canal gana menos de 15K USD/año y cada video requiere de al menos 16 horas de trabajo. Sin el apoyo de mis estudiantes en mi academia, trabajar solo en TH-cam no sería sostenible para mi. Amazon me pagaba 185K USD y de hecho requería menos trabajo que mi emprendimiento. Ahí te das cuenta de la diferencia. th-cam.com/video/PwLrYcocR6Y/w-d-xo.html
El gran problema con los diagramas de flujo es que quienes dicen usarlos o los usan no los saben utilizar bien, ahora que la metodología BPMN es más efectiva pero también existe mucha gente que no lo implementa bien. La función del diagrama de flujo es conocer cuáles son los procesos de un sistema (el que sea, no tiene que ser principalmente digital), de ahí, el Analista “aterriza” las faces del proceso que quiere transmitir al equipo de desarrollado, para que este entienda el “qué”, “porqué” y “para qué”, ya que cuando se inicia en un proyecto o se desea hacer una mejora, muchas veces la gente que lleva acabo sus funciones cae en una práctica de “hacer obvia la explicación” y es trabajo del Analista que esa explicación cuente con un manual donde quienes no se dedican a eso logren entender cuál es la funcionalidad que se necesita o cuál es la mejora que se desea implementar. Definitivamente es tedioso pero es porque en su mayoría la gente no conoce bien cómo implementarlos. Ahora que no dejan de ser herramientas que serán útil hasta donde sepa el equipo usarlo
Sirven para aprender. De hecho los peores programadores con los que he tenido relación son los que van a Bootcamps y cursos rápidos que no tienen la más mínima idea de lógica de programación. Muchos "programadores" ni siquiera saben pseudocódigo. Por lo menos UML debieran aprender.
Es un sí y un no a la vez. Si no puedes imaginarlo, nunca podrás materializar una idea. Justamente para eso son los diagramas para representar ideas estructuradas.
📙 ¡Empieza GRATIS con mi ebook de HTML! 👉 bit.ly/htmlgratis
Discrepo Programador X, llevo 40 años programando y en la actualidad la parte mas importante para un buen proyecto es documentar los procesos de forma clara y los diagramas de flujo son una herramienta que ayuda a visualizar el problema.
Estas herramientas son para comunicar ideas no solo lógica y el problema es que a muchos no les gusta documentar o lo hacen de forma poco clara.
Si les gusta trabajar de forma desordenada y sin involucrar al cliente pues háganlo sin diagramas... Pero por mi propia experiencia con más de 10 años desarrollando software les puedo decir con toda certeza que "más que un diagrama que respalda la funcionalidad y lógica de un sistema, es un respaldo para el desarrollador qué el cliente debe comprender y firmar de aceptación, puesto que en la mayoría de casos el proyecto evolucionara a tal punto de que el cliente pensara que algo no funciona como se debe, pese a que así quedo establecido en el diagrama" entonces es un respaldo para que si el cliente desea hacer un cambio o simplemente no aceptar la funcionalidad que pidió y quedo plasmada, se deberá cobrar más por el esfuerzo extra al desarrollo... SEAN ORDENADOS, LOS PROCESOS ESTÁN PARA SEGUIRSE Y DOCUMENTAR SU EVOLUCIÓN QUE LES SERVIRÁ DE RESPALDO ANTE CUALQUIER CONTRARIEDAD...
los diagramas de flujo sirven para aprender. Pero los diagramas UML si se utilizan bastantes, pero creo que es super importante saber plasmar tu idea o tu arquitectura en un diagrama. Lo digo porque he leído comentarios de gente que dice que solo hay que saber echar codigo
Para comunicar ideas el más importante sería diagrama er y de clases, pero a parte de esos muy raro usar otros, el resto de diagramas uml son verbosos o aportan poco (secuencia, casos de uso, componentes). Pero vamos, que la burocracia por desgracia está en todo lado.
Los de secuencia se usan a veces en documentación de api es muy raro ver uml en otros documentos
son lo mejor, también los bpmn, pero la gente son pura plata y no quieren tener un repositorio de análisis actualizado aunque las herramientas existan
En mi opinion, los diagramas de flujo son un lenguaje de alto nivel que permite plasmar de manera clara y sencilla un proceso, donde no solo lo entienda un desarrollador, sino cualquier persona con pensamiento analitico.
Para la empresa que trabajo lo utilizo mucho para presentar los procesos a la gerencia de como el software trabaja o esta diseñado de manera interna y sin conceptos tecnicos; de esta menera los demas departamentos logran comprender los procesos, no tanto como el software lo maneja sino como la empresa opera sobre los mismo, logrando asi y comunicacion mas efectiva cuando los demas departamentos nos envian los requerimientos.
La falta de esta práctica es lo que ha provocado que la famosa metodología agil no sea tan efectiva (agil) porque al no tener los procesos definidos como se comunican unos con otro, hace que siempre se redunde en lo mismo.
PD: Esto es un trabajo del analista o jefe de proyecto definir estos diagramas, no del desarrollador como tal como lo hacen una gran parte de las empresas.
Yo aprendi a programar a los 11 años y precisamente fueron los diagramas de flujo los que ayudan a aprender. Y en mis casi 30 años de experiencia como desarrollador, tengo que decirte lo siguiente.
Los diagramas de flujo son herramientas increíblemente útiles para visualizar y entender procesos complejos, similar a cómo un mapa guía a los viajeros. Aunque no tienen un estándar único, muchos lenguajes de modelado como UML y BPMN incorporan sus conceptos. Esto significa que usar estos estándares es, en esencia, utilizar diagramas de flujo. Saber crear y leer diagramas de flujo puede ahorrarte tiempo y esfuerzo, mejorando la planificación, comunicación y ejecución de proyectos, sobre todo con el personal no tecnico.
Tienes que entender que los diagramas de flujo tienen un proposito. Puedes describir flujos de programa, pero tambien de negocio. Y tambien puedes ir de lo general a lo particular. Y como todo, debe usarse en su justa medida, pero jamas va a ser una herramienta a desechar por mucha opinion que exista en el mundo al respecto.
Concuerdo, soy arquitecto de sw y esos diagramas son vitales para dar a entender el diseño de la arquitectura a mis compañeros, si bien no son como tal diagramas y a estas alturas son más garabatos pero funciona muy bien y no veo otra forma de explicar una arquitectura a un equipo multidisciplinario, posiblemente un desarrollador pueda evitarlos pero como arquitecto es vital.
Pero tampoco creo diagramas de procesos específicos esos si no valen la pena, son muy mutables
Si son una herramienta útil para visualizar un problema o comunicar una idea y dependiendo del nivel de detalle se puede usar c4 model. Igual cualquier herramienta es buena con su uso correcto, el título debería ser algo como, no uses diagramas en estos casos o no usar diagramas para documentar detalles etc
El diagrama de flujo es el esquema de un algoritmo. No es código, es un programa universal en forma gráfica que sirve para cualquier lenguaje de programación. Los programadores que se van directo al código (la inmensa mayoría) tienen atrofiada la capacidad para hacer diagramas de flujo. Lo ideal es saber hacer diagramas de flujo antes de hacer el código, con esto es más fácil depurar el programa y corregir errores. Después hacer el código ya sería mero trámite.
En absoluto, llevo 30 años trabajando en desarrollo de software, he pasado por infinidad de proyectos y empresas, desde las más grandes hasta pequeñas y, nadie trabaja o documenta con diagramas de flujo.
Simplemente es inaplicable al momento de trabajar en grandes proyectos con cientos y cientos de rutinas, en esos casos, lo más valioso es una buena documentación funcional, para entender el negocio y una alta calidad de código, bien estandarizado y bien modularizado.
No es que no sirvan, es que no sabes como usarlos.
Alguna vez me paso tambien que dije: Tengo 10 años como project manager y mi experiencia me dice que no puedes administrar un proyecto de software con graficas de Gantt.
Hasta que me enviaron a un curso donde me enseñaron como si se puede.
Creo que es más importante investigar porque nacieron en primer lugar el uso de diagramas, que problemas habia y como solucionaban la problemática.
Tal vez después de analizar te vas a dar cuenta que si es mejor usarlos y en vez de decir que no se usan en la vida real, puedes descubrir que son una gran herramienta y difundas la buena practica.
Y solo por si te preguntas, tengo 25 años programando y no lo he dejado a pesar de dirigir los proyectos.
Yo uso flowgorithm para enseñarle a mis alumnos a programar y me da buenos resultados hasta que aprenden la lógica. Además convierte automáticamente los diagramas a distintos lenguajes como python o javascript
O puedes usar el PSeint que tambien crea codigo personalizado y diagramas flujo pero en general
@@virusmuerte PSeInt está chido!
Los diagramas son muy necesarios para comprender los procesos
Yo soy arquitecto de sw y los uso mucho pero no son como tal diagramas de flujos son más como garabatos pero me sirven mucho para diseñar la arquitectura y abstraer procesos para modularizarlos pero uso mucho las cajas grises, esas cajas grises son procesos abstraidos y me sirve mucho para que el resto del equipo entiendan que se hace y en que ayuda lo que hacen o por que es importante lo que se hace
Es verdad que en la practica profesional no se usan pero en el proceso de aprendizaje son muy utiles
Más alla de si usas o no diagramas de flujo que puede ser una herramienta visual poderosa para hacer comprender las necesidades de negocio, es saber abstraer las necesidades desde alto nivel y bajarlas a nivel técnico y eso significa que debes entender los contextos acotados, entender el dominio que se expresa dividirlo en historias de usuario y determinar los casos de uso de cada uno con sus reglas de negocio. Eso es lo esencial, ya que estas reglas busquen expresarse con diagramas de flujo o lo que sea es distinto
Trabajo en proyectos pequeños, programo microcontroladores en lenguaje ensamblador. Los diagramas de flujo a veces ayudan, pero es verdad, el pseudocódigo es más rápido e igual de efectivo.
el que no sea comun no es que no sirva, además sirven para desarrollar la logica de programacion. Si bien cuando ya estas con el tiempo enciama ya debes llegar y programar, para hacer eso antes es necesario tener un nivel de abstraccion muy bueno, buena logica de programacion y conocer el lenguaje que utilizas. El pseudocodigo o los diagramas son buenos para ver como funciona una parte del codigo y para desarrollar logica de programacion. Obviamente no lo haras en todo el proyecto con el fin de documentar, solo la parte a entender para modificar o editar si no se ve claro a la primera.
Hay algo que estoy empezando a implementar para ayudarme a organizar y planificar código, de cosas que tal vez son complejas, es el uso de mapas mentales, lo voy mezclando con diagramas de clases/entidades. Para esto utilizo Miro, que es super práctico, y me está gustando mucho, me resulta más claro y ordenado visualmente. También utilizo mucho el bloc de notas para detallar algoritmos que tengo que hacer en el momento y tenerlos de guía a la hora de escribir código. En definitiva, hay que usar lo que a uno le resulte práctico, cómodo y efectivo!
Cuando solo trabajas con programadores tienes razón no sirven mucho. Pero si eres consultor. Entonces deberías entender que los usuarios de negocio no entienden mucho tecnología. Para mí son la clave entre alguien que entiende lo que hace y alguien que solo lo hace.
Para eso sí. Los diagramas de flujo para mostrarle los procesos a los usuarios, o también diagramas de securncias
Todavía es muy joven para saber lo importante del diagrama de flujo, y cuando es necesario utilizarlo. El video está basado en lo empirico personal, saludos.
Gracias por tu amable respuesta. No te dejes engañar por mi espíritu joven. 😁 Te invito a revisar mi experiencia con detenimiento. ¡Saludos!
Tienes un avalon como Pre del Micrófono... Que excelencia. Te felicito por cada detalle y profesionalismo
Desde el cariño, creo que para quedar mejor la grabación del vídeo, al igual que políticos
presentadores de TV, etc. debieras utilizar gafas o lentes antireflejantes en las grabaciones de vídeo, es una sugerencia amigable para que te luzca mejor
Los diagramas de flujo o dfd están para aprender la lógica secuencial de la información para poder ser plasmada en una solución a una necesidad de información. Cuando la persona entiende dfd llega a un punto en que lo hace sin necesidad de uno. La experuencia lo lleva a ello. Así que si no viste uno en tu empresa es por la experiencia que lleva el equipo en su conocimiento. Son necesarios para adentrarse en este mundo.
Ojalá y la enseñanza fuera de esta manera, simple, ágil y sencilla, fácil de entender y sin tanto enredos, Felicitaciones 🎉
Los diagramas de actividades o los de comportamiento como el de colaboración se pueden trasladar a diagramas de flujo. Los diagramas de flujo son para describir pasos de un algoritmo. Hay instrucciones de como salir de un edificio en formato de diagrama de flujos.
Los diagramas son totalmente utiles, asi como el pseudo y las secuenciales.
Que estrategias usan para mantener la documentación actualizada, en mi experiencia es de lo más complejo porque se tiende a priorizar la entrega como tal del software y la documentación termina relegada
Ami me toco crear una funcionalidad de alto impacto, donde hacia un sistema reutilizable ( de no hacerlo, el sistema solo serviria por un año y se desecharia).
La lógica la separe en 2 partes e involucraba mas de 20 tablas y lo hice con un SP, y la otra parte con Funciones.
Sentí la obligacion de usar diagramas en esa funcionalidad solamente, porque si lo escribia en un comentario o pseudocodigo, mis compañeros no lo entenderían.
La funcionalidad involucraba recrear la estructura de todo un año del sistema y las leyes ministeriales de mi país.
Soy junior, quizas este equivocado pero creo que el uso de diagramas en algunos casos es válido.
Si el equipo esta alineado y saben UML es completamente válido, siempre que sea necesario y aporte al equipo se deben usar, para usar bien los diagramas de flujo tan solo hay que hacer el diagrama macro e ir haciendo diagramas pequeños de los subprocesos. Nada de hacer un solo diagrama y meter todo en eso o nada mas usar pseudo. El diagrama de flujo es un mapa para una solución compleja y la capacidad visual de enlazar los puntos mediante líneas no se puede superar por el pseudocódigo. En general el pseudocódigo se usa la indentación si tienes un proceso medianamente grande no va a ser muy factible escribir pseudocódigo. Pero como dice Programador X es su opinión y se respeta , en mi opinión si son muy útiles sobre todo para comunicar algo complejo.
Estimado, los diagramas de flujo son una herramienta de aprendizaje para introducir a los estudiantes a la lógica de programación y los algoritmos.
Los diagramas de flujo son una herramienta de aprendizaje, no los puedes desechar simplemente porque no los usas en tu trabajo.
Según dice que Los diagramas de flujo no son estandarizados, que me dices del pseudo-código? Estoy muy poco de acuerdo con este video; los diagramas de flujo son muy útiles, estoy de acuerdo que en detalles de algoritmos puede usarse pseudo código, pero cuando se describen procesos macro los diagramas describen mejor y a todos los niveles la arquitectura de una solución.
Gracias por tremendo aporte, mi experiencia uso ambas técnicas el diagrama de flujo junto al pseudocodigo. Lo aprendí de un libro que es "programing logic & design by Tony Gaddis" con los buenos ejemplos y ejercicios aprendí a tomar requerimiento para hacer un algoritmos usando pseudocodigo para concentrar me en la lógica y no en el lenguaje, y los diagrama para hacer diagramas de jerarquía y los de flujo, también explican como hacer diagrama para programación orientada a objetos.
Tienes toda la razón con la opinión que tienes de los diagramas... A mi me paso una vez que se me ocurrió la fantástica idea de diagrama un proceso en donde trabajaba siguiendo las instrucciones que me daba un ingeniero industrial, el diagrama se hizo algo complejo, luego en esa semana me fui de vacaciones y cuando regrese ya no entendí casi nada del diagrama tuve que invertir esfuerzos en volverlo a entender a pezar de que yo mismo lo había hecho.
Gracias a ese video de "No tomes Notas, Haz esto" he mejorado mucho la forma en la que documento código, actualmente uso notebooks de Jupyter porque me permite documentar mi aprendizaje mientras codifico pequeños ejemplos en Python. además, me permite incrustar diagramas con archivos svg.
conclusion entonces es que no recomendas diagramas de flujo, pero sí diagramas UML?
Los diagramas de flujo sirven como una documentación visual clara de los procesos, de cómo debe funcionar el software. Esto facilita la comunicación de adonde queremos llegar con las partes interesadas que no son técnicos, especialmente entre la comunicación del diseñador de software y los involucrados y/o participantes (usuario final).
Ciertamente no es practico para el desarrollador en cuando a cada detalle de cada modulo, lo ideal es el seudocientífico, diagramas de casos de uso, diagramas de clases, etc. Cada proceso del diseño tiene un objetivo, esto evita cambios imprevistos y forma las bases para la cronología del diseño.
100% de acuerdo... solo útiles a nivel de arquitectura ;) gracias genio
Los diagramas son el lenguaje de los ingenieros, es cierto que no se utilizan, pero no por eso no quiere decir que no sea correcto, el problema que nadie tiene tiempo para crear diagramas...
Y el mantenimiento (a largo plazo)? Creo que no conoce el diagrama de actividades para facilitar la integración entre diferentes métodos!
Tienes buenos argumentos para defender esa idea. Eso sí... ¿cómo puede alguien que está empezando en el mundo de la programación aprender todo lo que es la lógica de programación sin utilizar diagramas de flujo?
¡Excelente vídeo, Xavier! 👏🏼
Si tienes experiencia con C4, vale la pena un video, siempre lo explicas muy bien.
Hola ingeniero, me gusta mucho PHP y ya tengo bases ... pero siento que a la hora de desarrollar algo me bloqueo, me confundo, las funciones y clases se me hace confusas... que me recomiendan por favor? Gracias
Ese episodio de TBBT es espectacular, especialmente cuándo Sheldon se cicla en su algoritmo para socializar y Howard lo tuvo que ayudar a salir del ciclo infinito.😂
Pregunta si ya por ejemplo se java ccs y HTML en tu cursó me los puedo saltar y ver los otros que tienes verdad
entonces para mejorar la logica en programacion seria analizar -> resolver y al final programar en pseudocodigo?
A mi Llama ya me habla perfecto en español. Yo tengo Llama de forma local en Linux con la APP Ollama. Desde que instale < llama3.1:8b > (Ollama) ya me sigue toda la conversacion en español y comete, como mucho, un error minimo del articulo o del genero de una palabra; muy ocasionalmente. Se los recomiendo. Yo descague la version de 4,7 GB de RAM y me va todo perfecto.
Los diagramas de flujo son una herramienta potente para introducir a la persona en la lógica de programación una vez hecho esto la persona escribe pseudocodigo de forma casi natural y luego ya directamente código, los diagramas UML no tienen nada que ver en la etapa de codificación y menos en el aprendizaje de la misma
No pierdas tiempo en diagramas, mejor pierde tiempo en diagramas... Cualquier diagrama que ayude a entender rápidamente algo es útil.
excelente como siempre... claro y al grano, gracias!!!!!
Me gustaría un video sobre los pro y contra de los sistemas tipo BPM como jbpm. Son sistemas basados en diagramas BPMN pero que sí ejecutan tareas, sin embargo en donde trabajo estamos renunciando al uso de ese tipo de sistema porque ha traído muchos problemas
Mi clave de exito se basa en diagramas de secuencia + diagramas de transición de estados
Todo bien, pero, si te queres idiotizar, utiliza las IAS disponibles, deja que los emuladores de inteligencia busquen en sus grandes bases de datos software hecho por otros y no resuelvas el problema, de esa manera, tu capacidad para resolver problemas va a ser siempre la de un programador junior. Ahora, si queres evolucionar y ser cada vez más rápido y eficiente y eficaz para resolver problemas, usa tu cabeza.
Los diagramas C4 ¿Qué tal te parece?
Estoy de acuerdo cuando se dice que eso no lo usas en el trabajo, yo tampoco los he usado en el trabajo, sin embargo nadie te dice que lo vas a usar siempre, en realidad es una herramienta para aprender, al principio no necesitas saber programar sino generar y desarrollar la lógica que requieres para resolver un problema y el diagrama de flujo te ayuda en eso a aclarar los pasos cuando estás aprendiendo, ya después de 4 o 5 años en la universidad pues ya uno tiene más experiencia en desarrollar la lógica que ya no necesitas plasmarlo en un diagrama.
Por otro lado mezclar diagramas de flujo con diagramas UML no se me hace adecuado siendo que esté último se usan para describir procesos más generales como la arquitectura de una aplicación o sistema más que el código del mismo.
Saludos!
Hola, puedes crear un vídeo explicando cómo funciona por dentro la nueva IA de Meta ♥️🙏🏼
Conoces BPMN? Haz revisado o hecho mantenimiento a software existente? Haz escuchado cuando dicen "ese software es mejor volverlo a hacer"?
Es lo que se vea bonito en la presentación
Gracias por compartir tu video, pero el título dice no PIERDAS el tiempo usando Diagramas, y los ejemplos que usas son diagramas (UML / AWS), es contradictorio.
Hola, buenas noches. Soy programador y tambien soy incapacitado visual. Resulta que como no puedo leer ni editar diagramas, término agotando me más de lo normal y lo recomendado. Hace tiempo que busco Busco una solución a este problema. Te agradeceria algunas sugerencias.
Hola, Yo soy incapacitado visual también y me interesa la programación. Me podrías sugerir alguna herramienta con la que empezar a aprender?
A buena hora.me.enseñaron Pseudocódigo en la universidad, estoy primer año
Recomiendas usar plantUml para realizar diagramas en UML?
ArgoUML es mejor a mi parecer
También starUML
@@dealma2510 Tambien, muy buena
Excelente explicación
Me pase adelantando tu video porque no vi nada util para llevarme. Respeto tu opinion pero a mi me ha servido y sirven los diagramas de flujo desde el aprendizaje de mi carrera hasta ya profesionalizado; en tantos dominios, programacion, negocios, procesos, proyectos telcos, etc. Pseudocodigos? si estan ok, pero no reemplaza en todo a los df. En resumen, esto tambien es mi opinión, y cada usuario debe elegir lo que le sirva, lo que SI es errado es generalizar que LA FORMA es hacerlo como uno opina y que lo demas estan mal. Saludos
Pseint me recordo a mi primer ciclo de la universidad resolver ejercicios en papel xdddddddddddddddddddddddddddddddddddddddddddddddddddd
Muy buenos consejos, gracias
Yo estudio en el tec de monterrey y en ITC nos enseñan varias diagramas como los sigueintes:
-Diagramas de actividades
-Diagrama de casos de uso
-Diagrama de despliegue
-Diagrama de secuencia
-MER
-MR
(Pero es curioso qu eno hayamos visto a profundidad el diagrama de flujo jajaja) en tu opinión o en los proyectos que haz trabajado, ¿Si los usan? lo pregunto porque actualemnte tengo un proyecto de investigación y quiero respetar el ciclo de vida del software, pero no se si si vale la pena invertirle demasiado detalle a esto ya que tengo un equipo de aproximadamente 15 personas, no digo que no vaya a documentar nada, pero como este es mi segundo proyecto más profesional con más personas a cargo no se como manejarlo muy bien (igual tengo una noción básica de ser PM, pero siento que no es suficiente)
Ciertamente, en los 30 años que llevo en el negocio de desarrollo de software, nunca vi un software documentado con diagramas de flujo o pseudocódigo.
La realidad es que, al momento de resolver problemas, pueden servir para plasmar los pasos a seguir en una rutina determinada, pero, en grandes proyectos eso es inaplicable.
Lo importantes es la claridad en el código, un código bien modularizado, es fundamental para su mantenimiento, localización de errores, modifications y seguimiento del mismo, odio cuando me encuentro con software donde meten toda la lógica en procedures inmensas, tocar eso es una locura, seguís su lógica es volverse loco.
No es que no sirvan, es que no sabes cómo usarlos
Hasta ahora, en el mundo real, la compañía no usa diagramas de flujo.
Sin embargo, para mi propia lógica y para identificar posibles fallos o mejoras, me resultan bastante útiles.
Es más tedioso, sí, y no siempre vale la pena gastar el tiempo haciendo el diagrama, pero para cuestiones más complicadas, sí.
También sirve para ver las cosas de manera abstracta. Por ejemplo, si tienes dos situaciones diferentes pero el diagrama de flujo de ambos casos se parece, ahí se puede vislumbrar la implementación de una solución general para todas esas situaciones que sigan un diagrama similar.
Cuando se viene un descuento en tus Academia X?:)
Excelente video estimado. Ya que mencionaste que trabajas en Amazon ¿Qué opinas respecto al Amazon Echo dot? Me enteré que van a cobrar proximamente una suscripción para poder usarlo, ya que implementarán una IA para mejorar los dispositivos. Yo, como usuario de un Echo Dot no sé que pensar, porque no quiero pagar una suscripción más al mes por algo que solo me encendía la luz de la habitación y funcionaba como parlante, siento que habré perdido dinero en su compra entonces.
Lo mejor que uno puede hacer antes de programar una sola línea de código es plasmar la idea en un diagrama, cuando estés seguro de tu diagrama allí si programa, te evitará dolores de cabeza. Te ayuda a asegurarte que tienes el requerimiento de negocio bien entendido.
Hola Xavier, tengo una duda y me gustaría saber tu opinión. Qué piensas sobre estudiar la carrera universitaria totalmente en línea, crees que sea una buena alternativa para aprender? o crees que lo mas conveniente es hacerla presencial?
Estos 3 videos te ayudarán con una respuesta:
th-cam.com/video/JxnkqtqkXpQ/w-d-xo.html
th-cam.com/video/aTFRt865jKw/w-d-xo.html
th-cam.com/video/Sa6MWDPTbuU/w-d-xo.html
@@ProgramadorX Xavier ya ví los 3 videos y le dí like a los 3 jaja. En mi caso yo quiero ingresar a la universidad, eso lo tengo decidido, pero no sé si online sea una buena idea. Te expongo un poco mi caso ya que vas a entender porque también soy de Ecuador. La Universidad Politecnica Salesiana sacó una nueva carrera online en Ingeniería de software avalada por la senescyt y todo, el costo está muy conveniente (no me causaría problema pagarlo) e iniciaría en el mes de octubre, pero la otra opcion sería ir a la ESPOL que es una universidad presencial publica donde si paso por los examenes de admision iniciaria en el mes de marzo del 2025 recien. Ambas universidades tienen muy buen prestigio aqui en Ecuador (me imagino ya las conoces) y el titulo tiene la misma validez, sin embargo mis familiares me dicen que estudiar la universidad online no es bueno. Por esta razon te pregunto a ti, que ya estas dentro de la industria, si crees que sea algo contraproducente. Agradecería tu respuesta Xavier!
Pues es bueno aprender de todo un poco
Yo trabajé en una empresa que usábamos diagramas de flujo, ahora en otra ya solo cierta forma de pseudocodigo, para integrar con otros, cuando es necesario, distintas partes de un proyecto grande. Veré las que mencionaste aquí. Saludos.
Hmmm cuando uno no estudia una carrera
El Pseucodigo NO siempre es lo mejor. Hay que entender que en las compañias se presentan proyectos a diferentes departamentos por ejemplo UX no le vas a explicar algo en pseudocodigo, perderas tu tiempo. UML siempre sera la mejor manera de explicar un proceso en todos los niveles, y el diagrama de flujo es un tipo de UML. Aun cuando trabajas para terceros y el cliente desconoce terminos de programacion la mejor forma siempre sera un diagrama de flujo.
Bueno yo creo que si enfocas el diagrama de flujo a bajo nivel sería muy largo y tedioso. Un diagrama de flujo para mi es aplicable para la navegación de feature con sus actores y como fluyen los datos, del resto no es recomendable.
¿Realmente el pseudocódigo es una mejor alternativa? En mi experiencia, es más fácil empezar con diagramas de flujo para visualizar ideas antes de pasar al pseudocódigo.
Estoy de acuerdo contigo. Llevo 11 años en el área de seguridad informática , y nunca he visto y he usado un diagrama de flojo en el campo laboral, solo en la universidad y en el colegio de mis hijos 😅
en las empresas lo más parecido a un diagrama de flujo es un garabato en una pizarra con lluvia de ideas que explica más o menos cómo hacer el sistema o el módulo a desarrollar y a partir de eso programamos😁
En la universidad nos enseñaban diagramas de flujo , componentes y pseudo codigo era un rollo estar haciendo uno de cada uno nadie disfrutaba hacer todo eso era hacer las cosas 3 veces.
Eso de usar el pseudocódigo en lugar de diagrama de flujo me lo enseñaron en la década de los 90😅😅😅😅
Totalmente de acuerdo seudocodigo si pero no diagramas para un algoritmo
Igual 10 años en la Industrial la última vez que utilice diagramas de flujo fue en preparatoria
Conclusión, Python es seudo código
Hubiera sido interesante ver ejemplos no comprometidos con su trabajo para que los que no sabemos tanto de las alternativas a los diagramas de flujo podamos aprender incluso como se arman.
Vengo de ver un vídeo de no usar pseudo código en inglés, lo que recomienda es hacer diagramas a vistas generales, aunq el vídeo era más para Seniors
Hay que ver de todo...que los diagramas de flujo no sirven....que si es muy costoso hacerlos....en fin
obviamente no se utiliza en el trabajo, pero es la base para aprender la programación secuencial en lo personal
No los usas hasta que viene un stakeholder y te dice haber explícame la funcionalidad…. 😂
Dos palabras y un anuncio, otras dos palabras otro anuncio. No es queja, solo algo notable.
Hablaras por favor sobre el área del desarrollo de videojuegos?
Yo si vi diagramas de flujo. Se usaban para documentar componentes de una super app.
Siempre doy el ejemplo de LatinCoder el último video de su canal estaba trabajando en Microsoft y no tenia tiempo para subir contenido a su canal , a veces me pregunto si los que dicen trabajar en una empresa Grande tienen tiempo para otras cosas.
Claro. Yo tuve una conversión con él hace ya tiempo (enlace) y también trabajé en Amazon.
La realidad es que no es solo el tiempo, el problema es que TH-cam no paga suficiente para que valga la pena el esfuerzo y tiempo. Mi canal gana menos de 15K USD/año y cada video requiere de al menos 16 horas de trabajo. Sin el apoyo de mis estudiantes en mi academia, trabajar solo en TH-cam no sería sostenible para mi.
Amazon me pagaba 185K USD y de hecho requería menos trabajo que mi emprendimiento. Ahí te das cuenta de la diferencia.
th-cam.com/video/PwLrYcocR6Y/w-d-xo.html
El gran problema con los diagramas de flujo es que quienes dicen usarlos o los usan no los saben utilizar bien, ahora que la metodología BPMN es más efectiva pero también existe mucha gente que no lo implementa bien. La función del diagrama de flujo es conocer cuáles son los procesos de un sistema (el que sea, no tiene que ser principalmente digital), de ahí, el Analista “aterriza” las faces del proceso que quiere transmitir al equipo de desarrollado, para que este entienda el “qué”, “porqué” y “para qué”, ya que cuando se inicia en un proyecto o se desea hacer una mejora, muchas veces la gente que lleva acabo sus funciones cae en una práctica de “hacer obvia la explicación” y es trabajo del Analista que esa explicación cuente con un manual donde quienes no se dedican a eso logren entender cuál es la funcionalidad que se necesita o cuál es la mejora que se desea implementar. Definitivamente es tedioso pero es porque en su mayoría la gente no conoce bien cómo implementarlos. Ahora que no dejan de ser herramientas que serán útil hasta donde sepa el equipo usarlo
Sirven para aprender. De hecho los peores programadores con los que he tenido relación son los que van a Bootcamps y cursos rápidos que no tienen la más mínima idea de lógica de programación. Muchos "programadores" ni siquiera saben pseudocódigo. Por lo menos UML debieran aprender.
Excelente video
En mis pocos años de profesión si los he usado, pero en el campo de RPA (Robotic process Automation).
Para mapear procesos actuales de un proyecto.
Abogar por código bien escrito: totalmente de acuerdo
Debido a lo anterior, abogar por escribir código directamente: totalmente en desacuerdo
Pensé que hablarías de diagrama como código , así los diagramas pueden ser colaborativo al poder estar versionado
Es un sí y un no a la vez. Si no puedes imaginarlo, nunca podrás materializar una idea. Justamente para eso son los diagramas para representar ideas estructuradas.