Detailed Notes
Code reviews are starting to become more common in enterprise development. Dev Ops and related automation have helped shine the light on improving quality and reliability in our processes. This presentation looks at how we can set our teams up for success in code reviews through better and consistent processes.
Code Reviews In Detail There is a time and place for code reviews. Likewise, there are ways to approach these complex tasks that can make the most of both our time and resources. Nevertheless, this process does not come without cost. Therefore, we need to be intentional in our approach and requirements to craft better code and provide a path for building better developers.
The Mentor-Mastermind Group This series comes from our mentoring/mastermind classes.  These classes are virtual meetings that focus on how to improve our technical skills and build our businesses.  The goals of each member vary.  However, this diversity makes for great discussions and a ton of educational value every time we meet.  We hope you enjoy viewing this series as much as we enjoy creating it. As always, this may not be all new to you, but we hope it helps you be a better developer. Drop us a line to find out when the next one is so you can join our group.
Transcript Text
[Music] so costs i've been very positive on on code reviews and i that is definitely i'm you know truth be told that is the purpose of this presentation but there are costs and you have to understand those you have to take those into account because there is a there's a there's a give and take and in a given environment or a given solution it may be that the costs are higher than the benefits uh they outweigh the benefits of the code review and a lot of times that may be because of the the structure or the timing of your code review so think about and while we're doing this we go back to the oops code review points um where did that go oh here we go if you go to these like if if you do your code review you could do it on code command before you deploy part of a release and as a retrospective so there could be multiple points where you're reviewing code you could technically actually review code the same code multiple times depending on how you do stuff i recommend against that but those are the kinds of things where where your code review points are those will impact how to some extent they may magnify or minify some minimum minimize some of these code review costs now the first and the probably the most obvious is your time spent if you add a code review into your process that time is going to be added into your process it's there's no ifs ands or buts that's like pure physics at that point if you are going to say we're going to do code reviews that takes time therefore that time is time that your resources could have spent doing other stuff it may be time that you're tacking on before a release but bottom line is there's going to be a cost of time and depending on how you do your your code reviews it could be the cost of for example like say you've got a 10 person team if all 10 people are involved in every code review the whole team is spending that time if you have it set up so only let's say two or three people are involved in a given code review then that's going to change your cost a little bit so it needs you need to be aware of it but also realize that there are process things you can do that can help adjust for those at least to take that account to some extent and maybe minimize the cost or at least at least make it easier to swallow uh slower quote slower code deployment and that is because typically we're going to do a code review after we've written code so somewhere from the writing code to the deployment step we're going to enter we're going to put in a code review process and that's going to slow the deployment because at some point we're waiting for code reviews to be done and waiting to go through the code review process before you deploy that one if you just wait until after a deployment and do your code review you could avoid that particular cost but that does mean that you're going to be slower to start your next deployment cycle so you're just sort of shifting time it's still going to slow that down something that i'd it goes back to the personal view of your code it can you can end up in a situation where you're basically doing defensive programming and this is where sometimes this goes back to sometimes the the value of uh this is what you know sort of the cathedral versus bizarre and stuff like that sometimes a single person is going to be a little more comfortable with maybe we'll say like the 80 20 rule that they're they're gonna they can get in they can write their code they see the problem they see a solution you're done but when you open that up to review when you have a committee or other people that are now taking a look at that then their varying levels of risk acceptance may change what is acceptable for that code and this would be defensive programming is that you can get into conversations where you are trying to take into account outliers that almost never happen and so you end up spending a lot of time trying to address a situation that almost never happens and that maybe is not that big a deal sometimes you look at stuff and it is in the long run better to allow the application to crash once in a blue moon when all you have to do is restart it as opposed to spending hours and hours reviewing the code adjusting it and trying to check for a bunch of situations that may not occur particularly if those checks are a cost to that process every time it's run and if you think on a big scale think of like batch data loads or exports probably load is more commonly something where if you're loading millions of records and each record you want to go in and do a bunch of checks to make sure if all of the values are valid and that they're unique within the system and things like that you may have to but in a lot of cases you don't not at that point anyways so instead of the cost of all of those validations being part of the import process you can put them somewhere else where they do not multiply because of just the number of records you're dealing with you know more simpler uh maybe a more simpler example that's why when you do triggers in a database it's often you know and in some similar kinds of things it's or actually any real transaction you want it to be as minimal as possible if you're locking stuff up because you want to minimize the time that you are locking the data that you're working with it sort of makes sense the cost from a code review with this defensive programming is that sometimes you may overthink a solution and you end up providing you know the the maserati when you could have gotten away with ikea it's you know not to be besmirch any of those products but to just say that you know sometimes we over architect our solution and code review can sometimes lead to that so that's something that has to be considered as part of your your environment and how you approach a code review is to try to do it so that you don't end up in this sort of defensive programming approach to solving problems and also that you just don't overthink your solutions the code review itself has a cost but preparing for a review looking to review documenting it just the mental switch to go from writing code to reviewing code there's a cost for that and so you you want to make sure you factor that in uh just like anything else just you want to make sure that when you're trying to get to the bottom line of is this going to cost more than it's worth fully thinking through what what are all the things that impact the cost what is it what is the true cost of this so now that all of that being said let's talk about how do we do this and maybe build a habit so it all comes down to attention to details that's really what a code review is is it's we're not going to just write code and throw it over the wall and see what happens it's we're going to write code but we're going to really we're going to take a you know write it take a moment take a deep breath take a look at it maybe make some adjustments and then move forward so if you want to build a habit the first thing is you've got to start somewhere so pick a place and set a process this may be personal it may be something where you're just i mean you couldn't even do this with yourself it's just a personal code review i'm going to write code but i'm going to go back and take a look at it before i move it forward in an organization it's much more once code gets to point a whatever that's going to be that's going to be our code review checkpoint then we're going to say there's this process that is code review and we're going to put that into place if you're a development shop that already exists then you want to do that really for the new changes to code you don't want to try to go back and code review you know millions and millions of lines of code you don't want to try to go back and code review all that stuff you start by saying okay we didn't do a code review in the past so the next second best time to start it is now and so we're going to pick a point and we're say we're going to start this in any new code we're going to we're going to do a code review process and that's that could be newly written code or even changes to code is that we're going to and changes to code can be far reaching so we're going to have to talk a little bit about scope of what is included in that code review because it could be that you want change five lines of code in a file that has 10 000 lines of code in it and you don't necessarily want to go back and code review all of that uh this that's probably an argument to not have a file that has 10 000 lines of code in it but that's an argument for a different day so start by saying all right we're going to code review changes when there's code changes we're going to do code reviews moving forward you want to build into that process a a flow to a code review that makes it easy to surface and address corrections and updates you want to have it be something where you can go through a code review there is a very well-defined list of of changes agreed upon changes and then it's essentially a continuation of that process to assign those changes back to the developer developer can change them you can have a sort of a a shorter code review process like a a verification code review that says yep you made these changes i'm i'm good with that maybe do a quick look to make sure that nothing else changed as part of that and then that flows forward and now your your code is reviewed it will help immensely to have some sort of metric or set of metrics that you can use to measure your progress uh we're going to talk a little bit about some of the tools that can provide these things that are essentially there they're roughly scores on your code so you can take a look at it and you can see over time hopefully how your scores get better this may also be things that are much more bottom line driven it may be customer acceptance scores it may have to do with bug reports it may have to do with system downtime all of those things and actually the more the better the more metrics you have the more details you have to look into what was life like you know sort of a baseline of what was it before we did the code reviews and what is it after we do the code reviews because even though we've looked at all these pros and cons and costs and and value the bottom line metrics for your organization are going to be the best measure of how does this work for us and is it working for us because if it's not it may be that it's not going to work at all it may be how you do it but it's like everything else if you don't measure it then it's going to be really hard to figure out how to change it and improve it once you get these things into place there's a point where it would be useful and you may want to be able to is maybe use some tools or automated tools or something like that just because of the time required and go back and review your legacy code and again some of the tools i'm going to point you to are great ways to do this is you can go back and look at stuff that you wrote last year 10 years ago in a different language whatever and see how they stack up and and you may want to go through and improve that older code as well try to make some changes and and figure a way to get that to have a better uh so you have like a better baseline essentially and then as you're going through this the bottom line at the end you sort of get down to it and you say all right we're doing these things we've made some changes we're making corrections we're measuring this we've even looked at some of our legacy code you're going to be able to improve so as you start building that data up take a look at those metrics take a look at where you can maybe make improvements you may even be able to do sort of a b testing make some improvements and see if that affects the metrics in the way that you want it to and it may be that you change your process and suddenly the metrics look worse so maybe it's time to examine that process and say what did we change that maybe caused this problem or if you see within those metrics depending on how detailed they are you may be able to see where there's there are strengths and weaknesses to what you do and so you maybe look at how can we offset some of those weaknesses in our process and i know these are a little vague as far as the details of the code review itself but that really does come down to uh beyond bugs are sort of easy like everybody it doesn't work it doesn't work we've got to fix it but when you get down to coding standards and maintainability uh also requirements in certain certain industries you know like if you're in healthcare or finance there are your code review is different there are certain things that are that you're going to have to take in account that take into account that you wouldn't otherwise if i write a little app that's a i don't know a to-do list app there's a whole lot of stuff i don't have to deal with if you write a little app that is talking to a doctor and exchanging personal health information there's a lot of stuff that you have to do for that to be legal you know to avoid fines and things like that so your industry and your uh even the way really your leadership of your it group can greatly impact what a code review really needs to be so those are things that you have to unfortunately you can have some guidelines again some of the tools we're going to look at and provide you some baselines for that but your organization itself needs to know what it needs in order to do it right so look at it you
Transcript Segments
[Music]
so costs i've been very
positive on on code reviews and i
that is definitely i'm you know
truth be told that is the purpose of
this presentation but there are costs
and you have to
understand those you have to take those
into account
because there is a there's a there's a
give and take and in a given environment
or a given solution
it may be that the costs
are higher than the benefits uh they
outweigh the benefits of the code review
and a lot of times that may be because
of the
the structure or the timing of your code
review
so think about and while we're doing
this we go back to the oops code review
points
um where did that go
oh here we go
if you go to these like if if you do
your code review you could do it on code
command before you deploy part of a
release and as a retrospective
so there could be multiple points where
you're reviewing code you could
technically actually
review code the same code multiple times
depending on how you do stuff
i recommend against that but
those are the kinds of things where
where your code review points are
those will impact how to some extent
they may magnify or minify some minimum
minimize some of these code review
costs now the first and the probably the
most obvious is your time spent
if you add a code review into your
process
that time is going to be added into your
process it's there's no ifs ands or buts
that's like pure physics at that point
if you
are going to say
we're going to do code reviews that
takes time therefore that time is time
that your resources could have spent
doing other stuff
it may be time that you're tacking on
before a release
but bottom line is
there's going to be a cost of time and
depending on how you do your your code
reviews it could be the cost of
for example like say you've got a 10
person team
if all 10 people
are involved in every code review
the whole team is spending that time
if
you have it set up so only let's say two
or three people are involved in a given
code review then that's going to change
your cost a little bit
so it needs you need to be aware of it
but also realize that there are
process things you can do that can help
adjust for those at least to take that
account to some extent and maybe
minimize the cost
or at least at least make it easier to
swallow
uh slower quote slower code deployment
and that is because typically we're
going to do a code review after
we've written code so somewhere from the
writing code to the deployment step
we're going to enter we're going to put
in a code review process
and that's going to slow
the deployment because at some point
we're waiting for code reviews to be
done and waiting to go through the code
review process before you deploy
that one if you just wait until after a
deployment and do your code review
you could avoid that particular cost but
that does mean that you're going to be
slower to start your next
deployment cycle so
you're just sort of shifting time it's
still going to slow that down
something that i'd
it goes back to the personal
view of your code
it can
you can end up in a situation where
you're basically doing defensive
programming
and this is where sometimes this goes
back to sometimes
the the value of
uh this is what you know sort of the
cathedral versus bizarre and stuff like
that
sometimes a single person is going to be
a little more comfortable with maybe
we'll say like the 80 20 rule that
they're they're gonna they can get in
they can write their code they see the
problem they see a solution
you're done
but when you open that up to review when
you have a committee or other people
that are now taking a look at that
then their varying
levels of risk acceptance
may change what is acceptable for that
code
and this would be defensive programming
is that you can get into conversations
where
you are
trying to take into account outliers
that almost never happen
and so you end up spending a lot of time
trying to address a situation that
almost never happens and that maybe
is not that big a deal
sometimes you look at stuff and it is
in the long run better to allow the
application to crash once in a blue moon
when all you have to do is restart it as
opposed to spending hours and hours
reviewing the code adjusting it and
trying to check for a bunch of
situations that may not occur
particularly if those checks
are a cost to that process every time
it's run
and if you think on a big scale think of
like batch
data loads or exports
probably load is more commonly something
where
if you're loading millions of records
and each record you want to go in and do
a bunch of checks to make sure if all of
the values are valid and that they're
unique within the system and things like
that you may have to
but in a lot of cases you don't not at
that point anyways
so instead of the cost of all of those
validations being part of the import
process you can put them somewhere else
where they do not multiply because of
just the number of records you're
dealing with
you know more simpler uh maybe a more
simpler example
that's why when you do triggers in a
database it's often
you know and in some similar kinds of
things it's or actually any real
transaction
you want it to be as minimal as possible
if you're locking stuff up because you
want to minimize the time that you are
locking the data that you're working
with it sort of makes sense
the cost from a code review with this
defensive programming is that sometimes
you may overthink
a solution and you end up providing you
know the the maserati when you could
have gotten away with ikea it's you know
not to
be
besmirch any of those products but
to just say that you know sometimes
we over architect our solution and code
review can sometimes lead to that
so that's something that has to be
considered as part of your
your environment and how you approach a
code review is to try to do it so that
you don't end up in this sort of
defensive programming approach to
solving problems and also that you just
don't overthink your solutions
the code review itself has a cost
but
preparing for a review
looking to review documenting it
just the mental
switch to go from writing code to
reviewing code there's a cost for that
and so you you want to make sure you
factor that in
uh just like anything else just you want
to make sure that when you're
trying to get to the bottom line of is
this going to cost more than it's worth
fully thinking through what what are all
the things that impact the cost what is
it what is the true cost of this
so now that
all of that being said let's talk about
how do we do this and maybe build a
habit
so it all comes down to
attention to details
that's really what a code review is is
it's we're not going to just write code
and throw it over the wall and see what
happens
it's we're going to write code but we're
going to really we're going to take a
you know write it take a moment take a
deep breath take a look at it
maybe make some adjustments and then
move forward
so if you want to build a habit
the first thing is you've got to start
somewhere
so pick a place
and set a process this may be personal
it may be something where you're just i
mean you couldn't even do this with
yourself it's just a personal code
review i'm going to write code but i'm
going to go back and take a look at it
before i move it forward
in an organization it's much more
once code gets to point a whatever
that's going to be that's going to be
our code review
checkpoint
then
we're going to say there's this process
that is code review and we're going to
put that into place
if you're a development shop that
already exists
then you want to do that really for the
new changes to code you don't want to
try to go back and code review you know
millions and millions of lines of code
you don't want to try to go back and
code review all that stuff
you start by saying okay we didn't do a
code review in the past so the next
second best time to start it is now
and so we're going to pick a point and
we're say we're going to start this in
any new code
we're going to we're going to do a code
review process and that's that could be
newly written code or even changes to
code is that we're going to and
changes to code can be far reaching so
we're going to have to talk a little bit
about scope
of what
is included in that code review
because it could be that you want change
five lines of code in a file that has
10 000 lines of code in it and you don't
necessarily want to go back and code
review all of that uh this that's
probably an argument to not have a file
that has 10 000 lines of code in it but
that's an argument for a different day
so start by saying all right we're going
to
code review changes when there's code
changes we're going to do code reviews
moving forward
you want to build into that process a
a flow
to a code review
that makes it easy to
surface and address
corrections and updates
you want to have it be something where
you can go through a code review there
is a very well-defined list of
of changes agreed upon changes
and then
it's essentially a
continuation of that process to
assign those changes back to the
developer developer can change them you
can have a
sort of a
a shorter code review process like a
a verification code review that says yep
you made these changes i'm i'm good with
that maybe do a quick look to make sure
that nothing else changed as part of
that
and then that flows forward and now your
your code is
reviewed
it will help immensely to have some sort
of metric
or set of metrics that you can use to
measure your progress uh we're going to
talk a little bit about some of the
tools that can provide these things that
are essentially there they're roughly
scores on your code so you can take a
look at it and you can see over time
hopefully how your scores get better
this may also be things that are much
more bottom line driven
it may be customer acceptance scores it
may have to do with bug reports it may
have to do with system downtime
all of those things and actually the
more the better the more metrics you
have
the more details you have to look into
what was life like you know sort of a
baseline of what was it before we did
the code reviews and what is it after we
do the code reviews
because even though we've looked at all
these pros and cons and costs and
and value
the bottom line metrics for your
organization are going to be the best
measure of how does this work for us
and
is it working for us
because
if it's not it may be that it's not
going to work at all it may be how you
do it
but it's like everything else if you
don't measure it then it's going to be
really hard to figure out how to change
it and improve it
once you get these things into place
there's a point where
it would be useful and you may want to
be able to is maybe use some tools or
automated tools or something like that
just because of the time required
and go back and review your legacy code
and again some of the tools i'm going to
point you to are great ways to do this
is you can go back and look at stuff
that you wrote last year 10 years ago
in a different language whatever
and see how they stack up
and and you may want to go through and
improve
that older code as well try to make some
changes
and
and figure a way to get that to have a
better uh so you have like a better
baseline essentially
and then as you're going through this
the bottom line at the end you sort of
get down to it and you say all right
we're doing these things we've made some
changes we're making corrections we're
measuring this we've even looked at some
of our legacy code
you're going to be able to improve so as
you start building that data up take a
look at those metrics
take a look at where you can maybe make
improvements
you may even be able to do sort of a b
testing make some improvements and see
if that affects the metrics in the way
that you want it to
and it may be that you change your
process and suddenly the metrics look
worse
so maybe it's time to examine that
process and say what did we change
that maybe caused this problem
or if you see within those metrics
depending on how detailed they are you
may be able to see where there's there
are strengths and weaknesses to what you
do and so
you maybe look at how can we
offset some of those weaknesses in our
process
and i know these are a little
vague
as far as the details of the code review
itself but
that really does come down to
uh beyond bugs are sort of easy
like everybody it doesn't work it
doesn't work we've got to fix it
but when you get down to coding
standards and maintainability
uh also requirements in certain certain
industries you know like if you're in
healthcare or finance
there are your code review is different
there are certain things that are
that you're going to have to take in
account that take into account that you
wouldn't otherwise if i write a little
app that's a i don't know a to-do list
app there's a whole lot of stuff i don't
have to deal with if you write a little
app that is talking to a doctor and
exchanging personal health information
there's a lot of stuff that you have to
do
for that to
be legal you know to avoid fines and
things like that so
your industry and your
uh even the way really your leadership
of your it group can greatly
impact what a code review really needs
to be so
those are things that you have to
unfortunately
you can have some guidelines again some
of the tools we're going to look at and
provide you some baselines for that
but your organization itself needs to
know what it needs
in order to do it right
so look at it
you