📺 Develpreneur YouTube Episode

Video + transcript

Code Reviews - Part 3

2022-01-04 •Youtube

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. This episode focuses on tools and ways to help speed your review process through automation.

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]
of some some tools that are out there
for analysis
and i'm hoping i have those
um
so the first one i've got here is codec
i've actually talked about it before
this is a static analysis tool let me
blow this up so it's a little easier to
read
and what it does is you can come in
you've got um
i think here if i can go back to
oh there we go
oh my session timed out
of course it did
here we go okay
so each of these
line items is a code repository uh
almost all of the tools that i'm going
to point to while you can do a specific
analysis on a project
uh almost all of them especially the
cloud-based ones they're going to
connect to like github or bitbucket or
something like that or you're
if you've got an internal git server
that just tends to be everybody all the
cool kids are doing git and it's just
much easier to make
static analysis part of your code commit
process so you're going to see that in
these
one i'm not
including here
but
i do want to mention is also amazon has
got
code insight pieces and if you are
generating code through the
we'll call it the amazon process where
you're looking at their uh their
pipelines and their code commit
repository and things like that
there are
ways to attach static analysis into that
and their tools are actually are are
pretty impressive and are are going to
look somewhat like this i just didn't
want to get you know have too many
things that we spend time on as part of
this
so for this example we can see
um
i have a grade for these these are four
different repositories and i have a
grade and we can see i've got uh issues
and this these are percents i think
based on in this case it's gonna be
based on my last
um my prior commit
um
and then you can see there's like here
it's got a complexity score where do i
have duplicate code
uh if you have tests some of them will
be able to check uh test coverage so if
i look at one and open it up
and you're gonna see this in a lot of
these
i can look at this i can see that hey he
has this thing has this analysis has set
uh has found 54 total issues
i can see issues based on you know
there's unused code compatibility
performance error prod security coding
style
coding styles
very useful
because it gets into
best practices for code and particularly
uh for example if you look at things
that are
regularly moving forward uh react python
java c-sharp
languages that are still evolving on a
fairly common basis
one of the problems you run into is that
you have code that works fine
but there's a better way to do it
and you're going to see that in some of
the things that will come up as it'll be
stuff like um you know sometimes it's
simple things like hey i've got an
unused import those are kinds of things
that are easy to correct
sometimes you'll have um
[Music]
things that may be a problem like a
method has no argument
oh here's like an example break
statement may swallow an exception so
this is a case where you know maybe
there's a try catch and the way we're
doing it it's never actually going to
surface the exception
i'm trying to see
like here
you'll see stuff that's like hey this
method could be a function
um
and you're going to see stuff coding
style
like here redefining built in sum there
are things that you can do
that
it's going to offer you a better
way to do it i don't think i have a java
one here
to show that though but i may be able to
get that
let's see here
uh yeah because these are all well this
java this one may have some java in
there somewhere
yeah because this is old stuff so this
is probably gonna have that so i'm gonna
see and and security will do that as
well
and so some of it's things like hey
strings must use a double quote
um
i'm trying to see if that's all
javascript javascript javascript
uh
maybe i've got one with code patterns i
don't know if i've got any oh so here's
some code patterns thing uh oops that's
not what i want
sorry i clicked the wrong buttons
oh here we go let's see if i can do uh
code stop
and
um
let's do like java coding styles so
here's where
so here like static method name doesn't
match
this regular expression so things like
that that's basically going to say hey
this and it sometimes it'll give you
this it says hey configurable naming
this is what our this is what it should
be
this is what you typically should see
and so these are things that are not
coding issues as much as they're going
to be coding standards and most of these
tools also have the ability for you to
customize
some of that so that you can actually
introduce your own coding standards into
your static analysis and so now you've
got an automated code review that says
hey if you look if you did this if you
went through and coded it this way you
need to change it
in this other way
so codices a good example that as you
can see you know i've seen through this
you go through you can get an overall
grade those are your metrics
and so you can see from any given one
you can go take a look at it you can
take a look at your errors your issues
and these can be things that you can
either say yep i need to fix it or no i
don't um and this is a good example
right here where
you know error prone these are probably
bugs coding style are things where hey
this is going to help our
maintainability security may be
something that goes to your uh your
organization your industry and your
requirements there
so codec good example
uh let's go to uh this is sonar cloud
which is very similar to codec and
you're going to see this same kind of
thing as i've got these repositories out
there this one breaks it down a little
differently is i've got an overall score
on bugs but then also on vulnerabilities
there may be some hot spots
uh code smell which is basically it
doesn't
it's something where you're not
following standards and then duplication
of code
so you see that it's a little different
in how it breaks it down but at the end
of the day
you're seeing scores based on
varying areas it's usually going to be
things that are related to
bugs versus scalability versus main
teletainability versus stability
but you get to see all that
and then you can go
let's see this one yeah so this one i've
got these different repositories i'm
looking at
and i can go into a specific one and i
can start clicking my way into what are
the bugs that it sees and you're going
to see all of these that's through all
these tools that's a nice thing
okay here's the bug and then they're
usually going to have something like why
is this an issue why does this matter
and this is where you're going to be
able to become a better developer
because it's say hey these are things
you should avoid
so that's sonar cloud and each of these
tools has
some level of an introductory or free
tier to it and then as you get further
into it um
there may be some costs
if you're doing it for publicly
available uh github repositories you're
more likely to have a free it's a lot of
times it's free as long as it's a public
repo
if it's not then the
prices may be incurred and you're gonna
have to take a look at them
shift left is another in the same vein
of what we've looked at so far so here
you can see um
i don't know if i've got oh so i've got
like here i've got these different
applications
i can take a look into i can see overall
here's some issues it has
it's not so much a score kind of thing
as it's just a total findings but that
would be your metric because i want to
be
getting the point where i'm seeing less
and less of these ideally get it to zero
you know so i don't have any issues with
it
if you want to get
a little different
um you have pbs studio this one's not a
cloud kind of thing you're gonna
actually go in and you're gonna be able
to do static analysis on your code
it's a little different than what its
focus is this one's you know c c plus
plus c sharp and java
whereas the other ones will actually the
ones the ones i've looked at so far i've
reviewed or talked about they will also
do things like html css javascript uh
you've seen python
uh php perl
shell scripts i mean it's amazing what
is out there as far as what those things
you know what kind of code that those
things will
uh assess for you
pbs studios one if you want to have
something that's just a static tool that
you run
potentially a lot of times these are
these static tools are run as part of
your commit process you have a little
hook and you say okay when you commit
code it's going to trigger a
an assessment from the static analyzer
and you're going to be able to see where
the code changes are sometimes there are
ways to put um
sort of like barriers there that says if
your code doesn't have a certain score
or if it introduces more than x number
of issues then it's going to block it
and not allow you to commit the code and
that could be the number could be zero
i've worked with one customer where it
was an old
subversion repository that was linked to
several
static code analyzers and if you didn't
pass 100 your code would not commit
which can be
a pain if you're trying to commit code
you're trying to fix something and
you've gotta you gotta go back and cross
all your t's and doubt all your eyes but
the flip side of that is that means that
your code and your repository is
as squeaky clean as you can do from an
automated perspective doesn't mean bugs
won't get through but it does minimize
the chance for that and when you think
of continuous integration continuous
deployment
that can be very valuable it can be very
useful almost necessary
to be really certain of your code before
it flows into that process
a tool that
and we may have talked about way in the
past there's a company called parasol
that does
a lot but some of their products include
um
let's see if we can get these to pop up
again is that they do they have a lot of
testing related tools unit related test
tools to generate
uh auto-generate unit tests and create
code coverage uh test coverage over your
code but as part of that there's a lot
of static analysis that they have into
it the pricing is
usually going to be more it's more aimed
at enterprise development so this is
something that you're probably not going
to get as a individual developer
but it may be something your comp your
organization would want to look into
uh let me flip back over wherever i put
it to the actual presentation
so i wanted to show you those tools
because one
those are the kinds that almost every
one of them there's ways that you can
hook those into your process
and so now when we go back to the
code review costs some of that time
spent is going to be reduced because you
have these tools that say hey i can
i can look at your code and i can
already surface that without somebody
else having to take time to look at your
code and it reduces a human error yeah i
can if i review your code i could easily
overlook issues but if the system does
it's going to highlight those and say
hey you did this this matches this
pattern that we've decided is not a good
one so fix it you know or address it
and that
allows you to build a habit because
that's just part of it you've now
systematized and automated this process
and so while there are some of those uh
benefits
you're not going to get a lot of
cross-training by these static analysis
tools but
you are going to because
developers going to have these things
spit back issues they are going to learn
how to do they're going to through
habits and fixing those they're going to
learn how to do the code right at least
in line with your standards and maybe
the language standards
and so that can be maybe a piece of your
code review process that you do the
automation
but you also have the team take a look
at some of that and maybe even the team
take a look at what
is surfaced by the analysis tools and
you may say hey we want to adjust some
of those rules because the the tool is
telling us stuff that we don't want to
hear or that we've decided is a
non-issue
so what have we learned maybe and going
through this and one
code reviews can improve quality not
only of your code but of your
development team of your coders and your
coding team and your coding environment
there are definitely costs and
challenges that are associated with
starting into an environment where you
produce where you include code reviews
and make that a part of what you produce
in day to day
release to release
the key to success
is consistency and building habits if
you do a code review once in a blue moon
and just you know randomly code review
your code it's just not going to be
that effective you're not going to be
able to
build
the
exercise the muscles that are needed to
become better at a code review it's like
everything else the more you practice
the better you get
and this feedback environment that you
have in a code review is perfect for
that where you're doing this as a team
you're getting feedback on it
everybody's learning how to code better
but also how to review code better
and the other thing that final point is
there are a lot of tools that can help
us step into this we don't have to
manually code review every line of code
that we've generated
we can put these tools in place and even
if we don't have any person
actually do a code review if we just
leave the tools in place that is at
least a step in the right direction
[Music]
you
Transcript Segments
0.48

[Music]

26.48

of some some tools that are out there

29.679

for analysis

31.599

and i'm hoping i have those

36.719

um

37.68

so the first one i've got here is codec

40.079

i've actually talked about it before

43.36

this is a static analysis tool let me

45.76

blow this up so it's a little easier to

47.2

read

49.12

and what it does is you can come in

51.36

you've got um

53.76

i think here if i can go back to

59.199

oh there we go

60.8

oh my session timed out

64.64

of course it did

68.159

here we go okay

69.68

so each of these

71.84

line items is a code repository uh

74.32

almost all of the tools that i'm going

76.08

to point to while you can do a specific

78.799

analysis on a project

80.88

uh almost all of them especially the

82.4

cloud-based ones they're going to

83.439

connect to like github or bitbucket or

85.68

something like that or you're

88.4

if you've got an internal git server

90.32

that just tends to be everybody all the

92.4

cool kids are doing git and it's just

94.799

much easier to make

97.119

static analysis part of your code commit

99.36

process so you're going to see that in

102.079

these

102.96

one i'm not

104.479

including here

106.56

but

108.56

i do want to mention is also amazon has

110.799

got

112

code insight pieces and if you are

115.28

generating code through the

117.28

we'll call it the amazon process where

119.119

you're looking at their uh their

121.439

pipelines and their code commit

123.68

repository and things like that

126

there are

127.28

ways to attach static analysis into that

130.319

and their tools are actually are are

132.08

pretty impressive and are are going to

133.92

look somewhat like this i just didn't

135.599

want to get you know have too many

137.12

things that we spend time on as part of

138.959

this

139.92

so for this example we can see

143.36

um

144.319

i have a grade for these these are four

146.64

different repositories and i have a

148.16

grade and we can see i've got uh issues

151.44

and this these are percents i think

153.04

based on in this case it's gonna be

155.04

based on my last

156.879

um my prior commit

159.84

um

160.72

and then you can see there's like here

162.239

it's got a complexity score where do i

164.239

have duplicate code

165.84

uh if you have tests some of them will

167.28

be able to check uh test coverage so if

169.84

i look at one and open it up

171.92

and you're gonna see this in a lot of

173.12

these

174.239

i can look at this i can see that hey he

176.4

has this thing has this analysis has set

179.36

uh has found 54 total issues

182.239

i can see issues based on you know

184.159

there's unused code compatibility

185.84

performance error prod security coding

188

style

188.959

coding styles

191.599

very useful

192.879

because it gets into

197.36

best practices for code and particularly

200.239

uh for example if you look at things

202.48

that are

203.519

regularly moving forward uh react python

207.36

java c-sharp

209.68

languages that are still evolving on a

211.84

fairly common basis

214.08

one of the problems you run into is that

215.519

you have code that works fine

219.04

but there's a better way to do it

221.2

and you're going to see that in some of

223.04

the things that will come up as it'll be

224.64

stuff like um you know sometimes it's

227.04

simple things like hey i've got an

228.56

unused import those are kinds of things

230.72

that are easy to correct

232.72

sometimes you'll have um

234.75

[Music]

236.08

things that may be a problem like a

237.439

method has no argument

240.08

oh here's like an example break

241.439

statement may swallow an exception so

243.439

this is a case where you know maybe

244.64

there's a try catch and the way we're

247.12

doing it it's never actually going to

248.72

surface the exception

251.36

i'm trying to see

255.04

like here

256.32

you'll see stuff that's like hey this

257.519

method could be a function

259.519

um

260.88

and you're going to see stuff coding

262.16

style

263.28

like here redefining built in sum there

265.52

are things that you can do

267.36

that

270.24

it's going to offer you a better

272

way to do it i don't think i have a java

274.479

one here

276.08

to show that though but i may be able to

278.24

get that

279.919

let's see here

283.52

uh yeah because these are all well this

285.36

java this one may have some java in

286.8

there somewhere

289.12

yeah because this is old stuff so this

291.52

is probably gonna have that so i'm gonna

292.96

see and and security will do that as

295.04

well

298.72

and so some of it's things like hey

299.919

strings must use a double quote

302.24

um

304.16

i'm trying to see if that's all

305.199

javascript javascript javascript

309.6

uh

310.479

maybe i've got one with code patterns i

311.919

don't know if i've got any oh so here's

313.52

some code patterns thing uh oops that's

315.52

not what i want

320

sorry i clicked the wrong buttons

324.32

oh here we go let's see if i can do uh

326.56

code stop

329.6

and

330.56

um

332.08

let's do like java coding styles so

334.56

here's where

337.039

so here like static method name doesn't

339.84

match

341.68

this regular expression so things like

343.6

that that's basically going to say hey

345.199

this and it sometimes it'll give you

346.72

this it says hey configurable naming

348.479

this is what our this is what it should

350.479

be

351.199

this is what you typically should see

353.6

and so these are things that are not

356.4

coding issues as much as they're going

357.68

to be coding standards and most of these

359.84

tools also have the ability for you to

363.68

customize

364.96

some of that so that you can actually

367.039

introduce your own coding standards into

369.039

your static analysis and so now you've

370.88

got an automated code review that says

372.4

hey if you look if you did this if you

374.319

went through and coded it this way you

376.16

need to change it

377.84

in this other way

379.199

so codices a good example that as you

381.28

can see you know i've seen through this

382.96

you go through you can get an overall

384.24

grade those are your metrics

386.24

and so you can see from any given one

388.08

you can go take a look at it you can

389.759

take a look at your errors your issues

392.319

and these can be things that you can

394.16

either say yep i need to fix it or no i

396.4

don't um and this is a good example

399.6

right here where

401.28

you know error prone these are probably

402.72

bugs coding style are things where hey

405.12

this is going to help our

405.919

maintainability security may be

408

something that goes to your uh your

410.08

organization your industry and your

411.759

requirements there

413.28

so codec good example

415.599

uh let's go to uh this is sonar cloud

420.639

which is very similar to codec and

423.759

you're going to see this same kind of

425.12

thing as i've got these repositories out

427.28

there this one breaks it down a little

429.36

differently is i've got an overall score

432.08

on bugs but then also on vulnerabilities

435.039

there may be some hot spots

437.039

uh code smell which is basically it

439.919

doesn't

441.199

it's something where you're not

442.16

following standards and then duplication

444.319

of code

445.919

so you see that it's a little different

447.36

in how it breaks it down but at the end

449.199

of the day

450.479

you're seeing scores based on

454.24

varying areas it's usually going to be

456.639

things that are related to

458.319

bugs versus scalability versus main

460.28

teletainability versus stability

463.039

but you get to see all that

464.96

and then you can go

466.24

let's see this one yeah so this one i've

468.16

got these different repositories i'm

469.84

looking at

471.919

and i can go into a specific one and i

474.4

can start clicking my way into what are

476.4

the bugs that it sees and you're going

478

to see all of these that's through all

479.919

these tools that's a nice thing

481.84

okay here's the bug and then they're

483.68

usually going to have something like why

485.039

is this an issue why does this matter

487.039

and this is where you're going to be

488.08

able to become a better developer

489.84

because it's say hey these are things

491.52

you should avoid

494.639

so that's sonar cloud and each of these

496.879

tools has

499.759

some level of an introductory or free

502.96

tier to it and then as you get further

505.44

into it um

507.12

there may be some costs

509.12

if you're doing it for publicly

511.039

available uh github repositories you're

513.2

more likely to have a free it's a lot of

515.36

times it's free as long as it's a public

516.959

repo

517.839

if it's not then the

520.08

prices may be incurred and you're gonna

521.599

have to take a look at them

524.08

shift left is another in the same vein

526.959

of what we've looked at so far so here

529.04

you can see um

531.04

i don't know if i've got oh so i've got

532.24

like here i've got these different

533.279

applications

534.56

i can take a look into i can see overall

536.56

here's some issues it has

538.56

it's not so much a score kind of thing

540.64

as it's just a total findings but that

542.399

would be your metric because i want to

543.76

be

544.48

getting the point where i'm seeing less

545.839

and less of these ideally get it to zero

548.56

you know so i don't have any issues with

550.16

it

551.279

if you want to get

552.88

a little different

555.519

um you have pbs studio this one's not a

558.48

cloud kind of thing you're gonna

559.6

actually go in and you're gonna be able

560.72

to do static analysis on your code

563.44

it's a little different than what its

564.48

focus is this one's you know c c plus

567.12

plus c sharp and java

568.959

whereas the other ones will actually the

570.8

ones the ones i've looked at so far i've

572.959

reviewed or talked about they will also

575.2

do things like html css javascript uh

579.839

you've seen python

581.519

uh php perl

584.08

shell scripts i mean it's amazing what

586.399

is out there as far as what those things

588.48

you know what kind of code that those

590.56

things will

591.92

uh assess for you

594.56

pbs studios one if you want to have

596.16

something that's just a static tool that

597.6

you run

598.959

potentially a lot of times these are

600.56

these static tools are run as part of

602.48

your commit process you have a little

604.48

hook and you say okay when you commit

605.839

code it's going to trigger a

609.12

an assessment from the static analyzer

611.76

and you're going to be able to see where

612.8

the code changes are sometimes there are

615.279

ways to put um

618.32

sort of like barriers there that says if

620

your code doesn't have a certain score

622.88

or if it introduces more than x number

625.04

of issues then it's going to block it

626.8

and not allow you to commit the code and

629.2

that could be the number could be zero

631.279

i've worked with one customer where it

633.12

was an old

635.36

subversion repository that was linked to

637.76

several

638.8

static code analyzers and if you didn't

641.12

pass 100 your code would not commit

644.32

which can be

645.6

a pain if you're trying to commit code

647.6

you're trying to fix something and

649.279

you've gotta you gotta go back and cross

651.44

all your t's and doubt all your eyes but

654.72

the flip side of that is that means that

656.24

your code and your repository is

658.56

as squeaky clean as you can do from an

660.48

automated perspective doesn't mean bugs

662.24

won't get through but it does minimize

664.72

the chance for that and when you think

666.399

of continuous integration continuous

668.24

deployment

669.6

that can be very valuable it can be very

672.079

useful almost necessary

674.48

to be really certain of your code before

676.88

it flows into that process

680.8

a tool that

684.56

and we may have talked about way in the

686.56

past there's a company called parasol

688.72

that does

690.32

a lot but some of their products include

693.279

um

694.32

let's see if we can get these to pop up

695.6

again is that they do they have a lot of

697.76

testing related tools unit related test

700.48

tools to generate

702.56

uh auto-generate unit tests and create

706

code coverage uh test coverage over your

708.64

code but as part of that there's a lot

711.279

of static analysis that they have into

713.12

it the pricing is

716.639

usually going to be more it's more aimed

719.12

at enterprise development so this is

721.12

something that you're probably not going

722.56

to get as a individual developer

726.16

but it may be something your comp your

727.6

organization would want to look into

731.2

uh let me flip back over wherever i put

733.92

it to the actual presentation

736.88

so i wanted to show you those tools

740.24

because one

741.68

those are the kinds that almost every

743.36

one of them there's ways that you can

744.959

hook those into your process

747.2

and so now when we go back to the

750.8

code review costs some of that time

753.04

spent is going to be reduced because you

754.56

have these tools that say hey i can

756.8

i can look at your code and i can

758.16

already surface that without somebody

760

else having to take time to look at your

761.68

code and it reduces a human error yeah i

765.12

can if i review your code i could easily

768.16

overlook issues but if the system does

770.56

it's going to highlight those and say

771.68

hey you did this this matches this

773.519

pattern that we've decided is not a good

775.279

one so fix it you know or address it

779.04

and that

780.079

allows you to build a habit because

782.079

that's just part of it you've now

783.76

systematized and automated this process

787.04

and so while there are some of those uh

789.36

benefits

790.72

you're not going to get a lot of

791.76

cross-training by these static analysis

793.92

tools but

796.079

you are going to because

798.32

developers going to have these things

799.6

spit back issues they are going to learn

802.959

how to do they're going to through

804.16

habits and fixing those they're going to

805.839

learn how to do the code right at least

807.92

in line with your standards and maybe

809.839

the language standards

811.839

and so that can be maybe a piece of your

814.48

code review process that you do the

816.079

automation

817.36

but you also have the team take a look

819.6

at some of that and maybe even the team

821.76

take a look at what

823.199

is surfaced by the analysis tools and

826.16

you may say hey we want to adjust some

827.76

of those rules because the the tool is

830.48

telling us stuff that we don't want to

832.16

hear or that we've decided is a

834

non-issue

838

so what have we learned maybe and going

840.72

through this and one

842.72

code reviews can improve quality not

844.639

only of your code but of your

846.24

development team of your coders and your

848.56

coding team and your coding environment

851.519

there are definitely costs and

853.12

challenges that are associated with

856.079

starting into an environment where you

858.079

produce where you include code reviews

860.88

and make that a part of what you produce

862.8

in day to day

865.04

release to release

867.279

the key to success

869.199

is consistency and building habits if

871.92

you do a code review once in a blue moon

874.639

and just you know randomly code review

876.56

your code it's just not going to be

879.04

that effective you're not going to be

881.04

able to

882.48

build

883.44

the

884.72

exercise the muscles that are needed to

886.8

become better at a code review it's like

889.199

everything else the more you practice

890.56

the better you get

892.32

and this feedback environment that you

894.88

have in a code review is perfect for

896.72

that where you're doing this as a team

898.48

you're getting feedback on it

900.56

everybody's learning how to code better

902.16

but also how to review code better

905.68

and the other thing that final point is

907.36

there are a lot of tools that can help

909.04

us step into this we don't have to

911.68

manually code review every line of code

913.76

that we've generated

915.92

we can put these tools in place and even

918.399

if we don't have any person

920.88

actually do a code review if we just

922.56

leave the tools in place that is at

924.88

least a step in the right direction

929.44

[Music]

944

you