Developer, Sandy, Matt discussed on Ruby on Rails Podcast


In good health and that other developers shop affi- are empowered to follow best practices around design and architecture so kind of day to day. What that looks like. Is We do a lot of technical work and core to Kind of maintain it and improve its health but we also do work to develop tools that help developers track the health of the areas of code. They own and then we're also involved in a lot of education initiatives around software design and architecture and that's actually kind of how the blog posts came to life. We were you know doing some work to our reactor core and we thought it would be a good idea to maybe share some of what we'd learned with other people at chop off by an outside of shop by so we decided to write a blog post about. It is a whole just always seems to be so willing to share insights especially since it's such a well known Scaled out ruby on rails application. So anytime see. New Host from the shop apply blog. I get excited because I know somehow it's going to be relevant to what I do. So one thing that I wanted to dive into in the article is that you start off by explaining what a God object is. So can you explain what a God object is impossibly? Maybe an example of one that we might see in our own code basis. Yeah for sure. So a God. Object to a common anti pattern it basically describes an object that knows or does too much. But if you're like me you might start to play the WII game and get into you know why is a bad to have an object that knows or does she much and this is kind of something? I've been reflecting along a lot on lately as I've been you know diving into how we can make chop if I were a little healthier so I've been learning a lot about why these large objects are bad and some of the consequences that arise when you have large objects or objects that kind of have too many responsibilities so the first of these is that there are often overloaded with dependencies so typically if you have an object that is doing too much. It's couple to other parts of your system so that makes it harder to reuse. They're also just like really hard to work with. If you have this giant object that does a million things and you need to make some changes to it. It's going to take a lot of mental effort front for you to understand the object. You can actually go and make the change And not only is the change. Hard TO MAKE. But it's GONNA be slow to test and We've had some pretty painful experiences with slow tests shop so it's definitely a pain point And then this concept. I've been learning a lot about lately is Death Stars this is a term I think sandy mets coined Basically you have these parts of a system that are high churn high complexity. So they're hard to understand and they also need to change a lot And I don't think that got objectives necessarily synonymous with death star but I think that got objects can turn into. Death Stars a lot of the time. And that's something we've noticed chopper fi like if you have this classes overloaded with responsibility it's likely going to need to change a lot and every time it needs to change. Developer has to load all this context into their head to understand it and the changes they make or probably GonNa make it more complex so it really becomes the vicious cycle and it can really slow down developer productivity and so onto like how do we identify got objects and rails APPs I definitely think it's a bit tricky like it's not always easy to spot an object. That's too large especially because these objects don't usually start out large they kind of slowly evolve into God objects but the biggest issue I think with got objects is that they violate the single responsibility principle in software engineering which states that an object should only one reason to change so I think if you have an object that is changing for a number of different reasons while it may not be at like God object level yet. It's probably doing too much and it's at risk for becoming a God object. I think personally In my experience a good rule of thumb is to look for areas in your stem. That are painful to work with in my article. I talk about our shop model. Which definitely has a reputation in the company for being? You know this massive class. That's really painful to work with. And that requires a lot of context and mental effort to make changes to And then something else is another thing to note about got objects is there? It's difficult to define what they're responsible for. So our domain models are meant to be obstruction of reality useful for solving business. That's kind of like the typical domain driven design definition. You here So you should be able to open up the code for a rails model at any time and get an idea of the thing that model is representing the obstruction. And the problem is that I think as our business needs evolve. Our models evolve to try and keep up and sometimes the obstruction isn't quite right anymore. So for us the shop It was probably at one time clear. What a shot was and what it did but today if you open up like shop dot. Rb It's impossible to tell what it is by looking at the code which is a really big hint that it's overloaded with responsibilities and doesn't have a clear definition anymore and is probably a god object. So yeah those are kind of the things that I've learned about. You know maybe some cure six for spotting objects that are got objects are trending in that direction. What a fantastic answer. I think if the phrase God object ever comes up again. I'm just going to point people to this because that was such a good explanation. I know for me personally anytime on getting into a legacy whereas application it typically is the user object for me that tends to be that God object. Is you see people passing it around it really depending on it hard and you're right Sandy. Matt's has a lot of really good tips on how to break up those objects so quoting from your.

Coming up next