Feedback "Uncle Bob" show | Good software code writing quicky | AGILE SOLID TDD |

SOLID

 

"Uncle Bob" : https://www.youtube.com/results?search_query=uncle+bob

 

Wow. He is super fun to listen to. Snarky old school engineers FTW!

 

Oh yes, I watched his presentations for a while, then he unfortunately started to give the same speech over and over. I guess you can talk about how you invented the SOLID principle and how it was an accidental naming for just so many times.

 

@Lurking-Ninja And did you watch this 7 Hs of Uncle Bob?

I like the idea that if a Higgs boson turns crazy the whole Universe structure does not fall down!
I hate to say this, but if I became crazy all the social structure will collapse.
We need to learn the clean code and correct "flow of control" to imitate somehow nature works.
Actually I'm eating and reading spaghetti code. I'm an artist what can I expect form myself!

Ignore the bad unitycoin channel that wants other and stole these videos; The quality of this presentation is better:

 

Hi! I'm Uncle Bob, and this is Clean Code
Cue guitar riff

That series is a gold mine. He can be a little preachy but he actually cares about making a point about why things happen and why we should care too.

 

I'm Latin ItaloArgentinian but that cloud be my uncle! I wish...

TDD
Test-Driven Development​

Nice: https://blogs.unity3d.com/2018/11/02/testing-test-driven-development-with-the-unity-test-runner/

Here what that it means in practice! The result of the code blows my brain and my artistic way of coding. Look at it from beginning to have a better understanding.

 

How many of us are making games via TDD? 10%?

 

@zombiegorilla @AlanMattano and whoever wants to vote in this: would you agree to modify this topic and maybe pin it if it worth the effort to a general "cool things", "connected to game development", "not directly about unity"-kind of useful video/link storage thread?

I mean I watched a couple of interesting videos/streams about interesting general topics, but obviously I don't want to mix it in if you are against it, since those aren't from UBM. On the other hand I don't want to open a separate thread either, it's just falling deep in the pages and no one reads/watch it after a day unless we post in it frequently.

(My contender would be a stream where Jonathan Blow talks about how to achieve frame-independence and all the pitfalls and stuff.)

 

Hummmm.. I do not know. But post in it frequently is like publicity or spam. Good things do not need extra help like publicity posting frequently. Need internal quality and that goodness will show off by itself.

TDD Why in 3min

TDD Demo Example

Better if you look at the video from beginning

 

Interesting video. Thank you for sharing.

 

Not a fan of solid.

If we're talking about online lectures, I found a good refresher lectures on ilecturonline, They're not programming related, but useful.

https://www.youtube.com/channel/UCiGxYawhEp4QyFcX0R60YdQ

 

I had to write a cryptography and lock workstation application outside of Unity,. I can whip C# around in Unity and write clean code and logical coherent structures. using dozens of classes/components. I ran into a wall of MicroSoft jargon trying to get the core Windows Service running. Damned VS code services template would not let me debug as I went along. It insisted i install the service and put up a huge brick wall to any progress. I was like hell no. Who thinks this crap up.?!?!! Alot of blogs and websites were the same..bunch of smartasses flinging jargon acronyms around "Do the XYZ with the ABC then DEF the HIJK using LMN while implementing OPQR". I did a search in youtube expecting to find some drooling dolt typing and using ummm to start every sentence or some Indian dude singsonging English at a million miles an hour. I pleasantly ran across this fellow Tim Corey and his C# series IAmTimCorey. Best tutorial broadcaster on YouTube IMHO. I had the Service up and running and installed inside an hour. Channel link-> https://www.youtube.com/channel/UC-ptWR16ITQyYOglXyQmpzw

 

Unless you're not doing any sort of OOP development, why's that?

 

Since we are making games, Is it because of performance?

 

Because I think that it is poorly described, benefits are dubious, and you can overdo SOLID, making your code worse.
You can't overdo KISS principle.

There are multiple practices that produce cargo cults. SOLID is one of them. Others are

* Test Driven Development.
* Dependency Injection
* AGILE.

The are articles on the web criticizing it. For example:
https://www.reddit.com/r/programming/comments/2hn91p/why_i_dont_teach_solid/

It is because I see the principle as unsound.

In my understanding a job of a programmer is to solve given problem in a minimum amount of time at a minimum cost. Where cost includes both short term maintenance cost and long-term development cost. The other job is to get high payment for that, but that's another story.

That means that you can't copy-paste things and write spaghetti that makes program now, because long-term cost of that is high (due to spaghetti being unintelligible). You also can't take your sweet time creating beautiful class hierarchies, because that drives short-term costs up (because it has to be done now, and not 6 months later). Likewise, you can't really do things like inventing your own programming dialect (inspired by ancient sumerian) on top of your current language, even if it increases your productivity, because it drives maintenance costs up, as there will be people who are not you working on that project, and you're introducing a learning curve.

That means that in the long term the focus of your codebase would be simplicity and readability. tt

KISS and YAGNI principles fit into this picture. Self-documenting code is also another attractive principle.

SOLID however.... does not fit into it quite well. In particular, one common mistake of a beginner programmer is to overuse OOP and inheritance. They'll be making class hierarchies, and said hierarchies oftne have no practical effect at problem being "solved". The principles of SOLID seems to be designed to encourage OOP overuse.

 

Right. I agree with most of the comments in that reddit post. If ideas in software architecture/engineering are treated as dogma and all-encompassing truth they should be taken with a grain of salt. That still doesn't negate the entire value of SOLID when used as rules of thumbs. One comment sums it up quite nicely in my opinion:

 

I can agree with that.

It is a tool that has application in some places. It is not a "perfect principle" that should be always followed.

I wouldn't pick SOLID as a rule of a thumb, though, but that's my opinion.

 

Yepp, agree, the Single responsibility is super-important from there, the Open-closed usually doesn't even apply (one-off software, you will change the class until someone wrings out of your hand and release your game, except if you make "public" libraries), Liskov-subtitution applies if you even use interfaces, obviously. Interface segregation is somewhat importan if we're using interfaces, and the Dependency inversion is okay, sometimes, but it is easy to implement it on the wrong way, especially in a somewhat rigid architecture like Unity scripting, not to mention it is easy to build a performance sink.
YAGNI and KISS are far (miles and miles) more important than SOLID in any Unity project.

 

https://en.wikipedia.org/wiki/List_of_software_development_philosophies

 

Much of it is good advice, although it should be considered as advice rather than rules to blindly follow.
I have mixed feelings on Dependency Inversion. In some cases, it's good. In others though, it reduces maintainability for the sake of potential expansibility, which is a questionable trade-off in many cases IMO.

A lot of coding philosophies that produce highly layered (but decoupled) code will focus on the fact that modifying the code happens many times, initially writing it only happens once, so extra work in the latter is worth it for the former, and that much is true.

IME though, what happens even more often is "fixing an issue with the code, without having the chance to thoroughly learn the codebase from the top down." Effectively, you are entering the code through the side door, with a starting point like "the error originates from FooComponent.Setup having incorrect data". At that point, you care a lot more about being able to quickly find what code paths call that method than about being able to seamlessly add a BarComponent or BazComponent using your (not yet existent) knowledge of the IComponent / IComponentProvider / ComponentDispatcher systems.

 

What is odd is that I have heard of everything on that list, and am familiar with most of them, but seeing them listed is pretty interesting. If you would have asked me how many approaches/philosophies there were, I would have said a half dozen or so off the top of my head. Kinda funny. (heh, I like that Cowboy is listed)

 

Clearly programming is not like aeronautic build up with good rules and checklist. As a beginner, I can take off. But for landing safely...Programming itself needs development.

 

Did you notice in that first video, through the first half, he makes fun of C#?: It's a copy of Java, delegates are bad versions of function pointers, interfaces are a stupid idea since multiple inheritance is easier and better.

 

Now, I have a reason not to watch the video.

 

Our studio works very much with open closed principle. If you try to honor it designs often turns out well and easy to maintain.

Also with component driven designs like unity favors its also comes very natural.

 

Can you give details? Open/Closed technically means to only change classes by writing a new subclass. A newer definition is the same, except says you can only inherit from an abstract interface -- not an actual class. A looser definition is to allow lots of plug-ins and in general write functions with more flexibility that you currently need.

I've just never seen any code or coding process where Open/Closed was a good description. You'd normally describe it some other way, but if you really wanted to call it O/C, well, sure, I guess.

 

Open/closed applies to composition over inheritance too

For example we have a handgrenade in our game. The grenade behaviour and the explosive behavior are two different components. If we want to make a smoke grenade we just replace the explosive behavior with a smoke behavior.

Even if you dont need the smoke grenade off the bat its better in my opinion to design it like this. Its more readable and cleaner. Also you might want that explosive behavior elsewhere like in our case with a C4 bomb

 

Thanks. So one field of your grenades is an abstract class like GrenadeEffect, or, since it's Unity, a Component? I feel like most people would describe that as Composition (as in "prefer composition over inheritance"). A nice, down-to-earth trick, easy to demonstrate and explain, with specific good and bad points.

Sure, sure, you could say that Composition is one example of Open/Closed. I just feel like every use of Open/Closed as a description comes down to "oh, you just mean X, why didn't you say X?"

 

Thats just what design patterns and practices are all about, giving a name to common practices

At the core open/closed principle is just a mindset that you should carry with you always.

Above grenade example for example when doing that you should ask yourself, can a grenade do more things than just explode, or can other things than grenades explode.

If you work with composition and find good boundaries between components you will find that you honor open/closed out of the box.

 

I did enjoy listening to him. I'd love to know what he was getting at with the chemistry thing, though.

 

Nowhere. He just likes to talk about space and chemistry and other unrelated stuff.

 

I looked it up -- he was speaking to the Yale School of Management (SOM in the article). That probably explains the timid-seeming audience response to his Q's (but for business majors on a programming track, they were fine). From reading Dilbert, I assume business types like lots of analogies. He looks like he reads Dilbert. And the atom thing wasn't so bad. You can think of atoms lots of ways; and you can think of C, with no formal OO features at all, as having encapsulation, interfaces, and inheritance.

 

For sure. I just assumed he intro'd with that because he was going to come back to it later, but that never happened.