Just started their video and wanted to comment on the "don't focus on the lines of code, focus on the decision making behind it" absolutely love it, that is what I've been missing from all these UA-cam tutorials, I could care less about what actual code I should enter, I can figure that out with documentation, but the actual logic and decision making behind developing is what I need the most help with. Think I'm going to enjoy a lot of your videos
I love that you're publishing intermediate content in the context of Unity. There is very little such content available, and most YTers seem to avoid it (doesn't get the views or likes they want).
insert *shallow, overly optimistic, obnoxiously narrated video on simple functionality designed to get the views of noob users and send them in a downward spiral of pain the more unity they learn* video here
The thing is, these concepts are fairly simple and basic when you come to game development from software development. The issue is people assume the 2 can be mutually exclusive. In reality, you can't and shouldn't attempt to make a game without having proper engineering skills OR good engineers to support you. It gets worse, because working with an engine is inherently limitting. You are bound by the rules and whims of the engine and your software architecture is limitted due to that. It requires even more practical experience and theoretical knowledge to find the best practices in the specific context you are thrown into.
@@Rev3rence I recently found a community that has a bunch of hobbyists making games and put myself out there to join some games in progress, and the projects I've looked at that are already partly through are full of code that reads like tutorial code. Some of them are big enough that I have no idea how the project even starts up. I had to tell a couple of teams that their project wasn't right for me because unpacking that code or trying to add features to it was brutal. It is crazy how much actually learning computer science changes the way you think about this kind of stuff.
I've watched this video 3 different times, each time coming back to this more senior and able to understand more. I remember somehow watching this and feeling overwhelmed at how "complicated" this was, and I feel good knowing how much I've grown as a developer that this video seems basically like common sense now.
I love the presentation, easy to understand examples, great narration and that every video provides a goal to achieve on your own that improves your overall skillset and knowledge. Can't wait for more videos! Keep up the great work Jason!
This might be the greatest software design and architecture resource I've come across in my 10 years of software development. I wish every new developer knew about it and studied what you are saying in detail.
Oh man, I’ve been teaching this for ages! And it seems that the younger the developers become the less they know and understand the use of software architecture. Your examples here were well chosen; simple quick and understandable. I think I will use the logging example from now on too. It’s easy to relate too. There’s a saying: “any problem in CS can be somber by an extra layer of abstraction”. And that’s true, but it’s walking a fine line with over abstraction and under abstraction. I try to teach developers, to initially don’t worry too much with abstraction unless it’s obvious (like logging, configuration and M/V/C etc). But as soon as you see you start to duplicate, take the time then and there to refactor. Because now it’s still easy and has little impact. But it just doesn’t sink in to the minds of the 25/35 year olds in most cases. They haven’t developed on low level languages (assembly and C) where this sort of duplication makes it impossible to maintain.
Man I just started trying to make games/learn to code (I know it's a trope at this point) but wow I have a long ways to go to understand all of what you wrote, excited for the journey though
@@dinkle9664 I think you may have a good point here. All those channels that “help” people land their 6 figure salary. So it’s probably more about the salary and the job than actually being an engineer and loving the job. I think you may be right!
1000% the first point. When trying to discuss architecture with someone and they ask 'why do I need to change it if it works' they're totally missing the point xD it's not about it working or not, it's about designing it in a way that's more scaleable, reads better to the human eye, shareable, etc.
Amazing content! Jason and Tarodev are by far my favorite game dev channels now, short, accurate, and straight to the point! Jason can you cover dependency injection in the future please ?
I am a completed noob with C# and playing with Unity and this made awesome perfect sense ! I think I need to read a few more books on fundamental principles like this video explained :) thank you my dude.
I really appreciate this video, I had read over the solid principles a few months ago and mostly didn't understand them, but this video made them much more clear to me. Thank you!
As a software developer since 1998, I can assure you that software architecture is the FIRST thing you should plan at the most basic level. You need to build a architecture design that allows all the fundamental object oriented principles and is easy to expand. It's the difference between taking a week to write a system, and taking an hour. The difference is that dramatic.
Hey Jason. I just want to really thank you for pointing me towards Uncle Bob. I've now been listening to him for 8 hours - and the stuff he preaches is SO important and valuable. This will change my way of coding for ever! Thank you. :)
I love the simplicity of your example and how you explain not just what to do, but why it's a good practice. Looking at the rest of the code, I could also see pulling out the code to compute the HitInfo from the mouse position as a separate concern.
With so many moving parts in a project, it is so easy to miss the forest for the trees. This is a very nice video. I look forward to seeing more from you in the future!
Was actually looking for some interesting videos about Addressables, but the title was teasing be about other interesting topics I have thought about before. So I think I will stick around for a while.
Great video, using console logs as an example was a great idea, it's something even beginners can understand. Looking forward to seeing "Unity is too slow part 2" 👀! Also, loved the colabs.
Thx 4 your time, bro. Awesome explanation. As Jason pointed out, do not look at the code. In particular, if you try to extend with a function that triggers Debug.Log, when there is a message in the console and double-click it, it will not take you to the message but to the function. So it is not helpful, and there isn't a way around that. We love your channel!
Thanks again Jason, You are a great teacher. I am looking forward to more videos as your channel grows. Ill be sure to keep watching them. So valuable!
You got a great point with change. The solid principles for example also make it possible to unit test your code and also make bug searching less painful. If you have certain classes with specific responsibilities than searching a bug is way easier. More important if there is a slight risk that you created a bug and another team member has to fix it (vacation whatever). With e.g. single responsibility in place, the new team member should be able to narrow the possible buggy classes down significantly. TL;DR Great Video Ty!
Great video, but I with it was longer. There are tons of resources for how to do single things in Unity with C#, but I’m struggling to understand how and when to implement them. Nobody seems to ever start the video explaining WHY you would do a certain thing. This discussion on architecture was a great start. I’d love to see the architecture of a developed game. What’s in their hierarchy? How are their files organized? How often and when are different principals used (state machines, statics and singletons, event systems, and other patterns). Great work. Keep it up.
For me, architecture is deciding boundaries and what should be coupled and what should not. In turn, change is confined to one area of the system as it's interactions are through defined boundaries. Also, I felt your example of Open/Close wasn't an extension, it was a change. Extension would be where you have 3 different types of logger (eg console, file or web service) and you want to add a 4 logger (eg Windows Event). Open/Close is where you can add a new logger without having to change the existing ones, usually through interface abstraction. Completely agree about SOLID still being valid. Like DRY, YAGNI and the gang of four, they're all just tools. Much of the SOLID hate comes from untyped languages, where those tools are less appropriate. Really enjoyed your Fowler refactor video.
This is a very well crafted video!! Perfect example, and the concepts are explained very clearly. Something this video highlights, without acknowledging it, is that the architecture of a project has to change and be redefined as the needs of the project change. Deciding which aspects of your code are changeable involves anticipating future design changes, which can be a tricky and sometimes harmful task. By its nature, writing code is the act of creating explicit structure that limits changes in some areas and allows it in others. As such, it's counterproductive to set out creating a program that will be changeable in every area. Of course this isnt to say you shouldn't anticipate future changes. Just that it's important to make sure you're doing so intentionally. There isn't a one size fits all "best way to start a unity coding project so that you wont have to do lots of refactoring in the future". Internalizing that took me a while when I started out.
Oh, this is a brilliant level of content! And my words are not just for being loud. As experienced in web, i've been looking for videos that would help me to switch into gamedev. Well, I found that in terms of basic principles and architecture the most of videos are weak. But, in opposite, this video is completely coherence with fundamentals that I rely on. At first - no afraid of "additional code and abstractions". At second, it says about code for game not talking about game itself, but exactly about architecture. So, I'm excited to keep watching the channel!
Great video. SOLID is definitely a great principle to follow when developing code (at least just the first two, the last three are more catered towards object oriented style languages with the use of interfaces and abstractions).
You forgot that functional programming basicly starts at the "open for extension, closed for modification" philosophie ^^ So basicly (if you ignore the three basic rules in the video) all you do is simple basic scripting but not realy programming (as in you think of the future change consequences) ;)
Nice video, actually touching upon important stuff. However architecture is more than just "change". I recommend watching "Where Does Bad Code Come From?". Instead of only "change" there are many more things that are important: - Write - architecture should help you write code faster - Argue - architecture should make it easier and reduce time programmers must argue about code - Read - architecture should make it easier to read code - Modify - architecture should make it easier to change things (this is the part mentioned in this video) - Execute - architecture should make code execution better (faster, easier, depends on context) - Debug - architecture should make it easier to debug bugs
While the concept is kinda unrelated to Unity, there is great value in discussing things like this. A prime example of something that would differentiate a Senior from a Junior, as i often see Juniors make these kinds of poor design choices that lead to unreadable and unmaintainable code later on.
A proper logger can adjust its loglevel. So if you added a lot of debug logs, you can set it to a higher level (e.g. info) then it will not write debug logs. But info, warn or error logs
Awesome Jason, thank you for this kind of videos. You are so unique. Also, to point something about Single Responsibility Principle, Robert Martin also says -A module should be responsible to one, and only one, actor-. So, if some behavior of your application is used by two different actors, you should keep it separate to avoid defects. Your example is perfect, I would love more examples using different point of views.
This video pops in my recommendation and I watched it the second time completely. Good work Jason! SOLID death seems very funny to me. even the S of the SOLID has much impact on the overall of your coding architecture decsion.
Fantastic video! I believe people talk about death of SOLID or many other architecture/good code related subjects because we are facing massive decrease in quality of developers on the market. Programming is very lucrative job and unfortunately that means it attracts a lot of people that do not want to become better, don't want to learn good coding practices, design patterns, principles and so on. I love the video you created because it proves, in simple, well understandable matter, that those things are important and we cannot just do not care about them. I mean we can... but it all comes at a price.
I wonder why would people even think that SOLID is dead... software engineering is about engineering the software not using the hammer for everything including screws. SOLID principles cannot be applied in embedded engineering or very high performance computing/distributed computing for example, you wouldn't even dare to write code in the way you do write enterprise applications and vice versa. It would be living hell to write enterprise applications using embedded software patterns, etc... For every tool there is a purpose and designated use case for it and good engineer realizes what works best for each situation/application Thanks for sharing this, really great video :D
Thank you for the information you put out, being only a couple months into this new hobby your voice is one I listen to a great deal (as are a fair few of the other commentators here which I find interesting.) Also I think the new skills in video editing are noticable.
I get that response a lot as well, like people start to up-front worry about a bunch of tiny classes everywhere and use that as an excuse to not modularize giant 1000 line classes, which is not a good reason at all. Maybe instead that giant 1000 line class could be 5 smaller classes that don't depend on each other and read better, and have 1 overall responsibility, who knows.
Jason, you are absolutely brilliant. PLEASE consider making long form refactoring videos like you used to at Infallible Code; your insights are so helpful.
Great video, the point about while writing code keep change in mind is cool. But there is a problem with Unity's logger, when you double click your logs from Console window it only trace back to the actual "Debug.Log" call(which is in Logger class in this case). If you are using an external logger class, you have to find the line that you used your own debug class by yourself. I tried to write my own DebugEditorOnly class once, and disability to trace back was very frustrating.
SuperObjectiveLookInside(the)Development. Let me throw a bunch of flowers onto the starship board where you stand to deliver us such practical and entertaining content.
Awesome video
Sir, why aren't you verified?
i am so glad you made him make a channel, such a good video
Love you man...
I Hope you learnt something.
another amazing master is here@@Ahatcho21
Beautiful scene, interesting code visuals, funny memes and _solid_ information. Well done Jason, it's about time you released a damn video!
Not to mention a powerful cameo
Solid I see whtchy did there
I have the same opinion, awesome video!
As always, you introduce me to new concepts that I wish I knew more about! Awesome work and explanation, Jason! Keep the vids coming ✨
Just started their video and wanted to comment on the "don't focus on the lines of code, focus on the decision making behind it" absolutely love it, that is what I've been missing from all these UA-cam tutorials, I could care less about what actual code I should enter, I can figure that out with documentation, but the actual logic and decision making behind developing is what I need the most help with. Think I'm going to enjoy a lot of your videos
Okay, we get it... you're good at what we need to get better at.
More videos, thanks!
I love that you're publishing intermediate content in the context of Unity. There is very little such content available, and most YTers seem to avoid it (doesn't get the views or likes they want).
insert *shallow, overly optimistic, obnoxiously narrated video on simple functionality designed to get the views of noob users and send them in a downward spiral of pain the more unity they learn* video here
The thing is, these concepts are fairly simple and basic when you come to game development from software development. The issue is people assume the 2 can be mutually exclusive. In reality, you can't and shouldn't attempt to make a game without having proper engineering skills OR good engineers to support you. It gets worse, because working with an engine is inherently limitting. You are bound by the rules and whims of the engine and your software architecture is limitted due to that. It requires even more practical experience and theoretical knowledge to find the best practices in the specific context you are thrown into.
@@Rev3rence I recently found a community that has a bunch of hobbyists making games and put myself out there to join some games in progress, and the projects I've looked at that are already partly through are full of code that reads like tutorial code. Some of them are big enough that I have no idea how the project even starts up. I had to tell a couple of teams that their project wasn't right for me because unpacking that code or trying to add features to it was brutal. It is crazy how much actually learning computer science changes the way you think about this kind of stuff.
I've watched this video 3 different times, each time coming back to this more senior and able to understand more.
I remember somehow watching this and feeling overwhelmed at how "complicated" this was, and I feel good knowing how much I've grown as a developer that this video seems basically like common sense now.
relatable af
Don't focus on the lines of code, focus on the decision making behind it. Love it!
I love the presentation, easy to understand examples, great narration and that every video provides a goal to achieve on your own that improves your overall skillset and knowledge. Can't wait for more videos! Keep up the great work Jason!
This might be the greatest software design and architecture resource I've come across in my 10 years of software development. I wish every new developer knew about it and studied what you are saying in detail.
Good video.
You aren't done when your code works, you are done when your code is right.
I know it takes a lot of effort but please keep making more videos, it's hard to find mid or above level stuff with good explanation. Thanks.
Oh man, I’ve been teaching this for ages! And it seems that the younger the developers become the less they know and understand the use of software architecture. Your examples here were well chosen; simple quick and understandable. I think I will use the logging example from now on too. It’s easy to relate too.
There’s a saying: “any problem in CS can be somber by an extra layer of abstraction”.
And that’s true, but it’s walking a fine line with over abstraction and under abstraction. I try to teach developers, to initially don’t worry too much with abstraction unless it’s obvious (like logging, configuration and M/V/C etc). But as soon as you see you start to duplicate, take the time then and there to refactor. Because now it’s still easy and has little impact.
But it just doesn’t sink in to the minds of the 25/35 year olds in most cases.
They haven’t developed on low level languages (assembly and C) where this sort of duplication makes it impossible to maintain.
Man I just started trying to make games/learn to code (I know it's a trope at this point) but wow I have a long ways to go to understand all of what you wrote, excited for the journey though
I think that programming used to be a passion and is now just another career path. Some people want to just "get the job done."
@@dinkle9664 I think you may have a good point here. All those channels that “help” people land their 6 figure salary. So it’s probably more about the salary and the job than actually being an engineer and loving the job. I think you may be right!
Memes and edits are kinda distracting, to be honest.
But your videos are always very informative! ty
cant remember commenting but watch this video 3 times.. these last two were just because you did it so well...kudos to you my bro!
This is one of the most useful videos on the internet. Following exactly this solves soo many problems.
Really useful video I just wish it was longer with even more examples, please make more videos expanding on this topic.
This is the best tutorial on this subject. The distinct separation of the architectural changes from the feature changes was very insightful.
Excellent video, love the way you demonstrated how change happens on projects
1000% the first point. When trying to discuss architecture with someone and they ask 'why do I need to change it if it works' they're totally missing the point xD it's not about it working or not, it's about designing it in a way that's more scaleable, reads better to the human eye, shareable, etc.
thank you, i have struggled understanding the 'why' behind it and you described it easily in 7 mins.
Amazing content!
Jason and Tarodev are by far my favorite game dev channels now, short, accurate, and straight to the point!
Jason can you cover dependency injection in the future please ?
I am a completed noob with C# and playing with Unity and this made awesome perfect sense !
I think I need to read a few more books on fundamental principles like this video explained :) thank you my dude.
I really appreciate this video, I had read over the solid principles a few months ago and mostly didn't understand them, but this video made them much more clear to me. Thank you!
As a software developer since 1998, I can assure you that software architecture is the FIRST thing you should plan at the most basic level.
You need to build a architecture design that allows all the fundamental object oriented principles and is easy to expand.
It's the difference between taking a week to write a system, and taking an hour. The difference is that dramatic.
Hey Jason. I just want to really thank you for pointing me towards Uncle Bob. I've now been listening to him for 8 hours - and the stuff he preaches is SO important and valuable. This will change my way of coding for ever! Thank you. :)
i want to say something nice but im terrible with words, I really like this.
I love the simplicity of your example and how you explain not just what to do, but why it's a good practice.
Looking at the rest of the code, I could also see pulling out the code to compute the HitInfo from the mouse position as a separate concern.
Excellent advice and example
This is a great simple video on how to take the "white paper" ideas and turn them into real world examples. Thank you.
precious stuff here! mindchanging ! i'm rewriting all my code with this philosophy and i'm happy with it! thx!!!!
i had a big brain Unlocking process while watching this video Really made me rethink how to handle things entirely not just Debuggin thankss a lot
It is absolutely phenomenal explanation of SOLID and Software Architecture. You did well. Thank you.
With so many moving parts in a project, it is so easy to miss the forest for the trees. This is a very nice video. I look forward to seeing more from you in the future!
Was actually looking for some interesting videos about Addressables, but the title was teasing be about other interesting topics I have thought about before. So I think I will stick around for a while.
Agree with everything except Logger being monobehavior. Good stuff 👍
I appreciate how thoughtfully worded you made this tutorial. Thanks for sharing!
Been wanting software architecture/organization in a unity context for years!
Brooo all of my favorite unity content creators are here in the comments. This is some next level stuff here.
Clarification absolutely needed. Thank you so much.
It's getting better and better
Great video, using console logs as an example was a great idea, it's something even beginners can understand. Looking forward to seeing "Unity is too slow part 2" 👀! Also, loved the colabs.
i'm intrigued by the way you structure your scene, it would be interesting to see a video on how you set it up and the reasons behind it.
Thanks for the video! I have been working quite a while on improving the workflow of code development and teamwork. This video definitely helps!
Thx 4 your time, bro. Awesome explanation. As Jason pointed out, do not look at the code. In particular, if you try to extend with a function that triggers Debug.Log, when there is a message in the console and double-click it, it will not take you to the message but to the function. So it is not helpful, and there isn't a way around that. We love your channel!
Great video, it's more rare to find videos about this topic than just another language feature. Keep up the good work!
Thanks again Jason, You are a great teacher. I am looking forward to more videos as your channel grows. Ill be sure to keep watching them. So valuable!
Okay, we get it... you're good at what we need to get better at.
這麽棒的影片我居然才看到……非常有用的思路。Thank you for sharing
Damn glad i found this video in the UA-cam archives.
You got a great point with change. The solid principles for example also make it possible to unit test your code and also make bug searching less painful. If you have certain classes with specific responsibilities than searching a bug is way easier. More important if there is a slight risk that you created a bug and another team member has to fix it (vacation whatever). With e.g. single responsibility in place, the new team member should be able to narrow the possible buggy classes down significantly.
TL;DR Great Video Ty!
Great video, but I with it was longer. There are tons of resources for how to do single things in Unity with C#, but I’m struggling to understand how and when to implement them. Nobody seems to ever start the video explaining WHY you would do a certain thing. This discussion on architecture was a great start. I’d love to see the architecture of a developed game. What’s in their hierarchy? How are their files organized? How often and when are different principals used (state machines, statics and singletons, event systems, and other patterns). Great work. Keep it up.
For me, architecture is deciding boundaries and what should be coupled and what should not. In turn, change is confined to one area of the system as it's interactions are through defined boundaries.
Also, I felt your example of Open/Close wasn't an extension, it was a change. Extension would be where you have 3 different types of logger (eg console, file or web service) and you want to add a 4 logger (eg Windows Event). Open/Close is where you can add a new logger without having to change the existing ones, usually through interface abstraction.
Completely agree about SOLID still being valid. Like DRY, YAGNI and the gang of four, they're all just tools. Much of the SOLID hate comes from untyped languages, where those tools are less appropriate.
Really enjoyed your Fowler refactor video.
This is a very well crafted video!! Perfect example, and the concepts are explained very clearly. Something this video highlights, without acknowledging it, is that the architecture of a project has to change and be redefined as the needs of the project change.
Deciding which aspects of your code are changeable involves anticipating future design changes, which can be a tricky and sometimes harmful task. By its nature, writing code is the act of creating explicit structure that limits changes in some areas and allows it in others. As such, it's counterproductive to set out creating a program that will be changeable in every area.
Of course this isnt to say you shouldn't anticipate future changes. Just that it's important to make sure you're doing so intentionally. There isn't a one size fits all "best way to start a unity coding project so that you wont have to do lots of refactoring in the future". Internalizing that took me a while when I started out.
To be clear, I don't expect this stuff to be discussed in this video. This is out of scope for the target audience and length of the video.
Oh, this is a brilliant level of content!
And my words are not just for being loud. As experienced in web, i've been looking for videos that would help me to switch into gamedev. Well, I found that in terms of basic principles and architecture the most of videos are weak. But, in opposite, this video is completely coherence with fundamentals that I rely on. At first - no afraid of "additional code and abstractions". At second, it says about code for game not talking about game itself, but exactly about architecture. So, I'm excited to keep watching the channel!
Great video. SOLID is definitely a great principle to follow when developing code (at least just the first two, the last three are more catered towards object oriented style languages with the use of interfaces and abstractions).
You forgot that functional programming basicly starts at the "open for extension, closed for modification" philosophie ^^
So basicly (if you ignore the three basic rules in the video) all you do is simple basic scripting but not realy programming (as in you think of the future change consequences) ;)
He only mentioned the first two principles in the video though?
Your page is amazing! I scour for these higher level thinking concepts!
Amazing video. One thing to note whilst doing this : You can *easily* go to far in this.
Nice video, actually touching upon important stuff. However architecture is more than just "change". I recommend watching "Where Does Bad Code Come From?".
Instead of only "change" there are many more things that are important:
- Write - architecture should help you write code faster
- Argue - architecture should make it easier and reduce time programmers must argue about code
- Read - architecture should make it easier to read code
- Modify - architecture should make it easier to change things (this is the part mentioned in this video)
- Execute - architecture should make code execution better (faster, easier, depends on context)
- Debug - architecture should make it easier to debug bugs
While the concept is kinda unrelated to Unity, there is great value in discussing things like this. A prime example of something that would differentiate a Senior from a Junior, as i often see Juniors make these kinds of poor design choices that lead to unreadable and unmaintainable code later on.
sheesh how am I just discovering this channel?! Dat quality
A proper logger can adjust its loglevel. So if you added a lot of debug logs, you can set it to a higher level (e.g. info) then it will not write debug logs. But info, warn or error logs
Please continue this kind of contents!! I love it! Thank you!
Great video Jason, just looking at your uploads and it seems you've stopped. Would love to see more of your stuff
wow that was eye opening! especially the Log() method - thanks!
Awesome Jason, thank you for this kind of videos. You are so unique. Also, to point something about Single Responsibility Principle, Robert Martin also says -A module should be responsible to one, and only one, actor-. So, if some behavior of your application is used by two different actors, you should keep it separate to avoid defects. Your example is perfect, I would love more examples using different point of views.
I feel like i found a legendary item that i want for years while watching this video.
The skype call was *genius!* Would love to see more people be brave and craft some unusual audio design! Thank you :)
This video pops in my recommendation and I watched it the second time completely. Good work Jason! SOLID death seems very funny to me. even the S of the SOLID has much impact on the overall of your coding architecture decsion.
Good to see video featuring Tarodev!!!
Incredibly informative as always
Please do more of these! Great info and made me realize I need a lot more architecture training!
Going more in depth on solid is probably a great start for more video topics. Each principle could surely use its own explanation and unity example?
I need more videos like this one. Very effective examples and to the point!
Fantastic video! I believe people talk about death of SOLID or many other architecture/good code related subjects because we are facing massive decrease in quality of developers on the market. Programming is very lucrative job and unfortunately that means it attracts a lot of people that do not want to become better, don't want to learn good coding practices, design patterns, principles and so on. I love the video you created because it proves, in simple, well understandable matter, that those things are important and we cannot just do not care about them. I mean we can... but it all comes at a price.
Your videos are just .. Wow! Pls keep'em coming
This practical example really helped! Great video, thank you :)
Great video, love how you use simple understandable examples.
Your content is fantastic because is clear and concise. Glad to be your follower Jason,
I'm glad search & replace text exist.
dude . you are the best. i love the passion you put into you editing and the learning experience is just on another level.
Absolutely beautiful solutions Jason. Thank you for these tips. You are a gem
I wonder why would people even think that SOLID is dead... software engineering is about engineering the software not using the hammer for everything including screws. SOLID principles cannot be applied in embedded engineering or very high performance computing/distributed computing for example, you wouldn't even dare to write code in the way you do write enterprise applications and vice versa. It would be living hell to write enterprise applications using embedded software patterns, etc...
For every tool there is a purpose and designated use case for it and good engineer realizes what works best for each situation/application
Thanks for sharing this, really great video :D
Great stuff, really loving these videos. Looking forward to the next one.
Thank you for the information you put out, being only a couple months into this new hobby your voice is one I listen to a great deal (as are a fair few of the other commentators here which I find interesting.)
Also I think the new skills in video editing are noticable.
I felt like all that needed to be said!
Looking forward to the next one :)
I get that response a lot as well, like people start to up-front worry about a bunch of tiny classes everywhere and use that as an excuse to not modularize giant 1000 line classes, which is not a good reason at all. Maybe instead that giant 1000 line class could be 5 smaller classes that don't depend on each other and read better, and have 1 overall responsibility, who knows.
Subbed. Thank you for being so insightful and straightforward.
I don't really understand code but I understood the video, very good video thanks!
Jason, you are absolutely brilliant. PLEASE consider making long form refactoring videos like you used to at Infallible Code; your insights are so helpful.
This was a fantastic explanation
Very important video and perfect example👍
Thanks for your honest review not like others trying make my life more diffuuucxxlt !
I love the editing in this one Jason! Well produced! Also awesome content!
Great video Jason! Can't wait to see more 👏
Short and sweet :) waiting for more new videos! thanks
Awesome video!, so much quality
Great video, the point about while writing code keep change in mind is cool. But there is a problem with Unity's logger, when you double click your logs from Console window it only trace back to the actual "Debug.Log" call(which is in Logger class in this case). If you are using an external logger class, you have to find the line that you used your own debug class by yourself. I tried to write my own DebugEditorOnly class once, and disability to trace back was very frustrating.
Great work with this video! Simple and easy to understand
SuperObjectiveLookInside(the)Development. Let me throw a bunch of flowers onto the starship board where you stand to deliver us such practical and entertaining content.
Great content man, your points made me better in such a short time.