This morning our coding best practice guru made us do our first coding dojo. I had no idea what that was, for me “dojo” vaguely referred to a javascript library. But actually, “dojo” is the Japanese word for the place where students practice their martial art. So by extent a coding dojo is a coding exercise where devs practice their code. Aha!
Principle
The principle is simple. There is a computer connected to a screen that everyone can see and all the devs are organized in circle around it. Then, given a problem to solve, the goal is to code the solution by switching turn in the coding seat. The person coding is called the pilot, and there must be a person beside her called the co-pilot who helps and guides her. Every pilot has 5 mn to code. During that lapse, the other devs comment and discuss alternative solutions or ways to do things differently, but in the end the coder does as he thinks.
Benefits
It’s a great way to share practices and see how everyone approaches the problem, it gives you ideas. It’s also interesting to see how everyone codes, where they put braces etc. for example today I discovered you could comment a line with # in php, I didn’t know. This morning’s problem was a basic problem (the Fizz Buzz test), so there was nothing spectacular, but our guru said that most of the time dojos usually provoke a lot of debates. Funny.
Topic
Anyway this morning’s subject was how to implement tests before coding something. Basically it goes 1. write the test ie the goal you want to achieve 2. code 3. refactor. The test is supposed to drive the way you code. So you write the code that the test requires you to write, for example to react to an error the test threw. I more or less already did that : write the goal, how I want to call my function and then build up from there, I think it’s a good method to keep things clean. Our guru insisted that testing is the engineering way to make sure that what you produce is stable and solid. It’s kind of what makes the difference between crafted software and engineered software. Tests == engineering method.
Feedback
My impression was that it’s not easy to follow all the discussions, and live coding is a bit stressing because suddenly you follow the collective logic instead of your own logic. Adrenalin.
Even if interesting, for now I don’t see how the testing method can apply to web development. The web is very much about formatting data, both on the back and front ends, I don’t really see what tests could apply. Well, I will probably see in a near future.
As a conclusion, this exercise was fun.
Posted in Discoveries, Devsworld
