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.
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.