— Apprenticeship — 3 min read
I wrote this post more than a year ago on medium and I decided to move it to this blog.
We have been training in Lean Mind performing the word wrap kata with Carlos. We have done the kata using TDD (Test Driven Development). The first thing we did was to solve the kata each one on our own and then we did mob programming with Carlos to solve it in different ways and he was explaining it to us. We have done this kata recursively, using loops and finally using value objects. In that way we can compare between the different solutions we have obtained.
The Word Wrap Kata consists of implementing an algorithm to split a text string that exceeds a given column width. Just like word processors that split by lines when we have exceeded the column width.
We were talking among ourselves about the different business rules. Then, we proceeded to sort out a list of some of the possible tests we wanted to do depending on their difficulty:
1TODOS2
3 "hello", -2 -> Throw an exception (Negative column width is not considered)4 "", 1 -> ""5 null, 1 -> ""6 "hello", 7 -> "hello"7 "hello", 2 -> "he\nll\no"8 "hello world", 7 -> "hello w\norld"Below I attach the repository with my resolution for this kata:
https://github.com/JuanAntonioQ/word-wrap-kata
I have also decided to write down here recommendations that Carlos made to us when we were solving the kata.
When you write code you are making a commitment to the people who will read it later. You have to take into account that the code does not get worse from one day to the next. People who are working on it can make it worse day by day if they do not care about what they are doing.
One thing that is very useful is to increase the IDE font size during programming sessions. This way we force less the views and also we can set a column width limit and we can prevent to extend too much the code horizontally.
It is very important to give good names. We have to care about the names we use for variables, objects and functions. They must respect the context of the problem and be consistent. Do not name a concept in different ways.
Documentation should never explain how the code works. Suppose two years have passed since a project was started and comments were put int. If someone changes the functionality of a method, but does not change the comment, then the comment is obsolete and also not consistent with what the code says it does. That is why code should never be explained. We can use comments, but we should use them to document the context of decisions (What for, why, why not).
Principle of Least Surprise/Astonishment, your code should behave as you expect it to behave. We must prevent our functions do something that they are not expected to do. The function name should reflect what it does.
Pair programming and mob programming are very important. Doing a kata using pair programming or mob programming allows you to discuss with your peers different approaches and also allows you to bring up cases that you might not otherwise consider.
Other important concepts discussed during the kata were the following:
I plan to do a post on each of the above topics to go more in depth.
This training that we have done using the word wrap kata has brought value to each member of the team. It has helped us to review concepts and learn others that we did not know. A kata has to be repeated many times. First you solve it one way, then another way and so on. In this case for example, we have solved the kata first in a recursive way, then using loops and finally using Value Objects. Doing it several times and in different ways allows you to compare later. You can also vary or complicate the kata. For example, the word wrap kata could be solved first taking into account the spaces and then without taking into account the spaces. Anyway, many thanks to Carlos for giving us so much value during the realization of this kata and to all my colleagues for their contributions.