Soy malo en UML (diagrama de concepción / clase), ¿eso me convierte en un mal ingeniero de software?

Answer 1

No conozco a ningún ingeniero de software que use UML. Tal vez algunos de mis compañeros de equipo lo hagan, en raras ocasiones o en privado.

Diseñar software de esta manera puede agregar mucho esfuerzo de diseño inicial. Realmente no tienes suficiente información para tomar esas decisiones por adelantado, entonces, ¿cuál es el punto de entrar en tantos detalles que esquematizan algo que va a cambiar con frecuencia?

UML también desalienta la refactorización a gran escala. ¿Algún voluntario para mantener los diagramas actualizados?

Los diagramas de generación automática son prácticamente inútiles. Es demasiada información, y rara vez necesita pensar en algo más que un modelo simplificado de una porción de la aplicación.

Me gusta dibujar cuadros con flechas que los conectan para ayudarme a visualizar partes de la aplicación. Esto no es UML, ni siquiera cerca. Apenas es un boceto de servilleta.

Aquí hay una publicación de blog que escribí describiendo un enfoque que me gusta tomar para dibujar diagramas de código: Comprensión del código mediante el dibujo de gráficos de llamadas por Ryan Cook en publicaciones

Answer 2

No creo que un solo atributo como este determine su efectividad como ‘ingeniero de software’. Algunos son mejores en la realización, otros en la conceptualización y algunos en ambos. Debes considerar la amplitud de tus habilidades para responder la pregunta.

Así como ser bueno en un aspecto de la profesión no es excelencia, ser pobre en otro aspecto no te hace malo en la profesión.

Answer 3

Si puedes dibujar como mencionó Ryan Cook, un boceto de servilleta que eres bueno, de lo contrario, es un buen comienzo pero muy necesario. La visualización de un concepto es imprescindible como es el concepto.