23 Comentarios

  1. estrellado_damm /  hace 2 años

    Ya era hora que acabarán con esa farsa.

  2. pezezin /  hace 2 años

    No me sorprende en absoluto. En mi experiencia profesional, creo que sólo he usado diagramas de casos de uso, diagramas de clase (a mano o autogenerados con Doxygen o similar) y máquinas de estados finitos. Y la mayoría de amigos y conocidos programadores igual. Hay muchos tipos de diagramas UML que no sé ni para qué sirven, y nunca nadie me lo ha sabido explicar de manera clara.

  3. velit6 /  hace 2 años

    Pues debo ser de los pocos que usan UML, eso sí nunca usé el del Visual Studio. Suelo hacerlo casi siempre en papel, pizarra y cuando se tiene que enviar, en Visio; jamás he visto que se mantengan los UMLs salvo contadas y pequeñas excepciones, por ejemplo la documentación de partes núcleo, el UML cumple un propósito de herramienta de comunicación y diseño. Sería una burrada mantener los UMLs de toda la aplicación. Admito que conozco a tremendos programadores que no saben en qué se diferencia un diagrama estático de uno dinámico; el saber / usar UML no te hace mejor programador, sí mejor comunicador.

  4. tomasbcn25 /  hace 2 años

    pues normal... normalmente no hay ni un word funcional, como para tener un analisis uml hecho xD

  5. enpunta /  hace 2 años

    Más o menos lo que imaginaba, multitud de gente que, por no conocer o quedarse en lo superficial de UML, lo ponen a parir, criticando el excesivo formalismo y lo innecesario del diseño.
    Y luego nos quejamos de que nuestra profesión no se tome en serio.

  6. sosiata /  hace 2 años

    Menudos frikis no me extraña que seais virgenes

  7. apetor /  hace 2 años

    Hoy es un gran día.

  8. alfredo_casado /  hace 2 años

    Hombre está bien que lo eliminen si eso sirve para que el Visual Studio arranque un poquito más rápido...

    UML puede tener su valor en determinadas situaciones, para explicar algunas cuestiones de diseño y tener una visión compartida en el equipo, pero esto se puede hacer en una pizarra, en una hoja de papel o en cualquier herramienta sencilla. No veo la necesidad de tenerlo integrado en un IDE, así que por mi estupendo, los IDE's como VS lo que necesitan es hacer menos cosas y hacerlas mejor y más rápido no tropecientas funcionalidades que se usan raramente y sólo sirven para sobrecargar de funcionalidad el monstruo.

  9. fuynfactory /  hace 2 años

    si al final quedara el lápiz y el papel ... si no con el tiempo... :troll:

  10. kimbbo /  hace 2 años

    Madre mía, la de cuñaos informáticos que salen a la luz en estos comentarios tirando por tierra todos aquellos procesos o herramientas relativos a la ingeniería del software únicamente porque no los utilizan para montar el Wordpress de su empresa.

    • Find /  hace 2 años

      Amén. He visto gente muy buena, con responsabilidad y teniendo más dudas que la mayoría de los que han comentado. Flipante :palm:

    • LelakiSerius /  hace 2 años

      #79 ¡Bienvenidos a Menéame! :hug::hug:

    • jjara /  hace 2 años

      Pues la verdad que no viene mal ponerse de acuerdo en unos tipos de diagramas, para que de un solo vistazo todo el mundo lo entienda...

      Hasta en Métrica te explican que no es obligatorio seguir los diagramas, sólo que se entienda.
      Yo lo he utilizado en su versión Métrica V3, y no comprendo como realizar ciertas cosas sin ellos.

      • fuynfactory /  hace 2 años

        se supone que el UML tendría que avanzar a unos niveles, que haciendo dibujos con las restricciones le das al conversor y que te lo transforma en clases y en código, SQL, conexiones etc... etc.. , solo necesitarías hacer las vistas y el trabajo echo. seria programar en la mas alta abstracción posible

        pero cada empresa modifica el UML como le sale de los c****es y en ciertos detalles como poner restricciones, lógica de negocio etc..etc.. no hay acuerdo ..


        pero ya sabe siempre nos quedara el lápiz y el papel .... y el ensamblador :troll:

      • KimDeal /  hace 2 años

        creo que voy a llorar, pensaba que era el único que aun se acordaba de Métrica!

    • apetor /  hace 2 años

      Sorry pero es el típico caso de "estándar" impuesto y MUY malo. Tiene algunos diagramas decentes pero otros son una puta mierda.

      #111 el problema es ese, que algunos de sus diagramas son anti-intuitivos.

    • KimDeal /  hace 2 años

      bravo y bravo y rebravo

  11. Irissu /  hace 2 años

    Que bien, justamente estoy estudiando UML ahora. Creéis que me servirá de algo? :shit:

    • Shambhala /  hace 2 años

      es importante saber hacer diagramas, aunque a veces sean mentales, otra cosa es que sirva de algo hacer el UML formal para un proyecto que no necesita ni la mitad de detalle.

    • ED209 /  hace 2 años

      no. Ni toda la mierda sobre herencia e interfaces.

      Object composition es el futuro.

    • opositor /  hace 2 años

      si

    • crateo /  hace 2 años



      Gente sin trasfondo profesional te dira que si.

      Gente con callo te dira la triste realidad :-D.

  12. Rydra /  hace 2 años

    Una palabra: qeditor-plantuml. El mejor software de modelado UML gratuito. Otros de pago como boUML también están bien.

  13. Diphen /  hace 2 años

    Que risas, yo acabo de empezar a usarlo en la carrera, tope bien oye.

  14. federico_gimenez /  hace 2 años

    Doxygen es tu amigo. Te genera también diagramas UML de manera automática. Guay para código ya existente.

  15. cucufatefate /  hace 2 años

    Pues yo lo utilizo para poner las ideas en orden...

  16. euleriano /  hace 2 años

    Estoy de acuerdo, con Dia se pueden hacer cajitas

  17. Mister_Lala /  hace 2 años

    Una vez vino un chavalín nuevo en la empresa a preguntarme por la documentación de un módulo. "¿No te la han pasado? Espera, que la tengo en esta carpeta", y acto seguido abrí el archivador, saqué una semicarpeta con algunos folios y se la di con mi mejor sonrisa.

    Al rato volvió cabreado con la semicarpeta. "¡¿Pero qué es esto?! Sólo son folios en blanco", me espetó. "Es la documentación existente del módulo. ¿No es lo que buscabas?". Y toda la sala explotó en carcajadas.

    • carlosmateo /  hace 2 años

      trabajas en un departamento de gente con necesidades especiales, no?

      Porque que reir esa tontería tiene delito.

      • Mister_Lala /  hace 2 años

        Se reían porque todos se habían visto antes en esa tesitura, la de tener que modificar un módulo y no existir ninguna documentación.

        • Salmonela /  hace 2 años

          Y todos como buenos trabajadores, lo poco que averiguaron no lo documentaron, para que la empresa siga gastando en analisis por duplicado, triplicado y lo que haga falta... muy bien todos... Los siguientes que vengan os agradeceran que seais tan buenos trabajadores y compañeros. Si es que hay siguientes debido al tira de dinero en tareas ya hechas.

          • dumbAwards /  hace 2 años

            claro hombre, criticar es bien sencillo. "La culpa es vuestra por no documentar". Claro, lo de que no te dejen sitio donde meter la documentación ya tal xD (no, los servicios externos a la empresa no son una opción en muchos casos).

            PD: como anécdota, hace relativamente poco nos obligaron a sacar la documentación que habíamos tenido que meter en el repo, así que esperemos que llegue con los comentarios en el código

            • Salmonela /  hace 2 años

              ¿Tienes una carpeta llena de archivos vacios y dices que no tienes sitio para la documentacion? No me hagas reir, la documentacion es parte del trabajo de desarrollo, si no esta hecha, para mi el trabajo no esta completado. Pero tu ponte excusas, a mi me da igual, no es mi profesionalidad la que esta en duda. En ningun momento digo que la culpa sea tuya por no documentar, ¿donde he dicho eso? ¿de donde sacas semejante tontería? Lo que digo es que de profesionales, los que no documentais, teneis poco, mas que nada porque la documentacion muchas veces va en codigo, como pueda ser un proyecto Java. Y si es un modulo independiente, como pueda ser un sistema satelite de una app para dar acceso desde fuera de la intranet, debería tener tambien su correspondiente manual de usuario. Pero lo dicho, que te pongas las excusas que quieras, a vagos como vosotros que se niegan a hacer por lo que se le paga y corresponde por categoría no los contrataba ni harto a heroina.

              • dumbAwards /  hace 2 años

                a ver, campeón, vuelvo a decirlo porque no has entendido un carajo: no nos dan sitio para documentación. Cuando la metimos en el repo en formato digital nos dijeron que la sacásemos. Sí, que hagamos la documentación y la metamos directa al triturador

                Te estoy hablando de mi caso, a lo mejor crees que estás respondiendo a otro usuario

                • Salmonela /  hace 2 años

                  Es que tu caso me da igual, yo estoy hablando del caso de Mister_Lala y tu vienes con un caso que no viene a cuento. Ademas lo que tu dices no implica perdida de documentacion, que no te den un servidor donde centralizarla, no implica que tu no puedas tener en tu maquina otro servidor o carpeta compartida para ello. Intentas defender un caso con otro diferente. A ti si te la piden, aunque no la tienes centralizada, la tienes, ¿o tampoco te dan espacio en tu maquina? No sé a donde quieres llegar, la verdad. Si no estas defiendiendo a Mister Lala, ¿a que viene tu comentario?

                  • dumbAwards /  hace 2 años

                    viene a que, para documentar tienes que tener donde guardar. Y no, el cajón de @Mister_Lala o el de Manolo el del bombo es virtualmente inexistente. La documentación tiene que ser localizable o es absolutamente inútil

                    • ED209 /  hace 2 años

                      #45 si no quieres documentar para otros, documenta para ti mismo y guárdala localmente

                      • opositor /  hace 2 años

                        Si no me la pagan no la hago. Luego si tardo 3 h en entender algo que con documentación hubiesen sido 5 minutos los cobro.
                        Y los test igual. Si no hay tiempo para hacerlos y luego hay bugs que con ellos serían más fácil de identificar y arreglar no es mi problema y cobro por horas. No voy a trabajar gratis por hacer las cosas mejor básicamente porque no tengo tiempo infinito tampoco

                        • Salmonela /  hace 2 años

                          ¿que no te lo pagan? La documentación es parte del desarrollo. Al igual que los tests. De verdad, no os quiero de compañeros en la vida. Por favor, dime donde trabajas para asegurarme de no pisar esa empresa en mi puta vida. Y decir que no te dan tiempo, a ti te dan una estimación que no tienes que cumplir a rajatabla, por eso se llama estimación (si es que no te la han pedido a ti) y si usas un sistema de ticketing tu probablemente serás el que has dado la tarea por terminada. Hay veo dos culpables, el de las estimaciones imposibles, y el de que no hace su trabajo (tu). Y no me vengas con que si no cumples te echan, si te echan por no cumplir una estimación imposible de cumplir, el juicio lo tienes ganado.

                          • opositor /  hace 2 años

                            pues no no me lo pagan. Yo trabajo por tareas.
                            Aveces me ponen a hacer test, o a documentar, otras veces a hacer X caracteristica, otras a arreglar X bug.
                            No entregó desarrollos de 0 trabajo por tareas en proyectos grandes y si en la tarea no está documentar/test no puedo aumentar las horas por hacer documentacion/test porque ademas hay prevision de horas que suelen ser cortitas, y si te pasas pues te pasaste pero si te pasas por hacer cosas que no te han mandado...

                            Yo se que es esencial documentar, y hacer tests.

                            Pero tampoco a lo loco, si el código es interpretable y no tienes tiempo de documentar ( lo gordo si lo tengo documentado no te confundas tampoco...) o de hacer test tienen que estar bien hechos (menudo cachondeo hacer tests sobre máquinas virtuales que no emulan 100% el dispositivo real y que ademas aveces fallan por causas externas al test).

                            Para mi trabajar con buenos test y buena documentación es genial pero es un lujo, y claro que ahorra mucho trabajo pero si el cliente no quiere invertir en eso no es mi problema, obviamente se comenta, y luego si hay bugs pues mas trabajo... pero avisando, sin malicia.

                    • Salmonela /  hace 2 años

                      Tío, si eres informatico y no sabes montar un servidor o recurso compartido de lo que sea para guardar la documentación apaga y vamonos. Y tu negación categórica de que si no está centralizada no esta accesible... bajo que logica te atreves a afirmar eso? acaso tu no vas a trabajar y enciendes tu maquina para ello? Ahora me dirás que los de sistemas no te asignan una ip fija dentro de la red interna. Cambia de empresa.

                      • dumbAwards /  hace 2 años

                        xD claro hombre. Tu ordenador no debería ser un recurso compartido que vaya a tener accesos muy recurrentes. Si eres informático y no sabes por qué apaga y vamos. Ni puedes ni debes hacer de tu equipo de trabajo un servidor. Y cuando te vayas de vacaciones? Y si alguien hace horas extras y tú no? y si te vas de la empresa?
                        A ver, el tema es muy sencillo: la documentación tiene que estar organizada, centralizada y en un dispositivo asignado a ese rol (por ejemplo, rara es la empresa que no tiene un servidor para uso interno) con gente controlándolo. Y te tienen que dar permiso para meter lo que sea que quieras meter.

                        #69 hombre, eso está muy bien pero aquí #19 remarca que es una pérdida de recursos para la empresa que cada trabajador cuando le toque ocuparse de algo tenga que hacer su propia documentación.
                        El problema no es si documentar o no documentar, el problema es centralizar esa documentación y para eso la empresa tiene que poner empeño y recursos, cosa que no suele pasar

                        • Salmonela /  hace 2 años

                          Accesos recurrentes a la documentación? tus compañeros son retrasaditos? Cuando te vayas de vacaciones cualquier otra persona del equipo puede ponrse una copia de esta antes de que te vayas. Volvemos a lo mismo, que temporalmente (que en el caso que expones no se da) no este accesible, no hace a algo inaccesible. De hecho, cuando te vas de vacaciones, es cuanto mas debes documentar, por si pasa algo con tu desarrollo, que otro pueda solucionarlo con cierta fluidez. De verdad, no se como os las apañais para trabajar, insisto, dame el nombre de la empresa para la que tabajas por favor, no quiero caer por ahi.

                          EDIT: No estoy negando que la documentación deba estar organizada o no. Estoy diciendo que se debe hacer, independientemte de la accesibildiad a ella.

                          • dumbAwards /  hace 2 años

                            en una empresa grande, o en un proyecto mierder con rotación alta tiene que ser accesible. Sí, con los compañeros que nos sentamos en el mismo área sí puedo compartirla. El problema es que si, puntualmente, tiene que tocar álguien que está en otro sitio y no sabe que se ha documentado volvemos a tener el problema.

                            Como te dije en mi primer comentario nosotros lo solucionamos comentando mucho el código (clases y métodos).

                            En el proyecto que estoy ahora cada requerimiento tiene que tener su documentación asociada y aún así tenemos problemas para acceder a ella así que optamos por la misma solución

                            • Salmonela /  hace 2 años

                              Insisto, te estas desviando de la cuestión, el unico empeñado en discutir si debe estar centralizada o no eres tu. El asunto que tratamos es la obligatoriedad de documentar.

                              • dumbAwards /  hace 2 años

                                sí, es obligatorio si te dan tiempo para hacerlo y sitio donde guardarla. Si no te dan tiempo o sitio directamente no te la dejarán hacer, aunque esto te parezca una aberración. Así que insisto, documenta el código

                                • Salmonela /  hace 2 años

                                  Estas entrando en bucle, dile al GC que deje mis respuestas anteriores tranquilas que necesitas reusarlas.

                                  • dumbAwards /  hace 2 años

                                    coño, tú también estás en bucle. La conversación es esta:
                                    Tú: hay que documentar
                                    Yo: Si se puede (y te dejan)
                                    Tú: pero hay que documentar
                                    Yo: Si se puede (y te dejan)
                                    Tú: pero hay que documentar
                                    Yo: Si se puede (y te dejan)
                                    Tú: pero hay que documentar
                                    Yo: Si se puede (y te dejan)
                                    Tú: has entrado en bucle.

                                    • Salmonela /  hace 2 años

                                      ¿me puedes explicar bajo que condiciones no podrías? Porque la capacidad la tienes. ¿Tu jefe te corta las manos?

                                      • dumbAwards /  hace 2 años

                                        pues a bote pronto:
                                        - falta de tiempo: hay veces que estás con varias entregas y vas pillado en todas haciendo horas extra
                                        - manager de turno: esos que creen que documentar es descansar (hay unos cuantos sueltos)
                                        - proyecto perecedero: en este hay 2 subtipos; o bien el cliente no quiere documentación (que pasa) o la empresa para la que trabajas será sustituída por otra (no se firma KT, no se facilita documentación).

                                        De ahí que diga que documento en el código. Y si tengo orden expresa de hacer documentación la hago a partir de esa

                                        • Salmonela /  hace 2 años

                                          Tu primer punto ya te lo he explicado antes, que no haya tiempo estimado (insisto en que es estimado, nadie va a venir a apagarte el PC cuando te pases) suficiente no te quita la capacidad de hacerlo, y ha de pagar el que estimo por su error en estimacion.
                                          Tu segundo punto va un poco unido con el primero, si alguna vez te echan por no cumplir una estimacion imposible, denuncialo, lo tienes ganado.
                                          Tercer punto, eso no es escusa, la gran mayoría de proyectos, por no decir su totalidad, son perecederos. ¿Podrías decirme una aplicación que jamas haya sido sustituida por una nueva version o una aplicacion alterantiva o mas moderna? Cuando el que quiera sustituirla, si no tiene la documentacion, ¿como va a poder saber que tiene que hacer la nueva?

                                          • dumbAwards /  hace 2 años

                                            mi primer punto básicamente va de que la documentación no la piden. Intento no hacer horas extras porque, en fin, es mi tiempo libre lo que pierdo aunque me den dinero.
                                            En el segundo, si te dicen que hagas otra cosa en vez de documentar la haces, por mucho que estimes que si no documentas se acaba el mundo.
                                            Y en el tercero, si la empresa no pide documentación no la haces, principalmente porque te ponen bien rápido a hacer otra cosa. Y si cambian de empresa tampoco, porque poner las cosas fáciles no es el spanish style

                                            Así que sigo documentando el código salvo que me pidan más documentación, si alguien toca actualiza comentarios y así, si alguien viene nuevo no tiene que andar preguntando quién tiene qué documentación. Y si te toca mirar el año que viene algo sobre ese proyecto no tienes que buscar nada: la tendrás en cuanto hagas checkout

                                            • Salmonela /  hace 2 años

                                              De verdad, no entiendo la exposición que haces sobre lo de las horas extras. A mi me hacen una estimación de mierda, y me voy a mi casa a mi hora y al dia siguiente continuo con mi horario normal hasta que termine lo que tengo que terminar, que vengan a quejarse que los pongo finos. Yo no tengo que pagar los errores de estimación que cometen otros. Recuerda que las estimaciones son por horas, no te dicen de tal fecha a tal fecha, esa es una estimacion de gestión que a ti ni te va ni te viene que se probablemente se alterara debido a 1000 causas posibles. ¿Que pasa si te pones enfermo dentro de esas fechas? Por eso no entiendo lo de las extras. Tienes los dias que quieras.

                                              • dumbAwards /  hace 2 años

                                                así es, y como no estiman para documentar no documento. Cuando acabe la tarea me pondré con otra, porque habrá más

                                                • Salmonela /  hace 2 años

                                                  No estoy diciendo eso, yo documento y lo imputo en la tarea, y si tardo mas tardo mas, sin echar horas. Todavia estoy esperando que me echen por eso.

                                                  • dumbAwards /  hace 2 años

                                                    me alegro por ti. Yo prefiero documentar el código: será accesible para quien venga después, sea quién sea, y lo hago mientras desarrollo. Y como trabajamos así siempre tenemos la documentación actualizada y accesible. Y mira, sin guardar nada en un cajón que solo yo sé de su existencia o en mi ordenador al que solamente yo tengo acceso. Y lo mejor es que funciona siempre que la gente tenga asumido que hay que actualizarla

                                                    • Salmonela /  hace 2 años

                                                      No sé porque me lo expones como algo diferente, documentar el codigo es parte de la documentacion, por ejemplo en Java, es javadoc el que genera la documentacion en funcion del codigoy comentarios de estos. Hay muchas formas de documentar, otro ejemplo lo tienes si utilizas raml para desarrollar apis-rest, ademas de como documentación te vale para la generación automatica de ciertas partes del codigo.

                                                      • dumbAwards /  hace 2 años

                                                        yo documentación le llamo al pdf corporativo con todos los logos y parafernalia llena de 5 páginas de literatura inútil por cada página útil. Vamos, la que exigen de cuando en cuando

                                                        • Salmonela /  hace 2 años

                                                          Es que esa es una mierda de documentación y por norma general no es muy util, porque como dices la literatura es un chiste, sobre todo porque al ser plantillas y no saber como redactarlo la gente tira mucho de copy-paste. A mi me han llegado DTDs con los que hacer desarrollos que del asquito que daban los cogia con guantes. Eso no es mas que el justificante que necesita tu gerente para decirle a su superior, mis chicos han hecho o estan haciendo todo esto, dame mi bonus.

                                                          Desgraciadamente cuando te piden algo que no es reclamar y por contenido no es util tecnicamente hablando, es que es un justificante que necesita tu jefe.

                        • ED209 /  hace 2 años

                          ¿donde pone que mi workstation sea un servidor?
                          Te digo que documentes para ti. Para tu "futuro yo". Pero no lo has entendido. Tienes razón: apaga y vámonos

                          • dumbAwards /  hace 2 años

                            tu respuesta es la segunda parte. Donde aparece referenciado tu comentario, básicamente

                            • ED209 /  hace 2 años

                              creo que todos (cc #144) queremos decir lo mismo.
                              Mi punto de vista tan solo incide en que si la empresa no quiere documentación ni mis compañeros tampoco, yo sí documento para mi "futuro yo", porque en 3 meses lo habré olvidado, y meterme en harina otra vez es muy pesado.

                              • dumbAwards /  hace 2 años

                                y por eso digo lo de comentar el código. Estará en un repositorio y será accesible por cualquiera que tenga que mirar

          • opositor /  hace 2 años

            bueno la documentación también te tendrán que mandar hacerla. No vas a echar horas no pagadas en hacerla

            • Salmonela /  hace 2 años

              ¿Y quien habla de echar horas extras? ¿por que cambias el contexto?

              • opositor /  hace 2 años

                Pues porque el tiempo es limitado.
                Como dije a #161 lo gordo si lo documento, pero por documentación entiendo tener un wiki de puta madre con todo al detalle.
                Yo si añado una funcionalidad la comento, si los métodos y la lógica es sencilla y autodescriptiva ni eso. Pero mas a nivel comentario de codigo. Luego si hay algo mas complejo que ami me cuesta entender hago un pequeño esquema, pero en plan rápido y sencillo(lo sencillo que se pueda) y solo para cosas complejas.
                No documento todo solo lo que veo necesario 100% y me lleva tiempo. Porque ademas aveces te toca trabajar sobre cosas de otros y documentar un poco lo que han dejado al añadir tu mas complejidad.

                • Salmonela /  hace 2 años

                  Ya he explicado en otro comentario que el desarrollo de tests y la documentación es parte de las tareas de desarrollo, si no cumples planificaciones imposibles no es motivo de despido. Si las sigues y tu das por finalizada la tarea eres igual de responsable que el que hizo la estimación erronea. Si la estimación es erronea el que debe pagar el pato es el que la hizo. El que estas quedando mal con tu trabajo eres tu, yo cuando veo casos descarado de desden suelo fijarme en los usuarios que hacen esas cosas, para asegurarme no trabajar con ellos. Si he visto tu nombre en algo no documentado, y algun dia me llega un CV tuyo, te aseguro que no trabajaras conmigo. El gerente al que le has seguido el juego seguro que le irá mejor que a ti. Estas pagando tu por el, porque te de la gana. Pero vamos, no voy a insistir mas en esto, cada uno verá lo que hace con su vida. Yo por mi parte lo tengo claro, mi trabajo es mi carta de presentación y debe estar lo mejor posible. El que quiera hacer tarbajos guarros que lo haga con su usuario.

                  • opositor /  hace 2 años

                    en realidad tienes razón.
                    Pero, no es mi caso porque yo no trabajo con horario de oficina en una oficina de todas formas pensandolo un poco si que documento.
                    No creo wikis estupendas, pero si tengo que modificar un modulo existente explico la modificación o en la propia tarea o en el código. Suelo documentar todo lo que considero esencial.
                    Lo que no hago es pararme a crear graficos o a hacer documentacion bonita o a documentar lo de otros. Y ademas trato de que el codigo se explique por si mismo. Por un lado esta la docuemntacion del codigo y metodos y por otro una mas abstracta y conceptual de la aplicacion ( que es en la que yo pienso al hablar de documentar) y claro si me piden "añade un boton que haga X, no tiene sentido que haga una wiki para documentar eso, el boton se llama botonQueHaceX, y no tiene mucho más.

                    Con cosas mas complejas siempre las explico y dejo referencias.

                    Asi que no se... yo lo que no hago es una documentacion superelaborada y bonita, si dejo constacia de que, y porque, y explico en la medida de lo posible las cosas.

                    Pero mira tu cojes una aplicacion acabada y te piden modificar cosas... Pues explicas lo que añades. Si te toca pelearte entendiendo algo haces un pequeño resumen... Tampoco cojo y lo tiro a la basura porque ademas igual en una semana me piden revisarlo y ya no me acuerdo si no dejo constancia. Lo que no hago es dedicar 3h a documentar salvo que me lo pidan, a ver si se entiende un poco mejor asi.

                    • Salmonela /  hace 2 años

                      Desde luego, no hay que exigir mas de lo que se debe, yo al igual que tu, solo documento mi trabajo y el de otro solo si lo he tenido que analizar por algo.

      • Arth /  hace 2 años

        A lo mejor el módulo no era suyo, o era heredado, etc, etc, etc. No nos apresuremos a criticar. ;) A mi me ha pasado que directamente no te dan tiempo para documentar o refactorizar código. Si consigues que una ñapa funcione, no te molestes en hacerlas cosas bien, la ñapa se queda... para siempre. (truenos)

    • Yonseca /  hace 2 años

      ¿Dónde está la gracia? La falta de documentación y de rigor a la hora de poner el trabajo es una de las principales causas de que la gente pierda el tiempo programando sobre la marcha.

      • Shambhala /  hace 2 años

        ojalá me diesen tiempo para documentar en mi trabajo...

        • Chupame_el_wifi /  hace 2 años

          Se supone que la vas creando a medida que programas. No necesitas que te asignen un tiempo para ello...

          • Shambhala /  hace 2 años

            si se asigna un tiempo tan bajo a una tarea que no da tiempo ni a programar en condiciones menos a documentar. Y sí, se que si programas bien lleva menos tiempo que programando mal, solo que a veces no puedes ni programar bien por que el proyecto en el que estas tiene taras.

            • Chupame_el_wifi /  hace 2 años

              Si el tiempo que te dan no te llega ni para programar lo que te piden tienes un problema muy gordo y perderéis mucho tiempo en el futuro arreglando mierdas que podríais usar en documentar. Habla con tu jefe. Cambia el sistema.

              • Shambhala /  hace 2 años

                ya te digo :-( es tal cual dices.

              • Chota /  hace 2 años

                Entiendo perfectamente a #66. El problema viene cuando tu jefe no es desarrollador, sino comercial, y hay que hacer las cosas a su modo. Si además es de esos "supergurú emprendedores que saben más que tú de todo", lo llevas jodido...

                • opositor /  hace 2 años

                  tu jefe o tu cliente

                • Chupame_el_wifi /  hace 2 años

                  En ese caso hay que usar mucha psicología.

                  Siempre viene bien utilizar palabras modernetas tipo "sinergia" para respaldar tu petición. Pero lo mejor de todo es dejarle a el ver que la solución es idea suya. Dejarselo en bandeja y cuando diga:
                  "Quizá deberíamos dedicar algo de tiempo a documentar..."

                  "Gran idea jefe! Precisamente tengo yo aquí una propuesta de cambio de tareas que..."

              • anv /  hace 2 años

                Lo que pasa es que en el futuro tal vez espere estar en otro trabajo mejor. Esto es como los directivos de las empresas: se meten en cosas como trucar los motores de los coches para obtener buenas ganancias ese año. Cuando se descubra el truco y venga la multa ya le tocará a otro lidiar con ello.

                Por eso el software libre tiene tan buena calidad en comparación. Porque se hace sin presiones y con la intención de hacer algo bien hecho, no algo para vender el mes que viene.

                • Arth /  hace 2 años

                  Y es por eso que muchas veces descubres un bug en una funcionalidad básica para el usuario, vas a reportarla, y ves que hay un montón de issues con dicho fallo que se remontan a 2002. :troll:

                  • anv /  hace 2 años

                    Si te refieres al software libre... si encuentras un bug que no se ha arreglado desde 2002 será que a nadie le ha interesado arreglarlo. Si es importante para ti podrías arreglarlo tu mismo y de paso colaboras un poco, ¿no?

                    • Arth /  hace 2 años

                      No te digo que no, pero al final eso es tirar balones fuera, al final depende de a que software libre te refieras pero no diría yo que tenga mucha calidad en general. Hay muchas cosas que se han quedado tiradas por hacer cosas sobre la marcha y en las que nadie se quiere meter, y tu esperas que vaya yo a meterme... además, asumes que cualquiera que encuentre un bug tendrá capacidades para ello.

                      Y sobre que a nadie le ha interesado arreglarlo, pues eso, por eso decía que eran cosas de funcionalidad básica que han sido reportadas una y otra vez. En mi experiencia personal, la mayoría de software libre está roto, muchas veces en aspectos básicos, y la forma de elegir que software libre vas a utilizar es elegir uno que no esté roto en aspectos básicos importantes para ti o de los que no puedas prescindir. ;)

                      • anv /  hace 2 años

                        No. No asumo que cualquiera pueda arreglar los bugs. Pero asumo que tu si porque pareces saber de lo que hablas.

                        • Arth /  hace 2 años

                          Como quieras, pero es tirar balones fuera, así que el software libre es mejor porque todos hacen las cosas sin presiones y buscando hacer algo de calidad, pero si no funciona, ah, es tu culpa. El software libre en sí mismo no es mejor que otro por ser libre, podrá tener sus ventajas, pero no hace que mágicamente todo sea una panacea.

                          • anv /  hace 2 años

                            Pues en realidad sí. Si el software libre no funciona y nadie lo arregla, es porque no hay interés. Y si no hay interés es porque no hay nadie interesado en mejorarlo, seguramente porque no tiene mucha utilidad o porque hay algo mejor o porque simplemente quienes podrían usarlo ya se han decidido por otra alternativa y los programadores están en otra cosa.

                            • Arth /  hace 2 años

                              Sinceramente me siento como conversando con un predicador. xD De todas formas mi opinión ya la dejé clara, esto simplemente es mentira:

                              Por eso el software libre tiene tan buena calidad en comparación. Porque se hace sin presiones y con la intención de hacer algo bien hecho, no algo para vender el mes que viene.

              • celyo /  hace 2 años

                Habla con tu jefe. Cambia el sistema. xDxDxD

                Ahora mismo con la tendencia a microtareas no se prima un tiempo dedicado a documentación por 2 motivos:

                i. El cliente no quiere asumir un coste de que el programador se dedique a documentar correctamente lo que hace.

                ii. Tu jefe solo te exigirá el tiempo aprobado por el cliente. Ya a veces se va justo con el tema de pruebas pues ya no te digo cosas como hacer documentos.

                Ojala fuera tan fácil, y si lo has conseguido te doy mi enhorabuena.

                • Chupame_el_wifi /  hace 2 años

                  Todo eso está muy bien como idea hasta que empiezan a salir todos los bugs y problemas, especialmente en proyectos grandes o largos en el tiempo. El tema del tiempo entonces ya toma otro cariz y no parece tan descabellado dedicarle más a revisar y solucionar.

                  Ese es el momento de atacar! :-D

                  • celyo /  hace 2 años

                    Si el programa no tuviera bugs no se contraría un mantenimiento xDxD:wall:

                    Donde trabajo se ha pasado de proyectos de una duración X a proyectos compuestos de microtareas y donde tienes que justificar el tiempo empleado. Todo a petición del cliente.

                    Antes era asumible dedicar tiempo a documentación o seguimiento propio de bugs u otras tareas menores, ya que había huecos libres para ello. Ahora parece esto un trabajo de fontaneros, te pago X por un tiempo y si te pasas de ahí que salga gratis.

                    • Chupame_el_wifi /  hace 2 años

                      Ok, pero qué haceis en vuestra empresa de fontaneros con tiempo superlimitado cuando empiezan a salir muchos problemas. No teneis tiempo para nada así que... ¿no los arreglais?

                      • celyo /  hace 2 años

                        Si se arreglan, por el simple hecho que el cliente ve si la microtarea está o no realizada, ya que si no paga. ¿Pagarías a un fontanero que te deja un grifo a medio poner? :-D

                        Yo no digo me guste el sistema, solo que me parece un sistema de locos, todo porque el cliente se quiere ahorrar dinero, que está en su derecho, además de incrementar mucho la burocracia. Espero que en otros lares de donde estoy sea la cosa mejor.

          • opositor /  hace 2 años

            si y no. Comentarios en el código y código legible por si mismo es una cosa y una buena documentación es otra. Si tienes tiempo limitado aunque se supone eso o te paras en esos detalles y no acabas o vas a la chicha y acabas.

      • Ander_ /  hace 2 años

        Mejor no te cuento como funciona el departamento de sistemas.

      • Mister_Lala /  hace 2 años

        #76 #17 A mí no tienes que convencerme. Eso cuéntaselo al dueño de la empresa. Es de los que piensan que si no estás tecleando, es que no estás trabajando. Con eso te lo digo todo.

        #94 ¿Sentirnos fatal porque no hay documentación? Entonces nos pasaríamos los días llorando. De unos años a esta parte sí que hay algo de documentación en word sobre qué debe hacer el módulo, las tablas que lleva y el significado de los campos. Y para de contar. Sobre código, los propios comentarios en código que ponemos nosotros.

        #83 Los únicos bugs críticos que hemos tenido han venido por parte de google, que con cada nueva versión del navegador nos fastidiaba algo. Terminamos por deshabilitar la actualización automática.

        #6 #65 Para nada. Las tablas se diseñan directamente en sistema relacional, y no hay esquema E-R que valga. Cuando necesitas saber a qué tabla auxiliar hace referencia una foreign key, o miras las constraints, o le preguntas a uno de los DBA.

        Los "jefes de proyecto" de la empresa en la que trabajo son en realidad comerciales. Sólo uno de ellos tiene estudios universitarios de informática. Dan presupuestos y fechas de entrega basados en la experiencia previa, pero sin tener ni idea del trabajo real que pueden acarrear. La documentación que nos llega es al principio de los proyectos, y en word. Cuando son modificaciones sobre un proyecto estable, los cambios se piden de viva voz o por un correo, sin documentar nada más. Como además donde se necesitan 5 programadores hay sólo 3, pues los tiempos siempre vienen apurados, y no da tiempo a documentar técnicamente nada por parte nuestra.

        La documentación en word es algo obsoleto, porque no tienes un acceso directo y rápido a la información. Tampoco ayuda a que cada vez que se modifica un módulo, los responsables la actualicen. Una documentación accesible, esquematizada, fiable y actualizada reduce enormemente los tiempos de desarrollo y los fallos. Por desgracia quien maneja el cotarro no quiere enterarse de eso.

        ¿Y cómo me afecta personalmente? Pues más de una vez me ha tocado lidiar con un módulo que migra de tecnología, o que me lo han asignado porque un compañero ha sido despedido o se ha ido. Donde tardarías tres días, echas dos semanas de trabajo, pero es algo que la empresa asume que así va a ser. En realidad a mí qué más me da estar haciendo una cosa que otra: tengo que estar 8 horas en el curro igualmente. Pero sí que tiene una ventaja para el trabajador. Llega un momento en que has trabajado y conoces un montón de módulos, y te conviertes en alguien de quien no pueden prescindir sin pensárselo dos veces por todo el conocimiento que posees. Tal y como está el mercado laboral hoy en día, contar con esa ventaja no es ninguna tontería.

        • undy /  hace 2 años

          #6 Que en tu empresa se trabaje así no significa que lo puedas generalizar a todas partes. Tanto UML como el modelo entidad-relación se usan muchísimo

          • waterbear /  hace 2 años

            Yo creo que estandarizar la documentación tiene sentido (del mismo modo que hacen los arquitectos con los planos), pero tu afirmación de que en la práctica "se usan muchísimo" no está nada clara: en la noticia Microsoft elimina el soporte por su bajo uso en una herramienta para un público global. No se que significa "poco" para Microsoft o "mucho" para ti, pero creo que un fabricante de herramientas de desarrollo tiene una buena posición para evaluar que usa y no usa la gente.

            • undy /  hace 2 años

              No se que significa "poco" para Microsoft o "mucho" para ti, pero creo que un fabricante de herramientas de desarrollo tiene una buena posición para evaluar que usa y no usa la gente.

              Tiene una buena posición para evaluar si la gente usa o no SU herramienta de desarrollo. Personalmente, he visto muchos proyectos de desarrollo hechos por muchas empresas, y en todos se usa UML (otra cosa es que se haga más o menos acertadamente, o que sólo se use una mínima parte de la especificación). Por supuesto, lo de mucho o poco es relativo, pero mi mensaje era en respuesta a uno que aseguraba a otro que nunca usaría UML en toda su carrera profesional

        • Harkon /  hace 2 años

          Hombre yo cuando estoy dibujando un diagrama de red, que es equivalente en cuanto lo que parece que estás haciendo con diseñar un diagrama UML nadie me dice que no esté currando.

          Pero bueno estoy comentando en menéame y nadie se atreve a decirme que no esté currando :troll:

    • diegogmx /  hace 2 años

      Una semicarpeta dentro de la subcarpeta contenida en otra carpeta con los folios en blanco... Gracia la justa

    • Maegruin /  hace 2 años

      La de risas que os debeis pegar en tu trabajo cuando surge un bug crítico de un modulo sin documentación de hace años y teneis que solucionarlo....

    • mcgregor /  hace 2 años

      y en vez de sentiros fatal por no tener documentación, pues os echasteis unas risas. Perfecto.

  18. AkiL3s /  hace 2 años

    Joder pues no lo usaran en microsoft pero aquí lo usamos mucho, para ser exactos el plantUML plantuml.com/

    • tnt80 /  hace 2 años

      Tranquilo, seguramente lo cambiarán por su propia versión de UML, dirán que es mejor, más chachi y demás, y listos :-|

      • AkiL3s /  hace 2 años

        {0x1f602} Seguro, pero aquí somos de usar cosas open source, ya se paga bastante por el winblows y el office :troll:

        • tnt80 /  hace 2 años

          Bueno, el metamodelado, por ejemplo, ya se hacía mejor y casi en exclusiva en Eclipse xDxD por lo que, si Visual Studio no quiere UML, cacsi mejor, algo menos que pueden joder xDxD

  19. Torrezno2010 /  hace 2 años

    No se usa porque algo que nació para ser útil se convirtió en una cosa complicadiiiiísima. Pero siempre va bien tener algo que dibuje cajas y flechas con los símbolos de 1.1 1,n y cuatro cosillas mas del uml

  20. CrudaVerdad /  hace 2 años

    Hoy UML, mañana caerán los "Patrones de Diseño" :troll:

    • uber /  hace 2 años

      Eso jamás. UML es irrelevante ahora con las metodologías ágiles, pero los patrones son cada vez más importantes y más usados.

      • cucufatefate /  hace 2 años

        Será irrelevante para tí. Para mí es imprescindible. No tiene nada que ver con la metodología que utilices. Es un método de representación. Yo flipo en el trabajo cómo la gente no hace un puto diagrama de nada, y después las cosas salen como salen. Metodología ágil no significa ser un tontaina.

        • uber /  hace 2 años

          si uno sabe diseñar, usar patrones y frameworks no necesita hacer un diagrama para explicar la arquitectura al resto del grupo, al menos no más que un diagrama simple que se hace en media hora.

          • cucufatefate /  hace 2 años

            Discrepo. El problema es que nunca se hacen diagramas. Otra cosa es el proceso unificado de rational, que sí que es excesívamente engorroso. Pero hay muchas muchas cosas que sí que requieren un diagrama. Incluso aunque sepas diseñas y usar patrones, los diagramas nunca están de más.
            Te doy la razón que aquellas cosas con cambios constantes cualquier diagrama se pudre rapidísimamente, pero cuando algo se estabiliza, sería deseable un diagrama.

            Otra cosa es que nunca se haga. Pero cuando eso mismo tengas que mirarlo un año después, agradecerás tu propio diagrama.

            • uber /  hace 2 años

              los diagramas me parece algo muy ochentero, toda la información que necesitas la tienes de usar patrones, frameworks, convenciones de estilo y la documentación, la evolución la tienes en el propio repositorio y las issues.
              Asi funcionan proyectos de software libre con millones de líneas de código y miles de desarrolladores, no hay diagramas pero todos pueden saber fácilmente que hace cada cosa, si algo no se adapta dicho framework y estilo no se acepta y punto.
              Ahora sí, a nivel medio amateur, cuando cada uno programa como le da la gana, se hace una cagada encima de otra y el diseño se complica cada vez más, pues en ese caso hay dos opciones: hacerlo todo nuevo o hacer unos diagramas de la ostia para seguir tirando.

              • cucufatefate /  hace 2 años

                Yo estoy en un proyecto de software libre y hago mis diagramas :-P
                No deberías asumir que todos tienen una memoria increíble y una comprensión apabullante como la tuya (lo digo porque considero que para no hacer nada en papel hay que tener memoria increíble y comprensión apabullante). A mi edad la memoria no es tan eficiente.

                Pues eso: no todos son como tú, y no significa que seamos inservibles. ¿Tú no necesitas diagramas? Guay por ti. Otros sí que los necesitamos.

                Y mis compañeros de trabajo, jóvenes ellos recién saliditos de FP, todavía tiernos, se acuerdan de las issues en las que han estado y qué líneas de código han escrito. Otros no tenemos ya energía de tantos años acordándonos de basura que al final más vale olvidar porque es absurdo acordarse de esas cosas.

                Por supuesto que agradezco los patrones y consistencia en el estilo de código: el día que tengo que leerlo es mucho más fácil. Pero el primer día que me enfrento con algo, prefiero ver de un vistazo qué cosas hay, qué relaciones hay entre ellos.

                Y de software libre dices que no se complica porque se hace todo de nuevo (ya que hablas de no hacer diagramas)? Pues no has visto el código de Nutch :-P

                • uber /  hace 2 años

                  diagramas hay en los grandes proyectos de software libre, pero hacer esos diagramas no supone ni el 1% del trabajo, nada que ver con métrica y esas metodología del siglo pasado, con un buen diseño un diagrama hecho en PowerPoint en un par de diapositivas es suficiente.

                  Uml es demasiado formal, demasiado verboso y demasiado lento, no es mejor que un párrafo y un mini diagrama informal hecho en 5 min, por eso ya no se usa.

                  • cucufatefate /  hace 2 años

                    Sólo puedo decirte: depende. Yo no hablo de documentar todo extensivamente.

                    ¿Métricas y cosas de esas? No, yo no hablo de eso. Pero puedo asegurarte que un buen diagrama ahorra muchos dolores de cabeza.

                    Por definición UML no es "demasiado formal", puesto que está creado para ser personalizable. Tampoco tiene que ser "demasiado verboso", y si lo es, seguramente está mal porque debería descomponerse en diferentes vistas en función de la necesidad y lo que se quiera explicar. Y ¿lento? eso no sé ni lo que significa, aunque si te refieres a que hay que invertir tiempo, es tiempo que luego redunda positivamente en tener menos errores y tardar menos.

                    Cualquier "mini diagrama informal hecho en 5 minutos" seguro que es inservible. A mí hacer un diagrama me puede llevar fácilmente 30 minutos, y después lo uso un montón de veces.

                    O compañeros de trabajo que se tiran 4 horas (contadas) haciendo cerdadas, y cuando ya no pueden más porque las cosas no funcionan, me llaman, hago mi diagrama con el que se detectan todas las cerdadas mal hechas, y se ven cómo han de estar bien, y se soluciona en 45 minutos (y porque no reutilizan el diagrama porque no le hacen ni puto caso, que si no...).

                    No digo que tú tengas que usarlo, pero de ahí a borrarlo de la faz de la tierra hay un largo trecho.

                    • uber /  hace 2 años

                      lo que decía, a peor código más necesidad de diagramas en sitios con manuales de estilo estrictos y donde todo el mundo sabe diseñar no hacen tanta falta

                    • neuralgya /  hace 2 años

                      Sabes que a partir de ahora se te conocera como diagramaman, no?

              • Ander_ /  hace 2 años

                "toda la información que necesitas la tienes de usar patrones, frameworks, convenciones de estilo y la documentación, la evolución la tienes en el propio repositorio y las issues."

                Y de hecho hay herramientas donde la realización del diagrama se hace automática, como graphviz.

          • AaLiYaH /  hace 2 años

            Y si mañana lo tiene que tocar otro, ¿qué se joda verdad? Y si mañana tienes que tocar tu lo de otros, ¿que te jodan no?

            Diciendo lo que dices, me encantaría ver tus diseños... :roll:

      • Bilki /  hace 2 años

        si estamos hablando de patrones de OO, cada vez son menos importantes y se usan menos, puesto que sólo sirven para superar las limitaciones de ese paradigma. Con la introducción de funciones de orden superior ya te limpias unos cuantos.

        El libro de Gang of Four hay gente que lo clasifica como "veneno para el cerebro" (Mario Fusco por ejemplo), y el problema es que se sigue explicando en las facultades sin razonar por qué son realmente necesarios los patrones de diseño (de OO).

      • borteixo /  hace 2 años

        UML es irrelevante ahora con las metodologías ágiles -> NO
        UML es un lenguaje que entendemos todos y para explicar un desarrollo compartido es la mejor idea.
        Con metodología ágil lo que no puedes es tirarte 7 días haciendo un UML.

      • BodyOfCrime /  hace 2 años

        Puedes explicarme como si no tuviera ni zorra de programacion que coño es UML? Si ya lo haces con manzanas y peras pues mejor que mejor xD

        • uber /  hace 2 años

          es la manera más lenta de describir el diseño o funcionamiento de un sistema. Cuando un sistema está bien diseñado un borratajo en una servilleta vale, cuando alguien no tiene ni puta idea acaba haciendo un diseño tan malo que necesita explicarlo con uml

    • yemeth /  hace 2 años

      Los cojones.

      El UML es una basura, los patrones de diseño son una cosa fantástica y yo me cago en los profesores de la ingeniería superior que me obligaron a perder tiempo haciendo dibujitos de mierda pero que en programación orientada a objetos se quedaron en chorradas básicas tipo "la clase triángulo hereda la clase figura..."

      • Ricardo1980 /  hace 2 años

        Si "la clase triángulo hereda la clase figura..." es lo que sabes de UML o lo que te enseñaron, mal vas.

        • yemeth /  hace 2 años

          Hablaba de programación orientada a objetos, y que se enseñaba lo muy básico de conceptos como la herencia.

      • AaLiYaH /  hace 2 años

        Yo también eché mucho de menos temario de patrones de diseño, algo que luego me ha tocado aprender por mi cuenta fuera.

        Muchos patrones son cosas de perogrullo que se te pueden ocurrir perfectamente a ti sin conocerlos, pero como digo, habría preferido saber patrones de antes en más de una ocasión y no haber tenido que reinventar la rueda.

        Ahora bien, decir que UML es basura...en fin xD

        A mi me enseñaron herencia, pero me enseñaron también cosas que, a mi juicio, resultan más importantes que los patrones de diseño, como las relaciones entre clases. Esos conceptos marcan diferencia a la hora de hacer buen código a mi juicio.

        • yemeth /  hace 2 años

          Es cierto que tengo la manía de englobarlo dentro de "esas cosas a las que les tengo manía", cuando de lo poco que me quedo son los documentos de especificación de requisitos (para atar al cliente más que nada) y los diagramas entidad/relación para bases de datos (que en realidad el UML no es muy diferente de esto último).

          Yo recuerdo poco más que la herencia y tonterías básicas y mucho perder el tiempo haciendo diagramas estúpidos, y años después descubrir el libro famoso de patrones de diseño, mejorar mi código en varios órdenes de magnitud, y que todavía sigo aprendiendo cosas.

    • borteixo /  hace 2 años

      Este patrón de diseño ya cayó

    • impalah /  hace 2 años

      ... y pasado Java.

      ¡Ay, qué bonito sueño!

  21. cubaman /  hace 2 años

    Ojalá liberen las herramientas UML como Open Source, y si alguien lo necesita las pueda usar. Es cierto que no son muy usadas, pero en proyectos grandes son casi una necesidad.

    • rodz /  hace 2 años

      en proyectos grandes son casi una necesidad.

      UML tiene demasiada morralla. Con herramientas de diseño genéricas ya va bien. Si de todas maneras el 90% de la documentación usable son tablas, texto, ejemplos, comentarios y demás. De todas maneras el uso real de UML no justifica la integración con Visual Studio.

      De hecho la herramienta con la herramienta de #7 sobra y todo.

      Yo creo que no he hecho más que los que están aquí yuml.me, y la verdad la mayoría de los que he usado los podía haber hecho con Paint y power point en poco tiemp

    • opinador /  hace 2 años

      Una pérdida de tiempo y dinero más bien.

  22. CrudaVerdad /  hace 2 años

    Y no, no es que eliminen a Paint porque hay muchos software para dibujar, allí sigue ese software sencillo en Windows. ¡Eliminan a UML!

      • Chupame_el_wifi /  hace 2 años

        Si esta a punto de llegar el Paint con objetos 3D...

        • Salmonela /  hace 2 años

          Te has molestado en leer el link que he puesto? porque la mitad de los que me estais contestando ni habeis leido el parrafo donde rectifico, ni el link que adjunto. Que mania teneis con contestar sin leer los comentarios completos. En cuanto veis algo (sin leer el contexto completo) que no os gusta, os lanzais. Lo de los objetos 3ds de donde te lo sacas? Yo hablo en función de la documentación oficial de Paint, ¿en base a que lo dices tu?

        • waterbear /  hace 2 años

          ¿van a hacerle la competencia a ZBrush?

          • Chupame_el_wifi /  hace 2 años

            Están cagados en ZBrush. De hecho se habla de la nueva peli de Pixar vendrá toda hecha en Paint.

      • LelakiSerius /  hace 2 años

        Están desarrollando una versión UWP (es un tipo de aplicaciones que solo se pueden instalar en Windows 10) de Paint, así que muerto no está.

    • gonas /  hace 2 años

      Si no te gusta, no lo uses. Además, la tendencia es que todas las aplicaciones adicionales que traiga Windows, lleguen via la tienda. Microsoft siempre ha tenido miedo a las leyes antimonopolio, por eso no han mejorado Paint.

  23. sacreew /  hace 2 años

    Joder, tanto estudiarlo en la carrera para esto. Bueno, siempre nos quedará el mus.

    • Mister_Lala /  hace 2 años

      Pues sí, porque el modelo entidad-relación para bases de datos tampoco lo vas a usar nunca profesionalmente.

      • sacreew /  hace 2 años

        No te creas, yo tengo bastantes relaciones con entidades.

        • Mister_Lala /  hace 2 años

          Sí, con el BBVA, con el Santander,... Se llaman deudas.

      • Acido /  hace 2 años



        Tu comentario es irónico ¿verdad?

      • kimbbo /  hace 2 años

        ¿Por qué dices eso o en qué te basas para realizar tal afirmación?.

      • Harkon /  hace 2 años

        #1 Eso, pasémonos el diseño por el forro de los cojones, bueno es lo que hacen el 99,9% de los desarrolladores...

      • borteixo /  hace 2 años

        estás de coña?

    • zhensydow /  hace 2 años

      puedes usar papel y lápiz para realizar UML pero corres riesgo de romperte la mano de repartir cartas :troll:

      • gonas /  hace 2 años

        La gracia del UML es que sirva de documentación. Si luego no se mantiene, al final no sirve para nada.

        • jas80 /  hace 2 años

          ¿documentación? ¿Y eso qué é lo que es? (léase con acento andaluz)

          • sacaelwhisky /  hace 2 años

            ¿Lo del acento es para que quede claro que lo dice un tonto?

          • perseo /  hace 2 años

            hay gente pa to

          • Jiraiya /  hace 2 años

            Tienes la gracia en el culo, deja el humor en manos de profesionales. Un andaluz.

            • Arth /  hace 2 años

              A uno que le salga el acento natural. :troll:

          • usuario.poco.conocido /  hace 2 años

            #28 Esos macroproyectos con cientos de páginas de documentación obsoleta que se hacían durante meses y nadie leía después del desarrollo. No sé como han podido ser reemplazados por herramientas como wikis y similares con algunas imágenes básicas y fáciles de entender...

        • herrerii /  hace 2 años

          el estereotipo es el ataque de los ignorantes, los españolistas como siempre creando independentistas.

      • opositor /  hace 2 años

        paper y lápiz? Estamos locos¡¡???

        • dkcpxxtskcum /  hace 2 años

          no, lo haces en papel, a lápiz, y después lo pasas ordenador. Así trabajamos los genios de la industria electrónica e formatica

          • opositor /  hace 2 años

            pero que era un lápiz?

    • frankiejcr /  hace 2 años

      Para . Gnu/Linux. No tienes porque permitir que los caprichos de una sola empresa dirijan tus pasos.

    • xeem /  hace 2 años

      , en la carrera también existen los créditos de libre configuración y no hablemos ya de asignaturas que luego no sirven para nada. Podremos estar de acuerdo o no, pero las hay.

      #3, como documentación está bien en proyectos pequeños/medianos/grandes/supergrandes/ultragrandes/megagrandes/teragrandes ... :-D pero sobre todo está muy bien que cuando cambian las personas del equipo de trabajo que mantiene un software exista un documento o varios donde que se expliquen como funciona ese software y si quieres meter UML en el documento, pues fale vale y para mi el word/writer/page/notepad/notepad++/sublime ... cumplen muy bien este cometido.

      • perseo /  hace 2 años

        existían

    • estebanbcn /  hace 2 años

      UML no sirve PARA NADA. Me explico.

      UML es la especificación formal del dibujo que muchos desarrolladores ya hacíamos en papel con bolitas cuadraditos y flechas antes de que existiese. Que eran dibujos para dar soporte rápido a ideas y formas de explicar diagramas y/o flujos de informacion. Pero eso no era ni es UML. Eran diagramas y bolitas.

      Las cosas no son útiles de por sí. Solo son útiles si su empleo es productivo y útil.

      25 años de profesión. Ingeniero informática. No he visto nunca un documento UML actualizado respecto a la versión actual del software.

      UML lo usan los malllamados consultores - la mayoría ni puta idea de informática a nivel útil porque apenas han desarrollado uno o 3 años antes de ponerse la corbata.

      UML sirve para que dichos consultores y algún jefe de proyecto que piensa que sabe mucho hagan un montón de diagramas para hacer ver que su trabajo es útil. Trabajo que nunca se actualiza y queda guardado en el cajón como la reliquia de la "documentación de la primera versión", a veces ni eso, "prediseño de la primera version".


      Útil és documentar el código y hacer una wiki del proyecto si es grande.

      Útil es hacer un pequeño diagrama del flujo principal a nivel muy alto. Y eso no es UML. Son diagramas y bolitas.

      No conozco a nadie que lleve trabajando varios años que se conozca todas las reglas inútiles de UML que sólo sirven en el mundo académico para aprovar.

      UML repito, no son los diagramas y bolitas que muchos hacemos y seguimos haciendo. Son un conjunto de normas que no se conoce ni su madre sobre como dibujar. Y por eso no se usa.

      • jrz /  hace 2 años

        Ni eso. Los consultores son funcionales que no han programado nunca y las especificaciones son una servilleta de bar

      • xizor /  hace 2 años

        el unico que me han pedido hacer fue para un documento para pedir una subvencion...

        • estebanbcn /  hace 2 años

          Podías haber dibujado una polla en UML que si os la fuesen a dar, os la hubiesen dado igual.

          Porque el que decide sobre subvenciones a veces no sabe ni si subvención lleva una "e"...

          • Arth /  hace 2 años

            Yo hacía eso :-D siempre puedes disponer el diagrama de forma que parezca cosas, aunque bueno, una polla no, sin embargo en una examen me salió un enterprise (de lado). :-D

      • ED209 /  hace 2 años

        Estas noticias sobre programación son geniales para ir anotando nicks de gente con la que nunca trabajarías. No hablo de no usar UML o patrones, sino de estas joyitas:
        - "yo no documento porque prefiero una ñapa a tiempo que algo bien hecho tarde"
        - "el que venga detrás que arree, aunque tenga que ser yo mismo en 3 meses"
        - "no te quejes, los de sistemas son peores"

        • PrincesitaPower /  hace 2 años

          Me encanta el verbo arrear aplicado al computer science!! Me pregunto como será algo parecido en inglés!! :-)

        • estebanbcn /  hace 2 años

          Eso son incompetentes y gente uqe no tiene ni idea de que programar no es "programar para ti", sino también que cualquiera puede seguir tu código si tu no estas.

          Pero esi amigo, es otra historia... ;)

          • apetor /  hace 2 años

            , #98,... Ya me gustaría veros modelar cosas como el core de un antivirus ( con hooks, código inyectado en procesos que no son vuestros, drivers engarzados en mil sitios del sistema operativo, etc. ). Sí, pondríais cajitas para aislar muchas cosas, tantas cosas que al final seria como no modelar NADA.

            :-D En fin, hay muchas realidades...

            • grails /  hace 2 años

              APIS y documentación de las mismas.

              • apetor /  hace 2 años

                ¿ Qué quieres decir ? ¿ Que te ponga esa info aquí ? Si es así espera sentado. Si te refieres a que pondrías eso en cajas, buena suerte, no. Es más, muchas cosas se "pinchan" in middle, muy in middle.

            • estebanbcn /  hace 2 años

              Amigo, esto se enseñaba en la carrera - ingenieria superior - sin UML hace ya unos añitos. Lo que pasa es que ahora si parece que si no es UML no sirve.

              • apetor /  hace 2 años

                No se si se enseñaba o no, si te refieres a software muy de bajo nivel y muy engarzado a otros módulos y tal. El caso es que modelar con estas cosas es... no se, imposible o insalvablemente artesanal. Se puede documentar y se puede plasmar con dibujos, aveces lo hacemos, pero desde luego la mayoría no es plasmable con UML.

            • ED209 /  hace 2 años

              he puesto claramente "no hablo de usar UML". A mi no me metas en el saco de los "arquitectos que pintan cajitas".

              Hablo de la gente que acepta los 3 puntos que enumero. Si no estás de acuerdo, tu nick a la lista que va.

              • apetor /  hace 2 años

                Ok, usted perdone, lapsus.

              • apetor /  hace 2 años

                en general no soy de esos tres puntos. Si bien alguna ñapa hemos hecho, más de una vez. Eso sí, no me gusta documentar ni comentar obviedades, comento lo que, en mi entorno o disciplina, tiene intríngulis para entender. Y documentar se documentan nuevos componentes o tal.

        • opositor /  hace 2 años

          para hacer las cosas bien también tienen que dejarte hacer las cosas bien. Aunque dentro de lo que cabe se intenta. Yo he dicho que no documento y realmente si documento pero lo minimo salvo que expresamente me manden la tarea de documentar por ejemplo un proyecto o un modulo de un proyecto que probablemente no haya hecho ni yo.
          Pero aquí depende mucho la manera de trabajar... Yo no trabajo con un horario de X a X, ni trabajo en una oficina con los compañeros al lado.
          En mi caso hay una documentación de las partes mas complejas que ademas hice yo, pero las que llevaron mas tiempo las hice como una tarea concreta. Luego, tenemos accesible todas las tareas que se han ido haciendo (github) con documentación dentro de lo que se hizo y porque. Y luego tenemos un código legible.

          Pero cuando hablo de documentación pienso en tener un wiki con todo detallado, no en esto. Ni en tener un código que parece código ofuscado sin ningun tipo de indicio de que hace.

          Vamos que va a ser que al final si que documento... Aunque no es bonita, y es básica.
          Los test son otra historia, porque al depender la aplicacion de muchas cosas se volvieron inmanejables y habria que dedicar mucho tiempo pero ademas aveces fallaban pòr causas externas por lo que no eran demasiado utiles. Es una gozada trabajar con ellos... pero es lo que hay.

      • alfredo_casado /  hace 2 años

        Eso que llamas "diagramas y bolitas" es un uso del UML que fowler catalogaba como "UML as Sketch" (martinfowler.com/bliki/UmlMode.html como siempre, leer a a fowler obligatorio :P), dibujos informales que pueden ayudar sobre todo para compartir en un equipo una idea de diseño, a mucha gente le ayuda verlo visualmente y no esta mal tener un lenguaje común de modelado donde sepamos que es una flecha y que es una caja, aunque sin mucho formalismo porque entonces te pierdes en los detalles y precisamente eso juega en contra de tener una visión compartida de algo simple y rápida.

        Lo que nunca ha funcionado muy bien es tratar de usar "UML as blueprint" o "UML as programming language", donde UML tiene un rol central en el desarrollo, en general las herramientas visuales de programación visual o mediante diagramas se han demostrado con los años bastante ineficientes y engorrosas y hoy en día poca gente se plantea su uso, los más viejunos podemos recordar como estas herramientas se supone que iban a ser la panacea a finales de los 90 principios de los 2000 y al final como tantas cosas en software la cosa quedo en agua de borrajas.

        • estebanbcn /  hace 2 años

          Si, porque listos los de UML, cuando lo diseñaron, dijeron "coño, vamos a llamar todo lo que esta dibujado con diagramas y bolitas "UML as Sketch", y nos quedamos tan anchos".

          Es una forma de decir mira, mi forma de programacion es Patatin, todo lo que no sea mi forma de programacion es "Patatin as Sketch".

          Olé.

          • alfredo_casado /  hace 2 años

            Es una forma de catalogar un uso real que se hace de UML en la industria, y fowler lo que hace es simplemente reflejar esa realidad ponerle un nombre y ayudarnos a todos a entender las motivaciones de la gente que usa las cosas de una determinada forma. Y Fowler, creeme, sabe de lo que habla. Leete el articulo.

            • estebanbcn /  hace 2 años

              ok, I beleave you :hug:

        • Arth /  hace 2 años

          Quizás de forma más general, y no solo aplicado a UML, a veces se olvida que un buen profesional sabe la diferencia entre cuando debe saltarse las "normas" y cuando debe aprovecharlas. Al final todo es un compromiso entre lo que ganas y lo que pierdes, un diagrama muy general puede ayudar a entender fácilmente cuál es la idea detrás de un módulo.

          Una de las primeras cosas contra las que te advierten al estudiar programación son las variables globales y los goto. Es una regla del pulgar válida, pero que cuando seas profesional tendrás que valorar donde te conviene saltártela.

      • usuario.poco.conocido /  hace 2 años

        Iba a escribir más o menos lo mismo.

        En algo menos de experiencia (unos 9 a;os), tras acabar la carrera solo he usado las herramientas UML porque los dibujitos predefinidos de UML son más cómodos de usar que las herramientas genéricas, pero el estándar no lo he usado nunca.

Ofertas

Loader noticialalminuto

Volver arriba

Esta web utiliza cookies, puedes ver nuestra política de cookies, aquí Si continuas navegando estás aceptándola