Open-Closed Principle Part 2

Jason, Huiqi and I continue our conversation about the Open-Closed Principle. You can find part 1 here: https://youtu.be/tg3ZOS3neaQ. Here we discuss what signs we use to tell us when to refactor and when not to refactor, and how to develop refactoring and software architecture skills.

Transcript

The following transcript was automatically generated by an algorithm.

00:00 : i think it'd be interesting to talk
00:01 : about just to hear
00:04 : you and hoichi because we're kind of
00:05 : starting at the end here where he's
00:06 : saying
00:07 : i have this thing and what if and it was
00:09 : done wrong and what if i did it this
00:11 : way but just to talk about the process
00:14 : like you have nothing and the business
00:16 : says hey we want to
00:18 : we want to have this thing where you
00:20 : know there's
00:21 : there's shapes and they're drawn on
00:23 : screen and you know can you make can you
00:24 : make a program that does that
00:26 : and we know that we're going to want to
00:28 : add loads to it after it goes viral
00:30 : you know um so can you make it really
00:33 : great you know and perfect like what
00:36 : you know where would you start that
00:38 : process in order to try to
00:41 : adhere to this as well as possible to be
00:43 : strategic about it
00:44 : does that sound like a good exercise the
00:46 : way i like to do it
00:49 : may not necessarily be
00:52 : the preferred method for everyone but i
00:54 : can tell you
00:55 : my approach i actually have a pretty bad
00:58 : memory
00:59 : that's not one of my strengths i i've
01:02 : known a
01:02 : co-worker in the past who has much much
01:06 : better memory than me and i know like
01:08 : that the
01:10 : great chess players for example they
01:11 : have much much better memory
01:13 : and i have a feeling for people have
01:16 : really good memory
01:17 : they might approach it differently they
01:19 : might prefer more of a holistic
01:21 : upfront kind of approach i i don't do
01:23 : that approach i
01:24 : prefer to build it like from the small
01:28 : and then grow it bit by bit i actually
01:30 : try to stay with the concrete
01:32 : i don't try to extract up front i try to
01:35 : write
01:36 : more tedious and more straightforward
01:38 : code just to get the feature working
01:41 : and if that means code that looks more
01:43 : like their very first example
01:45 : that's probably what i'll write like
01:46 : with this switch statement so
01:48 : actually i actually tend to approach it
01:51 : basically the same way that he does with
01:53 : every example and then i
01:55 : morph it a little bit more of it a
01:57 : little bit yeah that's how i do it
01:59 : i really like that because i i feel like
02:01 : we have so many conversations about good
02:03 : architecture and i
02:04 : to me at least implicitly like this
02:06 : conversation
02:07 : up to this point has been like if you
02:10 : really should try to do this
02:11 : like all the time but i i tend to
02:13 : completely agree with you toby like
02:15 : and i think a lot of us might feel like
02:17 : well you shouldn't really do it but
02:19 : what we do is like write the switch
02:21 : statement like until you have three
02:23 : shapes
02:24 : you know until you have four shapes do
02:26 : you even need
02:27 : all of this like super elegant
02:29 : abstraction to make sure that your code
02:31 : is like super perfect
02:32 : and is it even responsible to build it
02:35 : literally because what we just talked
02:36 : about that once you build it then you're
02:37 : like kind of stuck with it
02:39 : so if you only have two shapes is it
02:41 : even responsible to try to abstract
02:43 : things
02:45 : i definitely feel very similarly that
02:47 : yeah build it naively and then
02:50 : ease into patterns like this
02:53 : i think like from from my experience
02:56 : talking like mentoring developers um
03:00 : the junior developers that are trying to
03:02 : level up
03:04 : they will often jump to the abstract
03:07 : versions
03:08 : too quickly and run and run into the
03:13 : problems that we already mentioned and
03:15 : and then maybe
03:16 : their idea of what the interface is
03:19 : wasn't the
03:19 : optimal one but although it's two
03:22 : degrees obviously there's
03:24 : never the the correct one and the wrong
03:26 : one but maybe then
03:27 : later on we regret it and then we have
03:29 : to change it to a different
03:31 : different protocol and then that adds
03:34 : even more cost
03:35 : to the project there are uh two
03:38 : questions uh from this approach which is
03:41 : like
03:41 : first is at what point you you
03:44 : you're like oh i have to make
03:46 : abstractions instead of using switch
03:48 : statement what is the tipping point
03:50 : the second question is uh what what if
03:52 : you have to decide the interface like
03:54 : right now
03:55 : i mean even before you write actual
03:57 : implementation
03:58 : for whatever reason you have to have
04:01 : this interface because you have to work
04:03 : with another team or
04:04 : you have to have separate two parts
04:08 : okay the first one is like what's
04:11 : the tipping point what's the sign you
04:14 : should look for
04:14 : maybe yeah before you decide you should
04:18 : extract out an extension point or
04:21 : something like that
04:22 : do you guys have any thoughts for me
04:24 : it's just until i'm doing something that
04:26 : feels
04:26 : really nasty i i definitely i don't feel
04:29 : a need
04:30 : like i i let it just be motivated by
04:33 : that
04:33 : you know you write that that switch
04:35 : statement and there's two elements in it
04:37 : and then
04:38 : by the time i'm adding the third fourth
04:40 : fifth element something starts to feel
04:42 : really wrong and it's becoming more
04:44 : tedious to do it
04:45 : and so that's usually how i let myself
04:48 : be motivated
04:49 : it's the pain point you let yourself be
04:51 : guided by the pain points that you
04:53 : expect
04:54 : yeah and i trust my pain receptors yeah
04:57 : because yeah because that's it's hard to
04:59 : you know that's gonna obviously be
05:00 : different subjective but i
05:02 : i think that's yeah i've got a decent
05:04 : sense of it at least
05:05 : i feel like it served me well so yeah
05:07 : yes yeah i totally agree i totally agree
05:11 : is how if i see a pattern that
05:14 : i think it makes sense to abstract
05:17 : because the more
05:18 : cases that you see the easier to see the
05:22 : patch then the more uh
05:24 : existing requirement that you know the
05:26 : easier that you see the pattern
05:28 : and because you don't know how to
05:29 : extract until you see the pattern so
05:32 : i will go i see hey
05:35 : it makes sense to extract this way
05:37 : because i have
05:39 : all these stuff already yeah that
05:42 : yeah that's an important point too i
05:44 : sometimes
05:45 : defer the extraction because of that too
05:49 : which on the one hand seems
05:51 : irresponsible but
05:52 : on the other hand i think there's a
05:54 : reason for the madness
05:56 : so there's a there's a rule of three uh
05:59 : this is for writing no rule of three
06:03 : computer science there we go the rule of
06:07 : threes
06:07 : is a rule of thumb for refactoring
06:11 : you should start extracting if there's
06:13 : three instances
06:15 : of the duplication uh before you start
06:18 : refactoring
06:19 : but that's just a rule of thumb
06:20 : sometimes i defer it because i
06:23 : foresee things coming down in the
06:26 : pipeline
06:27 : that could change things right
06:31 : like i'm implementing my ui
06:34 : and i'm implementing the layout engine
06:36 : i'm implementing the rendering engine
06:39 : um and then i i'm feeling some pain
06:42 : and i'm wanting to refactor but i might
06:46 : have this
06:47 : worry that if i if i design my extension
06:50 : points now
06:52 : i may not be considering uh what the
06:54 : needs are
06:55 : for later like i'm gonna need to
06:57 : implement
06:58 : a keyboard focus later on what's that
07:02 : gonna look like i don't know yet i
07:03 : haven't thought about it
07:05 : but what if the protocol i design now
07:08 : is very flawed and and and then
07:12 : sort of morphing my interface to be able
07:15 : to support
07:16 : the keyboard focus is going to require a
07:18 : big change so that's
07:19 : what i don't want this is an example
07:22 : that may not even be true
07:24 : maybe like it's fine the change is
07:27 : not going to be that bad even if i did
07:29 : it now but i don't know
07:31 : the point is i don't know and and
07:33 : sometimes it does happen it's like oh
07:35 : shoot i didn't realize that feature
07:39 : that comes later it's gonna mess
07:41 : everything up and now i have to
07:43 : redesign everything from scratch and
07:45 : then all this
07:46 : work i've done is wasted and so for that
07:50 : reason sometimes i decided to
07:52 : defer the extraction until i
07:55 : added that other feature that i'm
07:58 : worried about
07:59 : and then the code is still pretty
08:01 : straightforward
08:02 : but repetitive but at least i got
08:05 : everything working
08:06 : and now i can look at the big picture as
08:09 : a whole and try to come up with a better
08:10 : extraction i have an
08:12 : observation but i want to answer this
08:14 : for myself to me just like really simply
08:17 : in general when to the trigger
08:20 : is like you know what you need to do
08:26 : because i think maybe you guys agree
08:28 : with this i think implicitly
08:30 : we all agree right now that it's better
08:33 : actually to write
08:34 : naive code that's not abstracted than to
08:37 : miss
08:38 : on abstracting because it's actually
08:40 : more painful
08:41 : to have a bad abstraction than to have
08:44 : code that's written naively that we can
08:45 : then abstract once we realize
08:48 : what's going on and so that sureness
08:51 : of i see how i can make this better is
08:54 : like
08:54 : to me a great trigger for yes it's time
08:57 : to do it
08:58 : because maybe you guys have experienced
09:00 : this too like early on in development i
09:02 : remember so many times
09:04 : writing code and like writing an
09:05 : abstraction being like this is great i'm
09:07 : like never going to have to change this
09:08 : and then never using it and in fact it
09:12 : causing problems because
09:14 : you want to do something completely
09:15 : different with the same stuff and that
09:17 : abstraction is useless to you
09:18 : and it's dead weight and it's just
09:20 : mocking everything up
09:21 : yes yes that can also happen again that
09:24 : goes back to the
09:25 : how good are you at predicting the
09:27 : future but you're always
09:29 : too optimistic about your abilities you
09:32 : kind of have to
09:32 : learn it by doing it the hard way if you
09:35 : do it
09:36 : enough times you'll get a sense of yeah
09:39 : this is a slam dunk
09:40 : this is obvious that this is gonna make
09:43 : everything better and it's always it's
09:45 : also obvious that
09:47 : it's going to be stable because i've
09:49 : seen enough
09:50 : instances of these things coming in that
09:53 : i i can
09:54 : feel pretty confident about that for
09:56 : developers that are
09:58 : trying to develop this kind of skill i
10:00 : would say
10:01 : unfortunately you have to do it the hard
10:03 : way start with a straightforward way
10:05 : and then morph it i've seen a lot of
10:07 : developers
10:09 : really avoid that because
10:12 : once you get something working you're
10:14 : very reluctant
10:15 : to risk breaking that code but
10:17 : unfortunately that's what you have to do
10:19 : i see developers when i work with them
10:22 : they tend to want to
10:23 : just jump to the end solution like if i
10:27 : knew that i was going to end up with the
10:29 : extracted version
10:30 : why would i even write this plain
10:32 : straightforward version
10:34 : they just want to jump to the end you
10:36 : know
10:37 : i agree with your all your points yeah
10:39 : it's a trade-off again with
10:41 : many things in computer science it's a
10:43 : trade-off unfortunately
10:45 : i know people want a straightforward
10:47 : answer up front
10:49 : but we don't have it i still think too
10:53 : like
10:53 : everyone has that legendary developer
10:55 : you know wielding a keyboard in their
10:57 : minds and like it's not really
10:59 : that that developer doesn't refactor and
11:01 : that they abstract perfectly the first
11:02 : time to me it's more just like that they
11:05 : refactor at the right times and make the
11:08 : the correct choice in the moment which
11:10 : is not necessarily
11:12 : even doing anything special
11:14 : architectural like
11:16 : i just to me coming back to that as we
11:18 : talk about these concepts but
11:20 : the build up to them is just as
11:21 : important maybe even more important
11:24 : yeah developing skills for how to morph
11:27 : the
11:28 : code from the before into the after that
11:31 : takes a lot of skill
11:32 : because you are going to introduce bugs
11:34 : and you'll need to
11:35 : debug at some point how do you make that
11:37 : transition
11:38 : more smooth
11:41 : tdd is a one way yep