En utilisant UML, c'est comme de regarder vos pieds pendant que vous marchez. C'est être conscient et explicite, quelque chose que vous pouvez généralement le faire inconsciemment. Les débutants ont besoin de bien réfléchir à ce qu'ils font, mais un programmeur professionnel sait déjà ce qu'ils font. La plupart du temps, de l'écriture du code en lui-même est plus rapide et plus efficace que d'écrire sur le code, parce que leur programmation intuition est adaptée à la tâche.
Ce n'est pas seulement à propos de ce que vous faites. Que penser de la nouvelle recrue qui vient dans les six mois à partir de maintenant et les besoins à venir jusqu'à la vitesse sur le code? Qu'en cinq ans à partir de maintenant, quand tout le monde travaille actuellement sur le projet est parti?
Il est extrêmement utile d'avoir de la base à jour de la documentation disponible pour n'importe qui qui a rejoint le projet plus tard. Je ne défends pas complètes de diagrammes UML avec des noms de méthode et des paramètres (trop difficile à gérer), mais je pense qu'un schéma de base de composants dans le système avec leurs relations et le comportement de base est d'une valeur inestimable. À moins que la conception du système de change radicalement, cette information ne devrait pas changer beaucoup de choses même que la mise en œuvre est tordu.
J'ai trouvé que la clé de la documentation, c'est la modération. Personne ne va la lire 50 pages complètes de diagrammes UML avec la documentation de la conception sans s'endormir quelques pages. D'autre part, la plupart des gens aimeraient obtenir de 5 à 10 pages de simples diagrammes de classe avec une description de base de la façon dont le système est mis en place.
L'autre cas où j'ai trouvé de UML pour être utile, c'est pour quand un développeur senior est responsable de la conception d'un composant, mais alors les mains de la conception d'un développeur junior à mettre en œuvre.
