I like the way you put that. Essentially the same, except emphasis on default to do it the way you feel like, but apply the conventional rules when they make life simpler. Don't have to feel guilty breaking a rule here or there.
The problem with leaning this way is that you are then justifying why you should use each rule rather than justifying why you should not. Best practices are designed to be the right thing to do generally in the situations they are designed for. For instance, DRY is always a best practice. That doesn't mean you don't decide not to be DRY for certain circumstances, but it should be your default. CQRS, on the other hand, only applies to very specific circumstances where a large and complicated data system will be put into place. In that case, there still might be times that you don't use CQRS, but you should evaluate why not. You would not need to evaluate why not, though, when building a small to medium sized CRUD app, since that's not a good fit for CQRS.
@@IAmTimCorey good point. Also, thanks for having the time to check our comments and replying. I am just learning C# and your videos are a huge help. Thanks for all you do for us, and that it's free. Hugely appreciated!!!
I would add to what Tim said that in team settings, it’s really nice to have a shared set of default rules that everyone uses, but obviously there needs to be the freedom to make non-standard choices on a case-by-case basis
I was against breaking the rules until I realized I am breaking rules too. For instance, in my own project, all my Web API 2.0 endpoints are POSTs. Why? Because it makes my life easier. I dont have to think about when an endpoint should be post or put. But, one problem with deciding when to break which rule while working in a team is the stubbornness of a developer. Developers always think they are right so when 2 developers have a different opinion in when breaking a rule or not, it will create a difficult time on the job. 😂
The "it depends" did not escape. 🤣🤣🤣🤣🤣🤣 I have a side project in which I had to use clean architecture. the MVP is not so powerful, but the coming features are just many. It is harder now, but upgrades will become easier. and testing is easier. you are right, it depends
The "it depends" is one of the firmest rules I know of. If you think that "it depends" is not accurate for a general situation and there is one right answer, you are probably wrong.
I remember opening huge Classic ASP files lol.. also includes nested files as well in there. Pretty difficult to maintain. Now Blazor is much easier to maintain unless there are many layers like Tim is talking about. Thanks for all of your great videos Tim 😊
I think the opening answer is such a great metaphor for how .NET think. That was such a verbose and over complicated answer for “it depends “ just say “it depends” much clearer simply and articulates the point the same.
@IAmTimCorey ...except when doing a job interview takeaway assignment. There you have to demonstrate your understanding of at least one architectural pattern, regardless of the size of the project. What do you think?
It depends (of course). If you think that is what they are looking for then definitely give that to them. However, if you think that they are looking for you to make wise choices about how you build applications then don't force one in. Maybe even document that you chose NOT to use certain patterns and why.
It is an interesting way to approach software development. I am concerned by how complex people make it, though, when the overall application should not be that complex.
My head fills with Judas Priest whenever a workflow-dogma acronym is foisted upon me. They tend to be wildly unsuited for almost anything when applied rigorously.
All rules have exceptions and best practices don't even rise to the level of rules. Developers need to be discerning about what they do and why they do it.
Накидал говнокода в один файл и норм, работает же! Зачем эти абстракции, наследование и прочая хрень? Только время тратить. Главное, чтобы работало, а то, что там потом хрен разберешься, это уже проблемы будующего меня.
The video make total sense. Congratulations for the subject.
Thanks!
How about don't follow any rules unless it makes your life easier?
I like the way you put that. Essentially the same, except emphasis on default to do it the way you feel like, but apply the conventional rules when they make life simpler. Don't have to feel guilty breaking a rule here or there.
The problem with leaning this way is that you are then justifying why you should use each rule rather than justifying why you should not. Best practices are designed to be the right thing to do generally in the situations they are designed for. For instance, DRY is always a best practice. That doesn't mean you don't decide not to be DRY for certain circumstances, but it should be your default. CQRS, on the other hand, only applies to very specific circumstances where a large and complicated data system will be put into place. In that case, there still might be times that you don't use CQRS, but you should evaluate why not. You would not need to evaluate why not, though, when building a small to medium sized CRUD app, since that's not a good fit for CQRS.
@@IAmTimCorey good point. Also, thanks for having the time to check our comments and replying. I am just learning C# and your videos are a huge help. Thanks for all you do for us, and that it's free. Hugely appreciated!!!
I would add to what Tim said that in team settings, it’s really nice to have a shared set of default rules that everyone uses, but obviously there needs to be the freedom to make non-standard choices on a case-by-case basis
Thank you, Master! That's a topic that sparks a lot of debate. Your clarification really helped me understand the 'why' behind it.
Glad it was helpful!
Just want to say thank you for all your work with your very informative content 👍 Greetings from Germany. Pascal
I am glad you find them helpful.
I was against breaking the rules until I realized I am breaking rules too. For instance, in my own project, all my Web API 2.0 endpoints are POSTs. Why? Because it makes my life easier. I dont have to think about when an endpoint should be post or put.
But, one problem with deciding when to break which rule while working in a team is the stubbornness of a developer. Developers always think they are right so when 2 developers have a different opinion in when breaking a rule or not, it will create a difficult time on the job. 😂
That's part of being a developer - figuring out how to agree upon standards.
The "it depends" did not escape. 🤣🤣🤣🤣🤣🤣
I have a side project in which I had to use clean architecture. the MVP is not so powerful, but the coming features are just many.
It is harder now, but upgrades will become easier. and testing is easier.
you are right, it depends
The "it depends" is one of the firmest rules I know of. If you think that "it depends" is not accurate for a general situation and there is one right answer, you are probably wrong.
I remember opening huge Classic ASP files lol.. also includes nested files as well in there. Pretty difficult to maintain. Now Blazor is much easier to maintain unless there are many layers like Tim is talking about. Thanks for all of your great videos Tim 😊
You are welcome.
I think the opening answer is such a great metaphor for how .NET think. That was such a verbose and over complicated answer for “it depends “ just say “it depends” much clearer simply and articulates the point the same.
I said "it depends" at 1:09. From there, I explained why. I'm not sure what else you could expect unless you wanted me to end the video there.
Thank you, Tim!
You are welcome.
@IAmTimCorey ...except when doing a job interview takeaway assignment. There you have to demonstrate your understanding of at least one architectural pattern, regardless of the size of the project. What do you think?
It depends (of course). If you think that is what they are looking for then definitely give that to them. However, if you think that they are looking for you to make wise choices about how you build applications then don't force one in. Maybe even document that you chose NOT to use certain patterns and why.
what do you think of DDD?
It is an interesting way to approach software development. I am concerned by how complex people make it, though, when the overall application should not be that complex.
My head fills with Judas Priest whenever a workflow-dogma acronym is foisted upon me. They tend to be wildly unsuited for almost anything when applied rigorously.
All rules have exceptions and best practices don't even rise to the level of rules. Developers need to be discerning about what they do and why they do it.
Накидал говнокода в один файл и норм, работает же! Зачем эти абстракции, наследование и прочая хрень? Только время тратить. Главное, чтобы работало, а то, что там потом хрен разберешься, это уже проблемы будующего меня.
There is always going to be a careful balance to maintain, which is what I talked about in this video.