Write More Durable Code: Principles and Techniques

ortussolutions 201 views 13 slides Jun 27, 2024
Slide 1
Slide 1 of 13
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13

About This Presentation

This workshop focused on simplifying programming decisions with key coding principles. Participants learned to avoid clever code, apply inversion of control, prefer composition over inheritance, write self-documenting code, use encapsulation, reduce nesting, avoid reassignment, and implement guard s...


Slide Content

INTO THE BOX 2024
Principles and
Techniques to Write
More Durable Code

ORANGE ROOM
PRESENTED BY
Jacob Beers
Writing Durable Code

Jacob Beers
SPEAKER IN ITB 2024
Jacob is a Senior Developer at Ortus Solutions, Corp. While he has been working as a
programmer for the past 10 years he never intended to make a career out of it. His professional
journey thus far has been marked by a diverse set of pursuits including 3d animation, game
design, fine art, special education, and operating a survival swim school. He likes to think his
unusual combination of experiences provides him with a unique and pragmatic approach to
software development.
Relatable Facts

●Programmer
●Approximately 70% water
●Likes the band CAKE
●Wife and 3 kids
●Rides a tandem bike
recreationally

INTO THE BOX 2024
Why this topic?
Opinions get a bad rap - they are the seed of
something greater!

●The purpose of an opinion is to make decisions more
efficient
●A bad opinion makes making bad decisions more efficient!
●They are data and knowledge based on prior experience
●We need to convert our opinions into principles and wisdom

We aren’t usually breaking new ground!

●Maybe not concretely but definitely abstractly
●Their opinions and principles can become productivity
multipliers for us
●Better opinions might help us cry less

●Regardless of how your code looks
you know it does what it was
tested for
●Greatly improves the rate at which
you can make future changes
INTO THE BOX 2024
Principle - Write Automated Tests

The Problem Our Approach The Result
●You have regressions
●The application is missing
features that were part of the
requirements
●The code is hard to change
without breaking things
●Prefer integration tests over unit
tests if possible
●Start with high priority tests
●Make them part of your CI or
manual release process - they will
never get run otherwise
●Marathon not sprint - try to create
a cadence each week to improve
your test coverage

INTO THE BOX 2024
Principle - Iterate to Innovate!

The Problem Our Approach The Result
●The problem domain feels
complex and overwhelming
●Solving one problem seems to
break another part of the system
●Solutions don’t seem to simplify
the problem only add to it
●Leverage the power of SMALL
iterations - not sweeping rewrites!
●Pick your most important or most
fundamental requirement and
solve it first in isolation
●Use // TODO comments to create
“savepoints”
●Apply Git liberally, when it doubt hit
it with the branch hammer
●Hard problems become simple - or
at least manageable
●You do better work when you focus
one problem at a time
●Avoid endlessly redesigning the
same system and never improving
it

●Greatly simplifies and strengthens
your code
●Once you have used the means at
your disposal to fully unnest (down
to one level) your code it is usually
bulletproof or easy to patch up
●Makes you feel like a boss

●Second level problem - requires a
collection of solutions
●Guard statements
●Don’t re-assign variables
●Try not to use else
●Adhere to FP/OOP paradigms
INTO THE BOX 2024
Principle - Reduce Nesting With Vengeance

The Problem Our Approach The Result
●Over-nested code is the root of
many evils and can be very
difficult to refactor
●Usually couples code that could
be separated and simplified
●1 level of nesting is fine - 2+
levels should be immediately
refactored
●Bonus points if you never use
else statements!

INTO THE BOX 2024
Principle - Know Your Paradigm OOP vs FP

The Problem Our Approach The Result
●The code is long, complex, and
inflexible
●Lots of copy/paste
●All the code is artisanal
●Learn OOP and FP - learn it again
if you think you know it!
●Don’t try to write perfect code on
your first try
●Write your code however it comes
naturally to you and then ITERATE
towards a pattern
●It isn’t real until you git commit &&
git push
●Leverages the language of design
patterns (This is the Strategy
Pattern! I know how it works!)
●Catch bugs/missed requirements
earlier
●Come up with solutions you
wouldn’t have thought of before
getting into the weeds

●In JavaSCript only use `const`
●In CF only use… your imagination!
(We can’t use `final` ?????? )
●When you feel yourself about to
reassign a variable
○Write a new function to return
what you need
○Use an array and map/join
INTO THE BOX 2024
Principle - Avoid Reassignment

The Problem Our Approach The Result
●Reusing a variable leads to
confusing code with hidden
gotchas
●When combined with overnesting
this can lead to very sneaky bugs
or even vulnerabilities
●Forces you to rethink your code
flow and separate concerns
●Clarifies the intent of your code for
others and/or your future self

●Comments are well named
functions, variables, or objects in
disguise
●If it doesn’t add value - delete it!
●Some humorous comments can be
acceptable IMO


INTO THE BOX 2024
Principle - Promote Comments to Executable Code

The Problem Our Approach The Result
●People don’t always read
comments
●We have to mentally connect
comments and code together in
order to understand them
●Often comments are redundant -
see bullet point #1
●If “naming things” is a hard part of
programming this is a cheat code
●Makes your code self documenting
●Forces colleagues to read what
you wrote
●Can reinforce the idea that
comments are worth reading -
every comment should either be
read or refactored!

INTO THE BOX 2024
Let’s Refactor Some Code
●The best time to refactor is while you
are writing (remember to iterate!)
●Prefer refactoring over rewriting 99%
of the time
●It takes practice - don’t pressure
yourself by trying to be perfect on
your first attempt

INTO THE BOX 2024
Wrapping Up
Next Steps
refactoring.com
by Martin Fowler
Out of the Tar Pit
github.com/papers-we-love
by Ben Moseley and Peter Marks
Resources
●Write some automated tests!
●Go read Martin Fowler’s book and
website. His stuff is awesome!
●Checkout Papers We Love and
specifically Out of the Tar Pit.
●Pick a technique/principle and try it
out - see if it is helpful to you.

INTO THE BOX 2024
THANK YOU TO OUR
SPONSORS
INTO THE BOX 2024