Today in UML class our teacher told us that it is very important to create uml diagram of our java code and use design pattern before starting to program any application.
I find that weird because usually I just start write programs directly I don't design uml for my code because I don't know what I will use in it.It can be new library so I don't know full dependencies I will use.
Where I work, diagramming is done before, during, and after we build the product.
Diagrams created before are used to discuss possible dependencies with other teams (which need to be coordinated as early as possible), the high-level systems we need to build (UI, Service, API, etc), and the user features each component fulfills.
These are built so that the team is on the same page, and can talk with other teams about what will be built, at a high level.
During development, we'll build diagrams when we need to discuss how lower level components interact, how over time components will talk to each other, and different contracts that exist (between UI, service, database, etc).
These are usually built so that the team can understand and talk amongst themselves how the system is evolving, and notice changes from the original design. They are made AS-NEEDED, when the team needs to discuss a complex problem or novel system.
These are usually the least useful. These diagrams are done for documentation purposes and help future teams understand how the system works as it stands today. They are not as valuable because, at this point, the team already has built the system. Even in the face of a major refactoring, the code will be more detailed and nuanced than most diagrams.
The diagrams built as you are developing the system will always be the most valuable because that is where you will see flaws, potential improvements, and have real discussions on what the system should look like.
That being said, it is completely possible in languages like Java to do almost all of your object-oriented design up front. Class diagrams lend themselves to this, and building diagrams first can help you practice talking about your system, before you build them out (something very common in whiteboard interviews).
NB. Design patterns should not be "used", they are emergent. When you notice something you are doing looks like a design pattern (more often than not in a diagram) you can start talking about concerns that are associated with them. Pre-emptively introducing a design pattern is a recipe for bad design.
