Side effects of trying to understand a large codebase - Henk Doornbos (PyGrunn conference)¶

Tags: python, pygrunn

Since a few months he’s head of paylogic’s architecture department. So obviously he had to learn all about the existing codebase. What does it? What’s infrastructure? What’s front office, what back office?

To get an idea, he ran sloccount over the codebase. Mostly 84k lines of python code. 560 meter of code, printed out :-)

Becoming familiar with such a codebase takes some doing. You can look at the components, the classes, the features and in the end the code. A good way to get started is by looking at bug reports and feature requests and figuring them out. (They use fogbugz as a bug reporting system, btw).

He digged into a specific bug and had to check by hand in the website whether the issue was fixed already. So he started thinking about automating the tests. What if we use the robot framework with selenium? And describe the bug reports in the language needed by robot? Normally a ticket already includes the steps needed to reproduce and the expected result, right? That would effectively make the the bug reports executable!

With robot framework you can write reasonably understandable lines like:

Given I go to the backoffice customer 12345
And I order a new xyz
And I set the country to France
Then I should not get an error 500

Parts of those sentences then have to be configured in robot framework. They’re basically macros. “And I order a <param 1>” is a macro that executes a couple of selenium commands.

In the end, a bug report often really expresses a missing requirement. What we now have with these executable bug reports are automated acceptance tests for those requirements.

What he wants: requirements expressed as proper user stories:

• To have some fun (the reason for the action)

• as a customer (the actor)

• I want to buy a ticket. (the actual action)

He wants this format as it forces you to write down an actual reason. Without a reason, there’s no business value. Without value, the requirement should not be implemented. And it forces you to be clear about the actual actor.

Conclusion: requirements can be written such that the customer understands them, developers can implement them and machines can understand them.