Respostas
Resposta:
A minha ideia pessoal, é que UML não vale a pena. Já sei… documentação! Mas, mais vale um texto bem descritivo que explique os conceitos, do que um UML, que sinceramente, serve para perder tempo. É a minha ideia.
Em tempos, uma empresa para a qual trabalhei durante muito tempo, usava um software de UML; a certa altura, nem sei bem porque motivo, mas a verdade é que deixaram de usar. Nunca ninguém quis saber o motivo de deixar, ou sequer voltou a perguntar o que se perdeu. Portanto, para mim, a resposta à "lean", é "se não se usa, é porque não é necessário".
Agora, aprender "design patterns". Sinceramente, se não as aprendeu na escola, devia. Se não foi à escola, devia. Há coisas que só se aprendem com quem sabe, e aprender "design patterns" é uma dessas coisas: devemos aprender com quem sabe, aprender quando usar, o que usar e como usar. É um pouco como saber quais as ferramentas que tem à sua disposição: saber que existe um martelo e quando o deve usar; saber que existe um alicate e quando o deve usar; saber que existe um serrote, e quando o deve usar; saber quando não deve usar um deles é igualmente importante.
Vi vários colegas na escola que aprendiam os conceitos, mas não os sabiam aplicar, por exemplo, na programação orientada por objectos. É que uma coisa é conhecer os conceitos, outra, bem diferente é saber quando e como os deve usar.
Por isso, saber "design patterns", faz parte do processo de aprendizagem de programação, e de como atacar e resolver problemas. Pode até saber muitas técnicas, mas se não souber tirar partido dessas técnicas, dessas ferramentas, é como a aquela pessoa que "sabe as letras", mas lê um texto e não o compreende: é um analfabeto funcional. Um programador também pode ser assim, se souber os conceitos, mas não os souber aplicar na vida real.
Portanto, mais ainda do que saber "design patterns", convém saber como é que essas ferramentas podem e devem ser usadas.
Explicação:
Espero que tenha ajudado