As promised, the continuation of Code of Principles is here. This time I’m going to talk about stuff that is less canonical and perhaps not so well known. Today’s motto is that you are not alone. There are strangers, psychopaths, users, fellow developers and good scouts out there.
Don’t talk to strangers
Let’s discuss Law of Demeter also known as Principle of least knowledge. Proposed in 1987 by Northeastern University, can be informally described in four bullet points:
- You can play with yourself (naughty boy).
- You can play with your own toys (but you can’t take them apart).
- You can play with toys that were given to you.
- And you can play with toys you’ve made yourself.
Which basically means that object should assume as little as possible about its environment, surroundings, its structure, properties and anything else, especially about internal structure of objects it’s manipulating. Classic violations of this rule are chains of invocations like this: a.getB().getC().doSomethin().getD().doSometingElse(); By the way, such style poses additional problems when resolving exceptions. Can you tell which invocation threw one exactly? Code following Law of Demeter tends to be more maintainable and adaptable. Following it strictly has some disadvantages however, like introducing time and space overhead needed to facilitate wrappers and auxiliary access methods.
(P)rinciple (o)f (L)east (A)stonishment
Also known as (P)rinciple (o)f (L)east (S)urprise. Often used in context of user interfaces from the ergonomics standpoint, along with (D)o (W)hat (I) (M)ean rule coined by Warren Teitelman in the sixties. Regarding user interfaces, people have experience, expectations and mental models. Design should reflect that in being the least surprising as possible. This also applies to code. You should construct things in a way that are intuitive, obvious, consistent, predictable and boring, based on the thing name, location and other clues. Try to leverage existing techniques, standards and conventions as much as possible. What if your project already violates those? Well it depends, if it’s easy to fix, just fix it. If it’s harder, nag your Product Owner for budget to do it. If it’s too hard to fix, follow the bad conventions. Bad conventions are usually better than no conventions at all.
Write Code for the Maintainer
“Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.” This is somewhat connected to the previous rule. Usually, code is written once and then maintained for a long time. Even if your creations brilliantly fulfill the Open Closed Principle, and don’t need to be modified, still someone has to understand what should be added where to achieve desired result. Think of people who are new to the project and will have to update your code, can they easily do that? Will you be able to do that after a year? When I was working longer on single project I had situations where after finding myself in some strange and scary place I would thought “What kind of moron wrote this crap? Hmm… oh… it was me a year ago…”. Don’t make me think too much. It hurts my brain.
Also, Brian Kernighan once said: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it”. Keep that in mind.
Boy Scout Rule
Boy Scout refactoring should be safe and small, and/or it should happen around the code you are working with. I remember the situation when I walked happily into my manager’s office saying “you know what, I threw away that crappy piece and written it from scratch nicely!” and instead of joy I saw grim face and heard “I didn’t ask you to do that…we have budget and stuff…”. I had to explain in details that I was building upon that change and I can deliver things faster now, and it was safe and good thing in general. If you spot a bigger refactoring opportunity outside of scope of your current task (say more than one hour of coding, depending on your team’s work agreement, deadlines, sprint tension and all such things), don’t rush into being good Boy Scout, ask your Product Owner if it’s okay and add it as a separate story to sprint. Remember, we are not here for the sake of art (unfortunately) but to fulfill our client expectations. We can shape those expectation too of course.
Think before you commit. Do they know where you live? Should you be scared if they do? Don’t worry, stick with the dragon blog and you will be fine ;)