Graphinder – Code review yourself


Few words of self reflection

After working a little on my side projects, I’ve found myself lacking a lot of code reviews. Or any sort of reflection on one’s code.
Often side projects are meant to be fun and focused on teaching oneself some new technology, new concept or just on simple proof of concept. Or made just for fun. But doesn’t mean it’s meant to resemble Swiss cheese. It’s quite the opposite.
Side project is where your code should shine.
Even if you tend to work in less Agile workflow (while (Waterfall) { fail++; }), you are mostly exposed to some sort of comments on your code. Sometimes somebody will come over to you with a bag of questions about your code. Sometimes you’ll find out you’d write it other way round. Alright, more than sometimes. But that’s not the point.
The point is that you have some sort of feedback.

Code review yourself

To fight back and to strive for better quality of code, I’ve forced myself to do annual Self Code Review.
You’d ask – how the hell? You’ll mostly lack feedback, because you’re the one, who gave birth to this little monster meant to be reviewed.
That’s actually not entirely true though.

Thinking over through many possibilities I’ve decided to go with behavior that would be closest to my natural way of reading the code.

Few steps to consider:

  • First of all, find an hour once a – let’s say – two weeks
  • Start from the point where you’re now in development. Let’s say, I’m in middle of Controller and View for one of my IAlgorithm in Graphinder. Let’s go down the whole pipeline, down to the very backend.
  • Now, let’s start going up, to middle end, to front end. Attempt to understand any method/property/field you’re going through in a process just by looking on a docs summary, method/property/field name or looking inside the body of each. Do you understand what it does or what it describes? Do you think it’s error-proof? If yes, that’s great – proceed. If not, you should do a quick reflection here.
  • Reflect on what is missing here. A quick docs summary? Maybe decomposition is necessary? Maybe you highly doubt it wont’ explode if you pass IDestroyerOfWorlds as param here? Or maybe name of the functionality is ambiguous? Or maybe it just doesn’t belong here and breaks SRP?
  • Decide on action that comes next: shall I document it properly now? Maybe. Should I refactor it now? Time is your judge. Should I postpone it then? It depends.
  • I believe that attempt to make code perfect at once tends to build up a lot of work and stops the progress of the project itself.
    While I also believe, that every project should work in a first place and then look beautiful, compromise is not an easy choice here.
    My advice would be to choose what you urgently need to fix (make it up to 2-3 pieces of code at most) and do it at once.
  • If you encounter the bug, always attempt to fix it before going back to writing new code. But that’s basics. That’s what should always be done when you find out bug.
  • Make sure, that every other thing that you’ve left behind is marked for future fixes. Make a goddamn //TODO {stuff we mostly don't come back to}. Acknowledge the fact, that some sort of refactor is needed here. Do yourself a favor and put it in some Scrum/Kanban/whatever board. I use Trello and love it. And I’m only user of my board. And I don’t care – as long as my workflow is being somehow organized.
  • Never trust code you see. Test it! It applies to every piece of code. Yours is the one you should probably trust the least. :)

Alrighty. We’ve got a few things we should go through here to make a few steps into direction of perfection.
But that’s only once a two weeks. Wouldn’t it be impossible to actually review all of that? Of course it would.
However, such approach made me behave a little differently when approaching my own code (and others’ too) at work (and everywhere else).
Whenever I come back to code written by myself or someone else, I try to reflect for a second or two on it.
I no longer feel afraid to put a big, bad //TODO in someone’s code and even put a card on a board with a task of making things right.
Of course mostly I bash my own code with wall of TODO‘s but I also tend to acknowledge others what smells just not right. Kindly, of course. Making enemies in our team is a bad idea from the very start, isn’t it? :)

As for growing up pile of TODO in your project, I’ll soon write a article about my upcoming TODO session.
Depending on how it goes. ;)

Other news

I’ve decided to introduce Continuous Integration for this project.
You can notice current status of last build every article’s menu, just below the logo. CI is provided by great amazing guys from AppVeyor @ https://ci.appveyor.com/. If you’re writing an app in C# and write unit tests (if you don’t then @&#!^#!&*^#!&* – do so!), you should definitely give it a try. It’s G-R-E-A-T.

2 thoughts on “Graphinder – Code review yourself”

  1. I must say – I can’t find self-code-review useful for myself. Why? I need some time (let’s say 1-2 month) to get out of my memory what I meant in “this” piece of code. Otherwise, my “fresh-in-mind-solution” prevents me to find spaghetti snippets.

  2. Well, it always depends on a person. To be honest during my self code reviews I tend to understand or recall what I meant but I also try to be that other person and think: would I really get what does it do? :)

Leave a Reply

Your email address will not be published. Required fields are marked *