3 4 QA Manager

Release Manager for 3.4 Proposal

Improving The Quality of Koha's Code

Koha has the potential for major growth in the future. To unlock that potential it needs to utilize its code base positively. At present the code is a very heterogeneous collection reflecting the history of the system in a period when many of the technologies it uses have changed rapidly. We need to improve the quality of our codebase to enable growth and encourage and enable contributions from new developers.

Modern Perl

Try to promote the approaches that can be subsumed under the heading 'Modern Perl', a more idiomatic and efficient way of writing perl for reuse.

Cleaner Interfaces

Many of the core modules have procedures with long lists of parameters (both mandatory and optional) and return multiple return values. It can be error-prone it also forces a user of these routines to read and understand the contents of the routine to use it (and sometimes to rewrite it in a routine of their own). A consistent, reliable and understandable interface to e.g. borrowers makes new developments easier and less bug prone. A borrower object abstracting the database table enables easier assembling of tasks using it.

We also need to encourage separation of database I/O, Template manipulation, and processing logic. In some modules the three are so intertwined as to be a serious barrier to comprehension let alone enhancement.

Make the logic clear

A lot of our code is not divided up into logical chunks, it is in long deeply indented if else statements. It needs breaking up, variables need their scope localized, it needs to clearly show what its flow is and limit its unseen side effects.

Remove The Cruft

There are a number of subroutines and variables lurking about in the code that are not used. They are obstacles to understanding and we should be removed.

Refactoring

The system is of a size that without actively addressing the quality of our existing code base, it gets worse as we add to it. We need to build a more extensive testsuite so that we can refactor effectively and better evaluate what the code (actually) does. We are hoping in 3.4 to enable important changes like enabling mod perl, template toolkit and database independence, we will need to refactor to some degree as part of enabling these developments, we should also be doing it to improve the tools in our toolkit.

Finish The Good Intentions

Among the aims of the current release cycle were things like 'enable warnings in all modules' that's still to be achieved. Its a fairly modest aim and its important we complete it. In some areas I think it revealed there was quite a bit of cleanup required. Developers should be able to apply those simple, automatic tests to their code.

Document

There are various bits and pieces on the wiki. If there are rules we want to encourage we need a short, succinct listing of these. We should be adding to the developer wiki pointers to good practice (either within koha or in other sources). Good examples are what we need most. As part of refactoring some areas in the code we should be able to produce functional documentation of use to implementers.

We are a multi-lingual, worldwide community. We also operate in field which has its own specialist terminology (not always that consistent even within the one language). I'd like to make a start on a file of terminology (traditionally called a jargon file), so that we have a reference of what we are talking about (this can be especially treacherous in fields like acquisitions). This might well be useful for translators too.

Koha 3.4 roles

Complete list here.