Taming the Technical Debt

Github // brittanystoroz

Twitter // @brittanystoroz

What does a debt-riddled codebase look like?

• Styling inconsistencies (whitespace, commenting, casing)
• Outdated/vague documentation
• Little or no testing
• Uninformative/noisy commit history

1) Makes it difficult to get readable diffs with extraneous styling changes. 2) Way more time trying to figure out how to work with the codebase, making deadlines even tighter 3) Bug prone; no clear definition of app intentions 4) No explanation for why code was written/what it was intened to do; tough to look back

function pointsToAward(questionPosition, inputVal, correctVal) {
  var points_earned, plus_seven, plus_three, plus_one;
  switch (questionPosition) {
    case 2:
      plus_one = (parseInt(inputVal) >= (parseInt(correctVal) - 5)) ? 1 : 0
      plus_three = (parseInt(inputVal) >= (parseInt(correctVal) - 3)) ? 3 : plus_one;
    break;
    case 10:
      plus_one = (parseInt(inputVal) >= (parseInt(correctVal) - 3)) ? 1 : 0
      plus_three = (parseInt(inputVal) >= (parseInt(correctVal) - 2)) ? 3 : plus_one;
    break;
    case 18:
      plus_one = (parseInt(inputVal) >= (parseInt(correctVal) - 7)) ? 1 : 0
      plus_three = (parseInt(inputVal) >= (parseInt(correctVal) - 3)) ? 3 : plus_one;
    break;
  }
  plus_seven = (parseInt(inputVal) === parseInt(correctVal)) ? 7 : plus_three;
  points_earned = (!parseInt(inputVal)) ? undefined : plus_seven
  return points_earned;
}

This is NOT technical debt if a, b, c & d.Hacky code like this isn't technical debt, it's a part of life. Sometimes you have to write bad code. Sometimes you write bad code but you don't know it's bad.

So What Is Technical Debt?

• Technical debt is a symptom of poor planning around preventing & fixing hacky code.
• Technical debt is a process problem - a workflow problem - not a skills, laziness or deadline problem.
• Technical debt is a sign of not using the right tools.

We shouldn't *have* to think about these things.

Oh just make a style guide.

Post it somewhere in the depths of your internal admin.

and that's exactly the problem...nobody is going to find it, nobody is going to follow it. jsbeautifier can take care of a lot of these styling issues - we'll talk about that a little more later - but what about something like how you comment your code? what makes it easier for people to follow conventions without having to memorize them or reference something all the time? (show jsdoc snips, autodoc generator). snippets are mostly marketed for how quickly they make certain tasks but I like them because they're a quality thing too. you know your comment styling is always going to be on par when you have a package autocompleting it. create an internal package for ST2/whatever text editors your team uses that conforms to the style standards you guys set

Write your tests.

They must be important. It seems everyone would just *die* without them.

that said, here's an example of a test pg live in prod. and guess what, NOBODY is dead. writing tests is a LUXURY. which is why we're all so adamant about telling people to write them. for those of you who dont write tests because you dont like to, I'll say that again, writing tests is a LUXURY. like diamonds. never take for granted the time you have to write tests. BUT. if you truly DONT have time to write them, like if you work at the NYT, what is to be done? show stubbing out tests example with st2 plugin - have them scream things out at me to test. so this is my version of taking notes. don't take notes with a pen and paper. we are not in the 1800s. stub your tests. also useful about this is if you don't have time to write tests, you're probably not thinking much about documentation. no readme? no autodoc? this IS your doc. even if you dont write the tests, describing them is half the battle anyway. when you do build your project, and get back to cleanup - go back to your unwritten tests first. will force you to refactor code that's probably already on your to-do list.

Learn how to use git.

Not just the push, pull, branch, add, commit, merge, stash bits. The even better bits.

git is one of my fave things. ive found a lot of ways to use it and also abuse it. couple things i'll touch on here. at the times, unconventional use of git. i used to be really strict about my diffs and my commit messages, but on deadline, its impossible to worry about such things.

f.e. a couple weeks back i was doing superbowl coverage with some of my teammates. and the git history started off pretty good, you know, affirmative case messages, all starting capitalized, no ending punctuation. then the game started. and things started getting hectic. there is no time in our environment for pull-requesting during the game or working on develop and merging into master, it's working on and pushing straight to production for 3-4 hours straight. so now what? we're left with a really sloppy, noisy commit history in master that we have to live with. here's the thing...

You don't always have to deploy from master.

Pre/Post Commit Hooks

• Takes care of styling inconsistencies so we don't have to
• Ensures everyone is committing with the same settings
• Easy to add/remove & update

Links & Such

• ST2 JSDoc Snippet
• Creating Custom ST2 Snippets
• Using Git Hooks
• Command-Line Github Issues
• My twitter feed that is mostly bad jokes