#Any recommendations for a good spring tutorial on youtube that uses best practices?

1 messages · Page 1 of 1 (latest)

dreamy oasis
#

Hey everyone, i hope this is the right channel for this question. I've been working with spring for a while and i understand the framework, but i would like to write more "Industry standard" code. the issue is, i'm not sure where to look for a big picture guide.

I have watched some tutorials on, e.g., error handling or how to test, but these are usually isolated in scope and take shortcuts in other areas. So, when i follow the tutorials on testing, its hard for me to know what is correct or not when i try and use my tests with the DTOs i made with, e.g. the mapstruct mapper compared to the example ones in the tutorial.

For example, im watching a tutorial on microservices right now and while it explains microservices and how to set them up the other parts like error handling or the overall DB schema look rather unprofessional.

I was wondering, before i commit to a tutorial, if you guys might know any tutorials i could follow that make a project using "best practices"? I know best practices is vague, but i just mean stuff like using stream, a global exception handler, stuff like that (assuming those are best practices). Basically a tutorial that doesnt take too many shortcuts for the sake of example.

Thanks in advance!

bleak umbraBOT
#

<@&987246841693360200> please have a look, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

#
TJ-Bot
Hey everyone, i hope this is the right channel for this question. I've been working with spring for a while and i understand the framework, but i would like to write more "Industry standard" code. the issue is, i'm not sure where to look for a big picture

I recommend checking out "Java Brains" on YouTube for Spring tutorials that focus on best practices. Their tutorials are comprehensive and cover a range of topics from basic to advanced concepts in Spring framework development.

Useful links:

- AI generated response
dreamy oasis
#

To explain a bit more, something so i can see like

"Oh, he made his DTOs like this because X Y Z, and because of this he made his tests this way, and this is why he doesnt do A B C here, etc. Rather than "Heres how to write a test with a generic example"

finite lodge
blissful aspen
#

this thread might be helpful

#

ethan explains a lot of stuff

snow mountain
#

I see where you're coming from, and I've been there. I know its enticing to look for "best practices".

I would strongly encourage you to avoid that thinking, though. Best practice thinking is harmful.

First, we have not yet reached the pinnacle of software engineering, so there's no such thing as "best". Ideally, we will keep discovering new and better practices that supersede previous ones in certain contexts.

Second, "best" for one project is almost certainly not "best" for another project. It's not quite as universal as you would expect.

Third, "practices". If you chase best practices, it might seem like you just need to collect the right set of patterns in order to have good software. This can result in overuse of patterns, and is a distraction to learning.

#

Instead, I would encourage you to learn what makes a design good in a certain situation, and bad in others. Learn to identify problems in your designs, and search for solutions for these problems. Rather than searching for solutions and trying to figure out how to apply them, regardless of whether the problem exists.

Good design I think boils down to 4 things.

  1. it works (passing unit tests is a good way to measure this)
  2. it reveals its intention (good names, hide irrelevant details, amplify important ones)
  3. it has minimal duplication (duplication of knowledge in the code)
  4. it has the fewest possible elements (delete things that aren't pulling their weight!)

These 4 elements can look differently on different project, or even between different people/cultures.

#

While there aren't "best practices" there is:

  • good hygine: simple stuff that generally pays off to keep up with, like using source control
  • bad habits: things that usually aren't a good idea, like keeping your database password on the frontend
#

Finally, be skeptical of people that say "its always good to do X" or "this is the best way to do things" or "never do it this way". Rarely, it may be good hygine/bad habits. But most often, its an opinion of A good way they have found to work in THEIR experience.

#

There are many good ways to do software. There is no single perfection or industry standard, nor would one be helpful.

#

And I guess one more footnote, its ok to make sub-optiimal choices (mistakes, if you want to call them that).
Even necessary, in order learn.

Always be thinking critically about your work and improving, and you'll do great. 🙂

versed summit
#

see this is when discord being a walled garden sucks. i don't want to have to retype that to share it on reddit

snow mountain
#

Idk why I can't remove that embed...

blissful aspen
dreamy oasis
#

Thank you guys!

dreamy oasis
dreamy oasis
dreamy oasis
# snow mountain I see where you're coming from, and I've been there. I know its enticing to look...

Thanks for the reply! I will try to apply the principles you listed I do try my best to keep good hygiene and i do find that when a decision hampers me in a project i can better adapt to it for the next project. I think I asked in part because i am applying to jobs currently and having no industry experience all i can really showcase is my Github, so the whole best practices seemed like a way to show some expertise.

#

Thank you again 🙏

snow mountain
#

I've been thinking of what I could add to make a more helpful answer, other than just "avoid best practices".

I think it would be more productive to search for common problems, and view these problems with skepticism.

Try to understand why they are (or aren't) problems. See if you can simulate the problem in your own project. Then, try common solutions that might be marketed as "best practice" and see if it helps in that situation.

Even these "common problems" can be misleading, though, since as programmers we often invent problems in order to justify our personal preferences.

Or apply a vague problem as justification for our personal preference.

Be diligent in understanding the problem first! I think that would be even more helpful in a job interview situation, to know common problems, and their potential solutions.

#

Rather than knowledge of common "solutions" and vague knowledge of the problems they intend to solve. As an interviewer, it's easy to tell someone who just googled best practices, (or picked them up on the job, without knowing why) because they can't explain the problem in depth.

#

For example, I found this article.
https://www.geeksforgeeks.org/java/top-10-most-common-spring-framework-mistakes/

Here's the bullet list, and which ones I think are actually problems

  1. Configuring Incorrectly - yes, but lacks a common solution other than "configure correctly"
  2. Using Dependency Injection Inefficiently - yes, DI is often misused or overused
  3. Mishandling Exceptions - yes, but a little too vague
  4. Version Conflicts - yes, not many common solutions other than be diligent and have automated unit/integration tests
  5. Separation of Concerns - sorta, this is too vague of a problem. Often used to justify personal preference. 4 elements of simple design can help cut through the crap.
  6. Autowiring Problem - similar to DI problem, often misused/overused
  7. Writing Duplicate Code - yes, 4 elements of simple design can help
  8. The Issue with XML Based Configuration - no, have a feeling this may not be an actual problem and just personal preference
  9. Focusing More on Low-Level Tasks - sorta, too vague, 4 elements of simple design can help.
  10. The Issue With Port - can be a minor issue, but seems like a filler to make the list 10
#

these could be a good place to start researching, to understand the vague problems with more detail.

for example, what does mishandling exceptions look like? why is (or isn't) it mishandling? what portion of that could be personal preference?

dreamy oasis
#

Absolutely amazing, thank you so much! Thank you for the insight 🙏