thisCodeSucks

 

and other tales of developer hubris...

Some back story

  • Front End Developer
  • full time ~5 years
  • self-taught / colleague-taught
  • no computer science background
  • mostly client side via API
  • django, jinja
  • Moontoast logo
  • Help fund it logo

Build the plane while flying






Technical Debt

Improving as a dev

Turning into a monster

Borderline obsessive about how I do things

This code suuuuuuuuuuuuuuuuuuuuuucks.

REFACTORING

I rewrite the whole damn thing.

Regressions, of course

When code that worked, doesn't anymore. Because of something I did. Probably.

Regressions are the worst

  • Unplanned for
  • Difficult to spot
  • Erode confidence in the whole team

Who is this talk for? Me.

 


What do I need to tell myself?

  • A few maxims worth repeating
  • How I decide if I should refactor
  • How do I refactor the right way to avoid regressions?



Just because I didn't write it, doesn't mean it sucks.




That line of code is probably there for a reason.






There is a difference between technical debt and code that just irks me.




What does it matter if
my code is perfect
but my software sucks?


Game time.


Should I refactor?

Scenario:

Swapping if / elif / else in favor of dictionary lookup.


if team == 'Falcons':
    odds = '100 to 1'
elif team == 'Patriots':
    odds = '3 to 1'
elif team == 'Titans':
    odds = 'maybe next year'
                                

super_bowl_odds = {
    'Falcons': '100 to 1',
    'Patriots': '3 to 1',
    'Titans': 'maybe next year'
}

odds = super_bowl_odds.get(team, 'Unknown team')
                                

Stack Overflow: "Better optimization technique using if/else or dictionary"

NO

Scenario:

Many of my dependencies are well out of date, some are unsupported altogether.


# requirements.txt
requests==0.2.0
                            

YES

Scenario:

I've created a generic utility function to replace code that's been copied and pasted in several places


def plus_one_week(dt):
    """
    Returns the given date plus 7 days.
    """
    return dt + timedelta(days=7)
                        

from ..utility.date import plus_one_week

# ...further down the page

        c = self.create(user_id=user.id,
            type='invitation',
            redirect_url=app.config['JOIN_LINK'],
            expires_on=plus_one_week(datetime.now()))
                        

NO, but...

Scenario:

A column in the database changes name. Change template context?


class BeveragesView(TemplateView):
template_name = 'drinks.html'

def get_context_data(self, **kwargs):
    context = super(BeveragesView, self).get_context_data(**kwargs)

    # leave the templates the same or change?
    context['drinks'] = get_beverages(self.request)
    return context
                            

YES




Scenario:

A view design changes dramatically

YES, but...

Scenario:


A function written by ex-employee is extremely complex and convoluted, but works without bugs

NO

Refactor the right way





Tests

  • If they're not there, write them
  • Forces you to understand the code deeply
  • Strong business justification for refactoring
  • Doubles as de facto documentation

head shot of Eric Elliott  Eric Elliott: "5 Questions Every Unit Test Must Answer"

Documentation

Write it all down

Be careful with refactor tools

  • grep - find via command line
  • sed - find and replace via command line and regex
  • PyCharm or other IDEs


Dedicate time to do it

(be transparent about it)

Easing your annoyance can be good for the business

Slides

http://russelljanderson.com/refactor-slides

me looking like a douche

Russell Anderson

Front End Developer, SimplyAgree

@RealRealRuss