So it seems to me. Good code, should be resilient to Bucks. It should be difficult to make bugs, and it should be easy to get started on. It should lead you in the way that it wants to go. So it's making it easier to do the kinds of changes that you want the system to make. Of course, the downside of that is that most refractory actually also make it harder to make other changes. And so if you guess the direction wrong of the software, then it can have the negative effect. Hey everyone.
My name is Henry Surya be Robin. And you're listening to the tekhelet journal. The show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal.
Hello again, to all of you. My listeners, welcome back to a new episode of the tekhelet journal podcast. Thank you for spending your time with me today, listening to this episode. If you haven't, please follow technology, you know, on your podcast app and social media on LinkedIn, Twitter and Instagram, you can also contribute and support this podcast by subscribing as a patron at technology. No, dot f / Patron, and help me to continue producing, great content every week.
For today's episode. I am happy to share my conversation with Christian Clausen. Christian is a technical a jar coach specializing in teaching teams on how to refactor their code properly. He is also the author of five lines of code in this episode Christian explain in depth about what refactoring is when and how we should do refactoring to our code. And he also described the components and pillars of refactoring, including his favorite refactoring work.
Flo Christian also shared about a few important architectural refactoring such as composition over inheritance and introducing changes. By addition instead of modification. Finally Christian also shared a few tips for writing quality software, such as his five lines of code Rule and why he thinks 5 is the magic. Number cultivating, the habit of deleting code and the advice went to avoid optimization and generality.
I enjoyed my conversation with Christian deepening, my understanding of refactoring and some of his useful practical tips. And I hope that you will find this episode useful to consider helping the show by living it a rating or review on your podcast app. And you can also leave some comments on all social media
channels, though. It may seem trivial, but those reviews and comments are one of the best ways to help me get this podcasts to reach more listeners and hopefully they can also benefit from all the contents in this. Outcast, let's get this episode started right after our sponsor message. Are you looking for a new cool swag? Tackle, it Journal. Now offers you some swags that you can purchase online.
These wax are printed on demand based on your preference and will be delivered safely to you all over the world where shipping is available. Check out all the cool swag is available by visiting technology, you know dot, f / shop and don't forget to break yourself. Once you receive any of those tracks. Hello everyone, welcome back to another new episode of the package. You know, today I have a guest with me. His name is Christian Clausen.
Christian is a technical a jar coach, which is different than the typical age. Our coach. He's actually specializing in helping people to properly refactor code. So that's why the technical term is there in his title. So, he previously worked as a software engineer and even has a teaching experience about software quality in the University. So as you can guess, They will be talking a lot about software
quality. And also in particular refactoring, Christian is also writing a book called five lines of code, which is currently in Early Access program in mining. So Christian. Thank you for your time. Looking forward to have this talk with you today. Thank you for having me Christian. Before we start, maybe, can you introduce yourself to the audience here? Telling more about yourself, your highlights, maybe or turning points in your career? Sure. Now, I was at University.
I have always liked software. And coding and programming and I've done a lot of that. I also like teaching. So I've done a lot of teaching at the University level, when I could buy with the teaching, assistant will stop at some point. There wasn't any teaching position for me to fill and so I didn't have anything to do being
a bit of a self-starter. I decided to just start my own teaching thing where I would invite students to come have a to our Tech talk every week and everyone was free to talk and to say whatever they had on their mind, but it turns out computer scientists are pretty timid. So I had to host the first Steam myself to get the ball rolling and doing 60 weeks in a row, and learned a lot of different things and load of different topics. And I got really good at
learning really. And then after we were done with University, one of my friends asked me if I could improvise a talk having done so many of them. Could I just do it on the fly. Now? There's only one way to find out. Let's try it. And so that's actually how I came up with the idea for the book that conversation that followed where I tried to illustrate. I wanted to do something with code because that's where I feel most comfortable. Double.
And so I wrote up the example that's in part, one of the book and then he was like, oh that was an interesting demonstration. I don't like, we're not done. We're just getting started. I want to teach you refactoring and then he started refactoring this code base. And I came up with these rules that are the basis for the book that I guess, we can come back to. But that wasn't how it all started.
Then I worked as a consultant, a lot and I've transition from being a developer to being like, a tickly and my Fondest Memories of my career for my ticket times. So the title of your show is really Appealing to me. And then after that, I figured, maybe I should try to go more into teaching because I was missing it a bit. You know, I really am passionate about teaching and about people.
And so, I went and I actually taught at the University of applied sciences in top software quality, but was a good fit for my current patients level. I think I'm too young to go and be a full-time teacher. So, I went back and now I'm a technical agile, coaches. You said I go and help organizations, understand how to do technical practices. As you said, testing refactoring, all of ab stuff but also the cultural side, how we manage the people.
How do we organize things and devops and teams, apologies, and all that interesting stuff. So that's sort of everything in five minutes or something. Thanks for sharing your story. I could see you embody teaching code, looking at your cap and also your T-shirt, right? Then they are like geeky sentences. So, I'm really looking forward to learn from you. Please treat this as a teaching experience for the audience here as well.
So you mentioned that, you specialize a lot in refactoring, code, Maybe. As a refresher for those people who may not be familiar. Could you give us a definition of what is actually refactoring? Yeah. Sure. So refactoring in its purest, form just means changing the code without changing what it does. That's the definition. I always introduce two people. It doesn't actually have an opinion on how to use that thing. It's just saying these two pieces of code are the same.
We can go from one to the other. In practice though. We almost always have the target of actually wanting to make the code more readable more. Maintainable better to work with in something. So then we call it refactoring and in my book and also, I think, in my own Palace book, he equates refactoring with, making the code better in the sense of maintainability and readability, but it could also just means that we're rearranging code without changing the
functionality. So that's the basic concept of it and you relate this to what you call good coat. So what does it mean by good code? Is it like code that is readable and maintainable only, or is there any other property or attribute? Well, you could have many attributes of your code that Define what good is in your specific context. Some people are doing embedded systems. Where memory layout is really important or performance is
really important. There are certainly domains where good code has different properties or what seems to be common to most. If not, all of them is that we want our invariance to be as local as possible. And variance, is the stuff we need to keep in our heads. While we're working with the software and the more complicated they are. And the further away they are from where we're looking. The more likely we're going to
To forget them, right? And then we're going to make mistakes and introduce errors into the system. So, it seems to me, good code, should be resilient to Bucks. It should be difficult to make bugs, and it should be easy to get started on. It should lead you in the way that it wants to go. So it's making it easier to do the kinds of changes that you want the system to make. Of course, the downside of that is that most refractory actually also make it harder to make other changes.
And so if you guess the direction wrong of the software, then it can have the Perfect. Thanks for reminding that part because sometimes a lot of developers are into yet. Let's refactor. Let's refactor make it better, but it turns out that the design becomes more complex. The code actually becomes less readable. And also it's not easy to make further change. A lot of times actually Engineers love to refactor. They think the code will be better.
But is there any decision point where you think we should think about doing refactoring? Like what's the purpose of refactoring? It's very linked to how well you're able to predict the future of your software. I always say that if you're experimenting a lot, if you have something you're testing, you don't really know what's going to happen to it. Don't worry Factory.
Don't make it super nice to spend that time because you don't know yet, if it's malleable validate, the business case first, and then do the refactoring in the same way. If you have something that's end of life soon or some setting don't spend time refactoring that making it nice because it's not going to survive for long enough for it to pay off all the Training should pay for itself in terms of easier, maintenance and cheaper maintenance in the future and fewer bugs at higher
quality. Also, a lot of times we associate, when we do refactoring, is to actually add more tests, adding more automated test unit test, whichever test that is because to refactor and not changing the actual intention of the code, the functionality cell, Sometimes It's Tricky, right? And we want to have the failsafe mechanism to say that, okay. We have a test here. We refactor and proves that the code actually still.
Behaves as what we intended to in the beginning, but in your book, actually, you come up with a different approach saying that you don't always have to come from the automated testing perspective. You can actually do refactoring without that. Can you tell us more about that? Yeah, definitely be. So I think since then can be super useful. I like to start saying I'm not against testing, testing certainly has its places when
I'm against this. It seems that some people are fanatic about testing thinking it's the only way to check code or thinking, man, if you have test. Everything will work out. And neither of those are true. There are other ways to guarantee high quality of your code and also things can fail even if you have tests. So, I'm more just an advocate of having a more nuanced approach, where you actually pick the quality tools, that fit the job like many of the refactorings. I would claim.
Most, if not all of their affections in, my book are breaking down to Atomic steps in a way that make it difficult for you to make mistakes while doing them. Of course. This means that we go a little bit slower while doing refactorings, but that To make up for the fact that we don't have the test to catch us if we Slide by the site. So if you follow the steps very accurately and in small steps, you're minimizing the risk of error at each point in the process which minimizes the
overall error rate a lot. So, I feel like there are other ways to guarantee that you can have high quality code, particularly. My thesis work that University was about, provably correct software here. I was actually sitting down and doing a proof that the computer could then check and verify that the I might written, did the thing that I claimed that it did, which means testing was trivial, you know, you don't need to test something.
If you've proven it works. You don't even need to run it. I just knew that it worked. So I'm just saying there are so many different levels of security and risk. And it's all about risk management. What is your company's strategy for managing risk? Is it during testing? That's cool. Isn't doing like types. That cannot go wrong. Then that's also cool. It's a business decision. What's your tolerance to risk ever since I wrote my thesis on
provably, Correct software. I hope that their automated cars. Self-driving cast would be proven. Correct. So that we knew Lee didn't kill people. They do need to kill. Unfortunately. It's sort of gone. The other direction doing machine learning where we can't even look at one that's thinking. It's very interesting. This is provably correct software. I haven't heard it before. Could you tell us a little bit more about? How does this thing work?
Is it solely relying on certain practices? Or is it solely relying on tools? I guess you can prove any program but it comes very expensive to do in the general case. The specific part. I work with was automatically verifiable proof. So we use the proof assistant or I've dependently typed programming language specific language, that was filled on new camel and functional language,
where you could. Then also type in the properties that you wanted your program to have and then it has some extra stuff to help you do the proof in that program as well. And then we'll check it without you needing to run it. There were some limitations, for instance. You can do instead nukes. Because you can't prove anything about if any of the coming that will be on the sound, but it also has some very high learning curve and that's in my Optics.
The biggest provender am using this widespread, but some of the practices. Some of the lessons we learned from that are seeping into other programming languages. I think the appearance of lambdas or higher order functions in most languages by now, or certainly helping to bring down the number of Errors. The fact that we are now talking in maps and filters and Loops that are based on the data. Doctor and not on the Primitive. Operator for instance.
That's certainly also helping we're moving in the right direction and also something that comes very much from my time working with dependent types, is my love of the type system and the type Checker. And you'll see that everywhere in the book. I relied very heavily on the fact that if I've set this as a number, I know without checking it. It's gonna be a number, the more properties you can put into that the more you don't have to test
because it can never fail. It's actually in a lot of ways. More powerful than tests. If you can express the same properties. Interesting concept, so I'll make sure maybe, if you have the link to your feces, for people who are interested to learn more about this. Also, you mentioned that it's interesting when you do refactoring, that you have to understand the strategy of your company or your business and you mention, these are one of the components for doing refactoring.
So skills is definitely one but they are also culture and tools. Can you tell us more about these three components? Yeah, the most problems that I encounter as a Tell coach or as a sort of a demo Ops consultant is related to one or more of these three. It's often a combination of them. It's when there's something that you're not doing right? Or did you not doing it
effectively. It's almost always because you missing the culture of doing it. Like you don't have permission or you don't have funding or something like that or you're not allowed to reorganize. The teams could be a big one and develops. It could be the knowledge that you don't have using. They don't know that. Something is bad or how something works or you're doing
the best that you can. But you don't have the Tools to do it. You don't have the correct thing to help you do this in an efficient manner, which makes it unfeasible and practice and refactoring requires. Everything writer cries. You have time to do refactoring. It requires you to have some sort of way to do it safely, some quality measure, we can't do it with our eyes closed. Testing is one of those tools but it could also be types are
good. Also be Version Control or manual testing or 15 other things. And it also, of course requires the skills to know. How do I actually do a factory? How do I know? I'm not just making this code worse. I've seen a lot of people especially young Engineers who just want to make the code AS compact as possible. They think it's really cool if they can do something one line. And it's like it maybe, but that's unreadable. I don't even know if it works. So it's definitely worse for
teamwork. So, we're factoring a sort of, a sophisticated Balancing Act between those three. So you mentioned about pop culture of getting permission to do it, and all that. There may be a lot of software Engineers would listen to this that are starting their careers or there. They're kind of like Junior. What will be your advice to them? Because they want to do? Good job, of course, like producing good coat or maybe working with Legacy code. Where is just simply difficult to work with?
So what would be your advice to them to actually have the courage to start refactoring? Well, first of all, I've recommended the source books that I talk about a lot like that. Modern polish original infection Burgers up. I recommended those to a lot of people, what I've often found was that it's actually difficult to get started with. It's very difficult to sit down and The book and then put it into practice.
Those are far apart. And then sort of why I wrote my book was to make it more accessible and reducing the cost of learning refactoring and least. That's my aim, so that you can actually start reading my book and do some good stuff to your code from the next day or the same day. As you eat something, you don't have to spend days mulling it over or doing theoretical exercises. You can practice in the exercise in the book and then you can do it on your own code, immediately
afterwards. So already, then reducing the The initial cost of learning is important. I think that's the first step. I do need to get started somewhere. Then the second step you mentioned getting the funding to do it or the time to do it.
I think if you have an organization where it's difficult to get funding, I think the easiest way to get it is probably to do refactoring before you start working on a task so that you will be like well to make this change, I need to prepare the environment to receive it. The need to go and make this code will written so that I can easier make my change the problem with doing it. Other way where we first do the change in.
Do the refactoring this set in a lot of places, if your estimated that the task takes some time and then you spend that time implementing the feature. Maybe you go a little bit over. They're not going to give you the time to do the refactoring as well. So it makes more sense to do it first. And I love this quote that I have in the book, also by Kent Beck where he says first, make the change easy, then make the easy to change.
Wow, I love that quote as well. And you mentioned that it should be part of our daily routine as a software engineer. So how would this routine look like? Maybe if you can explain to us? Because when we pick up a task, for example, we are working on but fixing or feature, right? So, how should we make this as a routine I present in the book. I think there are six steps to the workflow that I recommend that people use and it's sort of built from what I've seen people
go through. But it's also not accounting for the fact that it's probably easier to get funding the other way around. This is from an optimal sort of workflow would look like in a company that is mature enough to actually let developers do the development.
The way that they say, the reason it should be part of your daily work is of course that we know from all sorts of things, lean and devops and everything else that smaller batches give to a smaller errors and lower risks and easier to fix errors. So, the more continuously you do refactoring, the smaller the risk that something's going to go wrong and you're not doing, like, a full two-week refactoring.
That's just bound to go wrong in everywhere and create merge conflicts with everyone and everything is going to go bad. So we want to do it in small batches and that's why the workflow is you start by experimenting that first? A lot of people just start coding which I've linked to be counterproductive in a lot of cases because we don't know what we have to build. Usually the ticket that we get or the task is poorly described it maybe even not done by a user
or anything. It's just someone has an idea and then they put it on paper. Maybe they follow sort of the Mike Cohen style as Need to or something like that, but it's still, it's very difficult to get a hold of. So I recommend people start by experimenting with what we call a spike where they just write some code. It's intended to be thrown away. It's not a production code. It's just to figure out is this sort of thing. What I want to do, we sort of eliminate most of the
uncertainty in this space. We maybe send it to the customer and say, hey, I know this isn't looking great, but does it function the way that you expect it to, or maybe, we're also marking up some prototype for the design as well, just to get a feeling. So, the First base is experiment with a spike. Then once we have that we usually like to write down the specification. It's just a list of the things that we've just agreed on to lock something in and say this, I have certainty and I know
these things are true. Sometimes we do this. If they weren't automated tests with something like a behavior during development or test driven development. You will be right down some tests. And sometimes we just write it in the acceptance criteria and other times. We do other things. I don't mind how you do your specifications just write down what you've tested. What your hypotheses were and what you now know from the user or the reporter. And then you start doing the code.
Now, we have the specification. So now you can start doing the code. However, you want to do that. Finally. You have to go back when the thing is done and check against the specification, right? You have a checklist of the things that you should be able to do, or you run your test or however, you did the specification. You just check against it to make sure that everything is good and then you do refactoring
afterwards. Because now you have this new feature that has been in a state of flux where you work, moving things around you. Experimenting. Nothing you sure but now that you're sure it's a fides, the specification. Now you can go and say, okay. I'm going to make it nice before I shared with my team because I don't want to trip up my team. The don't want everyone else to
be prevented by this thing. So you do the refactoring and you make it nice and then you deliver it into production or to the main branch or something like that. Thanks for sharing the workflow. I think the few key things that I pick up there to have a specification. We have a checklist of things that you need to fulfill in terms of, maybe the The bug fixing and then you test it experiment, maybe ask for feedback, from users, or from
Weber that use that feature. After you prove that the spec works, you do the refractory. And again, at the end, you proved again that the specification are still met. So thanks for sharing that look, Flo the other thing that I pick up and I really like this thing. You mentioned that three maybe principles or pillars of refactoring. So maybe I'll mention it one by one improving readability by communicating in 10. So, what do you mean by this
communicating? In 10, I mean, that the code should lead you to a natural conclusion, that should be accurate with what the code is doing. It should have good method names as an easy way to start. Give us something a name that actually holds a poor example, I would say is when you have comments that somehow go out of sync with what the code is doing, method names, rarely do that. Luckily? Or when you just give something a good variable name or something like that. You are help me.
Not having to check a bunch of things around it because I could see, okay. This is communicating what its intended to do and from my experience as well. This is also a good reminder for everyone. Right? Sometimes the thing that you are working on is not written by you in the first place, but it's pulley communicated. In terms of name in terms of intent. I think this is also a good reminder for us that you should not be afraid of changing.
Even those things that you did not write and make it more readable, communicating more in 10, maybe changing the name would be the easiest example of this bike could be other things, changing the class names data structure, and things like that. It gets. Yeah, exactly. Data structures and interesting point by because if you have an interface with five subclasses, then that's also communicating to you. That it's likely. There's going to be a six or seven.
That's also communicating sort of an architectural intent behind this thing. We're expecting this to have more subclasses. The second one you mentioned about the principles of refactoring is actually to improve maintainability by localizing invariance. So you mentioned this in the beginning, maybe you can explain Again by localizing invariance. What do you mean by that?
Sure, your abs as I said, And when barium is something you need to keep in our hints, that is true about the system, but that the system doesn't know about. So it's something in the sort of a meat and layer of programming where I know that this property always holds.
So I have to keep trying to make sure I don't break it because then somebody else's code might break and the fact that also already suggests where it can go wrong, right with you have two different places that rely on the same invariant that isn't checked anywhere in the code. Then I might very easily break it in one place and then affect another place. So we These invariants to have the smallest scope possible. We want them to be local and variance.
So for instance, only this needs to be true within this method. It's unlikely that I'm going to break it because I could see the whole method. Whereas if it's some Global field that I know have either a 1 or a 0, then, you know, somebody could go and put a 2 in it from anywhere in the program and I don't have the mental capacity to actually look at the whole code base and see, does anyone ever break this invariant. So we want these to be localized
to one. To be a small scope as possible, which leads us to the third principle, which is by doing the first tool, you should do it without affecting any code outside our scope. So make it a smaller scope as much as possible. It also means that if we draw a line around the code that we have access to and we don't know who is outside of that line. That could be anyone if we're doing a library than this other developers that we're doing the
front end, then it's the user. We cannot affect anyone who is not A part of this team or we don't own the code. That's Coley our code. So we can't change the public interfaces. So it's just defining. What is our boundary for change. Where are we allowed to change something? And it might be to say where we don't have access. We're not controlling the database so we can't change any of the fields in the database, but we can change the layer right after it.
Enters our control our boundary. So it's just saying that anyone from outside. Our team should not be able to see whether we've refactored our code or not. I like that as well. So, let's go back to the topic of the book, which is five lines of code. The first thing that is interesting to me. Y5y, not shorter, maybe three or why not longer, maybe 10. So, why particularly 5, I will admit that it takes a good
portion of luck. Sometimes to be a gotcher to be on the Forefront of doing something new. And I came up with five lines because I was looking at the game, they example, the book is a 2-D game and so it takes exactly five lines to do one pass through. A 2d array. You have two moves to think inside with a knife and a return or something like that. I was thinking, it does not make sense to set.
The limit lower than I can do a pass of the data structure because then I have to actually split up the two for loops and that sort of breaks the intent a little bit, makes it harder to see that we're running through this array. And I'm also saying in the book if you have an another fundamental data structure, if you're working with 3D arrays or for the erase, then you should probably use a slightly higher
limit and fitted a little bit. But for most cases that I see in practice five lines seems to be a pretty good indicator. And I've since learned that someone has done a study of how many bugs that were in code, depending on how many lines, the method length was, the average method. It turned out that five and six are the lowest number four hairs. I mean, that's just pure luck. I didn't know that when I wrote it, but I still think it makes
intuitive sense. And I also think that all the advice I give as a coach should be intuitively, easy to understand. Once you are told, and they can be hard to come up with the idea, but it should be easy when you handed. Why do you think that shot the code actually leads to a much better color? Maybe less box, or is that even more readable?
Yeah. I mean, that's a good point and a lot of people find that out that it may become less readable actually, by exploding up like this 20 line method. That had a really nice flow to it. And now we're cutting it up into four different things and making the street. We're actually making it harder to follow from the start to the Finish because you need to go through. A lot more layers, and that's a
really accurate point. The thing is though, the way that I use the methods in the book and in practice, also this that I let the lines of code show me where the method should be through blank lines or through other structures that I described in the book. And then I explode that out two methods. And then I let the methods guide me to where the classes should be through rules, like common
ethics, or something like that. Where I didn't get a much more finely detailed hierarchy of classes that interact with each other. That Both actually helps the generality. Like, I can reuse more things but that's not the point at all. The point is more that I can isolate things. Then it's an invariant to three methods but not the last two, then I can make it Clans around those three methods, where the invariant is isolated. So again, localizing the invariance.
So I use the statements to guide the methods and the methods to guide the classes in the class is actually to guide the names based, but we don't do names faces too much in the book. So a lot of people actually also like, throughout my experience looking at shortcode. Yeah. Yeah. It's nice neat. But sometimes some people complain is hard to trace, especially if they don't use a proper tool, if they don't use proper ID. Maybe they just use text. I did, of course. This will be cumbersome.
Right? Where you have to navigate across multiple functions. Any advice for those people. I mean, I'm just using visual studio code and anything that hasn't F12 or something that jumps to the definition of a something. We'll just it really doesn't turn out to be a big problem. If you do have an editor, that's not very smart. Then my old advice back when I
was On seems like that. I said that every time you go looking for a method, you should swap it with the one right above it so that it wobbles up to the top of the file. And then the things you're looking for, most often will be at the top of the file and other approach that does. The same thing, is based on the book algorithms to live by just every time you go look for something, put it on top sort of
like a stack. You just take it out from anywhere and look from the top, because turns out we look for the same things often and some things we look for only ones ever and they'll just go The bottom of the file, so it's the same idea but things that you're looking for often higher in the file, but really just use an editor that has the pilot. He's interesting approach. So you also mention that to important architectural, refactoring for people.
I think this is quite important in my opinion, as well. So to architectural refactoring, whenever we want to make it either like short concise or even better in terms of maintainability, right? The facilities about favoring composition over inheritance. This was also mentioned in one of the books. Oh, I forget what is the title? But can you tell us more? Why not inheritance?
Why composition? Yeah, so the gang of four book or design patterns as it's called it was the first book that sort of introduced design patterns in a large way. I don't know what they may have existed before. Then. I was in the programmer, but they were sort of the pioneers of design patterns where they were like we see these General problems.
Begin and again, and there is a right solution to solve this specific thing and then they wrote down the constraints that were necessary and then they wrote down the solution, which is Amazing. It's a great way to solve a bunch of problems. The thing is though, in my opinion, or my view design patterns, were mostly to improve the architecture of a specification. At least. I think that was part of the
idea. You could see these things in the specifying paste, and then you could improve them already didn't and then you wouldn't have the problem when it came to the software. The thing is, those things change a lot. You can't just write up a thing. And then it just works the way you intended. It changes throughout the lifetime of the software and then refactoring. Alms in this is the same thick introducing those patterns in a way that doesn't break the
system. We've already built and in a way where we don't need to predict anything in the future. I don't know where their variability points are going to be at this scope, but I can see it after work with a 42 years. I know where I tend to do move changes. So, the thing is with the inheritance, this exactly the in very important that I had before, when you have one superclass and you have two subclasses, these two subclasses now. Share a common invariant through
the superclass. You have actually created an invariant that goes across two things that you can't possibly do at the same time. It just makes them dependent on each other and changing one things. Interface means you have to change the super Glenda's interface, and then you have to achieve other one. What do you know about the other one? The other one might be another team, right? Then is doing something slightly different than you don't know how to sort of fit that specification.
So, you're creating a coupling between these two subclasses and also between the superclass and both of them. It's just a very bad practice these. We extend to strangle us. If we don't manage them, very strictly. There are cases, certainly for inheritance, the ruled in the books, they never use inheritance, but it's because it's simpler to remember that way. It's almost never. It seems counterintuitive for object-oriented programming where the inheritance is actually.
One of the properties of why you would want to use object-oriented. This seems counterintuitive to me, a lot of examples. Also in the books, during our University you have shape. And then you have Circle and triangle, and all that. All this seems to say that, okay, you should probably use inheritance for things that are common to each other similar to each other. Right? Well, I think it's a very common misunderstanding that object in object oriented programming, has
to do with physical objects. Whereas I have do remember who said it but I think the north has reiterated, the point in some ways talk stood. In fact, the idea of an object, in an object oriented language, this, like a virtual machine, it can solve a test. It's a mess. Each passing system where the methods are actually the events or the messages that it passes to other objects that are themselves little virtual machines.
So, we tend to think of objects much more like people, I have a person who knows how to handle these specific things, and then I can give him tasks that he will then solve for me and give them back. They are much less about physical objects are just properties of something. It's a completely different thing in my mind and then interfaces, then become capabilities of that person. Like, Vacations really this optic knows how to do the method M. Ok cool. He's certified em. Cool.
So it's a different manner for but I think it gives better design to think about it like that. Thanks for changing the perspective. For those people who are still into that mindset of objects, like physical objects, or maybe even like biology where you inherit something from your parents. So thanks for reminding that another counterintuitive architecture refactoring. You mentioned that by changing code, right? You should do it by doing
addition. Instead of Ian, this is also sometimes contain intuitive but it's very important principle in my opinion. So can you tell us more about this rule? When we change code, if we modify it, we are again doing something risky. There is a risk that I'm changing this wrong and breaking something. The different approach to that entirely is to say, well before I go and make a change.
I'll just take this code and put it within if/else block where it's going to be called, and then I'll put my new code in the else block, maybe even duplicate the original code make my modifications. In the else block, but the original code is still there. It's intact and I can still run it through that. If block that. I have your B just pass, a parameter saying with, I want to run the top one or the bottom one. Then I still have both pieces of code.
I can change between them very quickly and that also means I've only added things to this coat that never change the original code, no modification of just added things, but I've changed the functionality through the new parameter that I can pass to run the new code. And then when you start doing that regularly, you realize that That it's actually maybe not the best thing to do this with gifts.
Sometimes it is, you do feature toggling, then we're doing it exactly like that actually, but if we're doing something more complicated where we have two customers who need to separate configurations of this software or two separate versions of the software, then we'll do it probably through a strategy pattern from exactly the book we mentioned before the gang of four book strangely pattern, which is also something that a lot of refactoring and I would probably say the most important
refactoring in the book is about how to introduce ready. The Safeway things taking two pieces of code and then making and biffed into an interface with some sub classes for each of the cases and it's super powerful and it's very nice and it means we can do change by modification. Also, sometimes you mentioned right feature toggling. It helps also in terms of a/b testing or some kind of rolling deployment, where you don't want to deploy all these changes to
the people exactly in one way. So you could probably also roll it back by changing the toggle or maybe changing the implementation of the interface. There are so many advantages to something like that. You can merge your code continuously into the brains because it's toggle off. You can deploy it continuously to meet action because it's toggle off. You can release it as a business decision right on a timer. If you want, you can do it during a big conference event or doing some live thing.
You can just go and say now the code is active and now we have this new feature and it's super cool. And it looks like magic which is part of what marketing is about. I think. And then you can also build TB testing that you say on top and you can just keep growing something. Like that, you don't need to do anything. You just put things in the feature targeting system. It figures out, whether it works. It figures out whether it's
valuable. I mean it can get our base fairly sophisticated at that point. So whenever we add more of clothes, obviously, the could grows bigger and bigger, right? You mentioned also we as a developers should have this habit of deleting code. So why do you think it's important for us? Not to forget deleting code? You said it yourself systems tend to grow over time and become very complex. I don't think we We have a good solution at the moment, for how
to get rid of code. It seems that our code bases are growing and growing. It's an active thing to go and delete something and it takes time, but it seems difficult to argue why that's valuable in the same way. That is difficult to argue. Why refactoring is valuable because people don't understand that. We're carrying this load on our back. Every time we need to go and check something. If I need to check, as I said the system before, if there is
an invariant somewhere. I need to check the whole code base. I can't do it in. Most cases because it's growing out of control. Then I think that's also part of why microservices, had such a huge impact. We were making the full quote based, in quote. We're making that smaller. We're making the full core basis, this service instead of the hole on the left, the way to sort of get through that is by
constantly cutting off anything. That's not pulling its own weight, anything that's not providing value. Whether that's documentation or bad tests for actually running features. Sometimes if I have this feature, that's super, Expensive to maintain, but there are two people using it. I might just cut that feature entirely. It's not pulling its own weight and it's important to get rid of that.
And I think it's a big problem right now that we don't have that structured way of getting rid of old or dead code or very underutilized code and it's all coming back to my earlier argument. Right? Some people also tend to be afraid of deleting other people's code. Any advice for them. I do in the book suggests that if you have a legacy system, for instance, that you actually That in a different class that you can then monitor, how often is this actually called?
And it also helps if you want to start deleting it yet, the type system again, as I said, I love that the type system will help you find all the occurrences where you're calling this and redirect them or just to see if there are no occurrences of the method being called, some editors can help you say this,
private Manson's is not call. But if you have a public method, it can't possibly know whether it is called because if you're doing a library, how will it know if somebody else is calling it, but if You know that you're not doing a library, then editor won't help you. So you have to go in and actually work with deleting code and getting rid of things and I do it as much as I can. I delete comments. I delete anything that looks like that code.
After verifying obviously that is not going to break anything. I delete all the time and hopefully you'll see. I will also tell you if you delete something wrong, the bill will fail and you can roll it back safely and you always have the Version Control. Anyway, hopefully everyone is doing fish and control by know. You meant it. Beginning that some people Pen tool of simplifying, the code into one line, multiple lines, or as short as possible, right?
And you mentioned this as an anti patterns, so like over optimizing your code or come up with a more generic framework or approach where you think, okay. This will be useful in the future. Can you tell us more white? These are the danger things we should avoid. I have a few things that seem natural to people that people start doing, but that are actually counterproductive and one of them as you say, is when people try to simplify things so
that they are short in terms. Terms of lines of code, which doesn't make any sense to me at all because it's not actually making the code faster, or usually not even smaller. But some people like it and it looks cool and it feel cool while doing it and saying, look at this code that I came up with to solve this complex thing. You just 30 characters. It's amazing. It's just not very good for teamwork. And that's actually where the productivity happens and where the Practical applications
happen. So optimizing lines of code is one of them. Then we have, as you also said is the generality. We also, I want to find this. Oh, I have this function itself is a specific thing. But if I just add these two parameters and then structured a little bit differently. I can solve this whole other class of problems. That is much bigger. And that seems like it would be valuable because then you don't have to do another function next time we can just call this one
again. The problem is as I said earlier you haven't validated. This is ever going to happen. My you don't know that this is gonna happen. So there's no point in this serology. It's just something that you spent time on. That's maybe Ever going to pay off and even worse. Sometimes it actually prevents us from doing some transformations to the code because it's overly General and then you can't simplify it in the same way. So if I spot that something is always being called with the
same parameters. I just remove the perimeter just in line them simplify the code. Sometimes it's much easier to work with after that, and you'll never need that generality. Optimization is another one. A lot of people like to do, like people look like shaved off point zero two milliseconds and it's like, that's cool. Why? Like, how many hours did you spend shaving that off? It only took me three hours? Okay, cool, but the app takes 5
Seconds to start off. I mean you're doing this thing and it feels valuable and that's the danger of it. It feels like you're doing something good. But in fact, it's not the appropriate timing to do. So dry is like to the another one. Then I'm sort of on the fence about. There are certainly cases for dry and like their optimizations
in generality. They have their cases, but in a lot of cases where we see people doing it, it's actually not the right time to do it because Dry is another way to unify. So, don't repeat yourself as dryer. Instead of copying some code. It's making a new function, generalizing it, and then using that into place in the step, but you've now coupled the two places.
These places now changed together that might be appropriate, but it might also just as well, not be appropriate, do not repeat yourself is in itself, not valuable. Unless, you know, that the underlying Behavior has to stay in sync and sometimes that's true. But without asking the question, you can't know. Have to stop and think, are these places gonna change together forever? Or is it actually better to have them be two separate copies of
the same thing? And then when they change that sign because they're not related to each other. So those are my four of my favorite games. I call them to bash on the developers do because it feel good, but they're just not. It's very interesting to listen to this perspectives because sometimes Engineers, we tend to focus on some engineering best practices, but I treat some of these are content to it in practice, especially in team.
Look like you mentioned, Shadow lines of code, maybe with cryptic name might be shorter, but it's actually are counterproductive to teamwork and how people understand your code may be. For the last session. You mentioned about Atomic changes in the beginning. Can you maybe share some of your favorite refactoring, strategies or methods for people who wants to get started? So can you tell us some of your favorites? Obviously, the classical one is extract method.
I mean, that is that sing we build everything on. That's the foundation of everything. If we can't break up methods. Do all these things with methods and generalize unify, you know, you can do too many things with extract method. I really like it.
It's a stable, the start of my favorite or factoring pattern has always been and probably will always be the replaced type code with classes because the first time you take an enum or something like it and the replace over classes and see how all the code just magically just simplifies, all the ifs. Go away all the chicks and stuff. It's just it's so wonderful and it just looks really cool. I was mind-blowing. Chapter 4.
It is in my opinion. If you don't get the chills, all reading chapter 4, then maybe you're too advanced for the book. You're already too smart, but that's just amazing. And as I said, probably strategy pattern is both more useful, more powerful, but I still just love the replace type code thing. I mean, it just has a special place in my heart. That was when I knew refactoring, was light.
So powerful. So, for those of you who listen to this and you want to feel the chill, make sure you read chapter 4 of Christians book, five lines of code. When is it going to be out? Actually, it's a great question. I wish I knew it's in production. So we have some people checking the layout and making sure everything looks nice and cool, and then they send it to me for review. And that's a process that we're
in right now. We're reviewing all the chapters, making sure everything's lined up nicely and the code looks good on paper and everything is just good to go. I'm hoping the ID, but I'm fairly certain, it will be this year. So the question is, how long will we take to review all these changes Apple? Bead, go smooth. So Christian. Thank you so much for spending your time. I'm here is pretty unpleasant talk and I learned a lot from
you. But before I let you go, I have this one last question that I normally ask for all my guests, which is for you to share your tree technical leadership. Wisdom in all of us here to learn from. And maybe also a look at some of the wisdom that I actually met the for us. So, can you share us your tree technical leadership wisdom. So since this is called tekhelet Journal, I'll talk about how my experience is.
It's actually worse and the things that I found out to be working for him and I was a technique. First of all, I would say it's about inspirational leadership. It's about actually inspiring. Your people is much more powerful than trying to control anything. So, now, when I coach technical techniques, I usually say that the only Power they're getting is they can host the talk 20 minutes every second week where they talk about whatever they want. That's their time.
But if they're not inspirational the wasting it, that's the only way they can control anything. So we have to sort of start being inspirational. They have to start talking about things in the right way and getting the team excited to do the things that they want. Things to go in there, right direction. So that's definitely the first one. It's very important mental. So what I like about teaching all these, these inspiring people and the second one I guess is to be humble.
We're going to run into situations that we can't control and that are going to be chaotic. They're going to be errors and outages and managers to shouting and customers are showering and developers are crying. They're going to be so many different things to handle and just going into this with the mindset of I'm going to be the best I can control. Everything is not going to help you at all. It's much. More helpful to just say. Okay, these things are going to
happen. Some of them are out of my control and just have to weather that into staying. On course. The third thing is sort of the same but in a different ways to listen to your people, usually, the people have their own brain, they're actually smart people and they have great ideas and just listening to that and supporting them and helping them and empowering them. Instead of trying to control the situation, a lot is just a much
better way to work. When I was doing one of my favorite assignments, as a Technique. We had an issue that we I would send that choose to review. We would call the customers Aid. You see the change? Do you like it? This is the way that you want it, and they're taking a short, but I also need and then I would add something, you know, they're just push something onto the back, look under the table, going around all of the prophecies and everything when I came to the exactly there.
I was like, so what are you guys working on in there? Like I'm working on this thing and this thing and like those are not on the backlog. Why are you working on those things? I can't see what's happening. What the team is doing? And so I said to them that from now on, they could not talk to the customer the customer. Only talk to me because they don't the developers, would we
get into active? They wouldn't call the developer and say, oh also, I need this other thing, interrupting them from the flow that they were in focusing on flow is like nothing, right? You need your team to be productive as much of the time as possible. So I just tend to absorb a lot of the waste into my time and in the developers could be super productive deliver, great software and then that would bring down sort of the waste
over time. So yeah, it's listen to your people and enable them Empower them focus on. On them and then the sacrifice yourself a little bit. Sometimes that's fine. I'm laughing at you. Imagine that story, right? Because this is like a psychological thing where you show people your good work and they acknowledged but they had something like psychologically and you become like okay, maybe let's just do this small thing and it will be better. So thanks again for reminding
this. So Christian for people who wants to connect with you, whether they want to learn more from you, any blocks any website, or any Twitter account or LinkedIn for people to look for you. Yes, I am. The doctor Lambda on GitHub, on medium, on Twitter. Pretty much everywhere developers are MD, doctor Lambda. Then I try to reserve that in as many places as possible. So hit me up. I love talking about cook quality and software development in stuff wasn't aware of that.
We could have talked about your doctor Lambda thing, but maybe for another episode. All right. So thanks Christian. Good luck with your book. Looking forward to have it on Amazon or somewhere where people buy books. Yeah. Thanks for having me. Thank you for listening to this episode and for staying right till the end. If you highly enjoyed, please share it with your friends and colleagues who you think would also benefit from listening to
this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It really, really helps me a lot in order to grow these podcasts better. You can also find the full show notes of this conversation on the episode page at technology. No, the death website. Including the full transcript interesting quotes, and links to the resources and mentions from the conversation. And lastly make sure to subscribe to the show's mailing
list on technology. No, the deaf to get notified for any future episodes. Stay tuned for the next technique Journal episode. And until then. Goodbye.