It is well known that good development practices make it possible to speed up software production while guaranteeing a high level of quality. However, to be fully effective, they must be tailor-made, i.e. they must fully correspond to the organisation (individual, team, company) that implements them.

The definition and dissemination of good practices are therefore two major challenges !

However, this can still be very difficult to achieve. Indeed, who hasn’t tried to set up the Wiki of good practices … only to realise a few months later that nobody reads it.

ProMyze proposes a new approach dedicated to this issue. This approach, fully integrated in the Themis workshop, consists of 3 main steps:

1. The definition of good practice
2. Facilitating the implementation of good practices
3. Wide dissemination of good practice

1. Definition of good practice

What is a good practice?

It is impossible to give a rigorous definition of what constitutes a good practice. Indeed, good development practice comes from the experience of many developers and the feedback they provide. They can be found in blog articles, books on programming, conferences, etc.

It should be noted that the good practices that we integrate in these Craft Workshops are not smells codes automatically identifiable by qualimetry tools such as SonarQube. A human assessment is absolutely necessary.

Moreover, a good practice can be agnostic or on the contrary depend on a programming language or framework:

• Agnostic: e.g. the fact that the methods are well named and that their intention is clearly explicit in their name (Clean Code practice).
• Specific to a particular language or framework: e.g. to favour the use of components rather than guidelines with Angular (Angular practice)

Finally, a good practice is often context-specific (project or organisation). The main objective is to improve productivity and quality. This can be achieved, for example, by using frameworks in very specific contexts (e.g. “using the bootstrap component for modals”), but it is still a goodpractice for your context.

A first set of good practices

With the help of several experts, ProMyze proposes a first set of good practices. These practices have been selected because, in our experience, they regularly appear in many teams as basic good practices.

We have built this set to serve as an example for the creation of your good practices. Don’t hesitate to appropriate those that correspond to your context and set aside those that are more distant from your concerns.

Who in your organisation can/should define good practice?

Usually it is an internal technical leader or an external consultant who will help define your best practices.

However, seniority should not be the only element to be taken into account. Indeed, junior developers can also bring a fresh perspective to the team and introduce new development practices.

Finally, depending on the context, the teams are more or less autonomous in defining their good practices and development conventions.

Generic rules can be defined at company level, but each team usually has the opportunity to refine its own set of good practices by adding those specific to their context.

At ProMyze, we are convinced that the definition of good practices is everyone’s business. Consensus building should be the rule in order to maximize developers’ adherence to practices that they will have to implement or respect on a regular basis.

In concreteterms, how do we creategood practices?

Themis offers the “Good Practices” page which allows you to create new good practices.

Each good practice has a list of categories. A category represents a context in which the practice applies (“javascript”, “angular”, “projectA”, etc.) or the topic addressed (“Testing”, “SOLID”, “Archi”, “DDD”, etc.).

The advantage of having these practices in Themis and not in a wiki page is that we will bring them to life with the Craft Workshops. As a result, the developers will have real actions with these practices, which will allow them to evolve more regularly and to spread them much more easily.

2. Animation and implementation of the good practices in our code

As soon as it is defined, a good practice must be alive, i.e. it must be implemented by developers in their projects. To animate this implementation we propose the Craft Workshop.

Thanks to Themis, it is possible to create a Craft Workshop to animate the implementation of good practices. The objective is to organise sessions to ensure that the good practices are well applied and even to challenge and evolve them.

A Craft Workshop focuses on one or more projects. It is also linked to a periodicity (monthly, sprints, etc.) which will allow to start sessions (one session per period).

The following figure shows the Craft Workshops page. It shows a workshop (Atelier JS) on the Libra project, which is held monthly. Currently 3 developers participate in this workshop.

When you enter aCraft Workshop, you take part in the session. in progress (that of the month, the sprint, etc.). Each participant can enter the session whenever he or she wishes (no need to be synchronised with the other participants).

We enter a session in workshop mode. The objective is to question the implementation of good development practices. More concretely Themis will propose files and ask to identify places in the code where good practices are not applied.

The following figure shows a session in which Camille participates. It can be seen at the top of the screen that Camille is in workshop mode. The screen shows one of the files that has been proposed by Themis. The list of good practices is on the right hand side of the page and can be filtered by name or categories.

Camille can place good practices on the code (“drag&drop” mode). In the figure, we can see that three good practices have been placed on the code.

It is possible to click on a good practice placed on the code to access its description and especially to add a comment. The other participants will see this comment and will be able to respond to it.

Comments are used to indicate suggestions for improvement or to discuss the specific point raised where the good practice has been applied. It is also a good time to modify the practice or why not even create a new one. The following figure shows the window displayed when Camille clicked on one of the good practices added to the code.

Once completed, you can switch to review mode. In this mode, you can see the good practices identified by the other team members. These appear in lighter blue on the file.

It is on this page that we can see which good practices we did not identify but which other participants identified. We can then discuss with these participants to better understand their motivations and the reasons why they have filed these tags. These interactions consolidate our interpretations of good practice and ensure that the whole team is well aligned with it.

3. Dissemination of knowledge on these good practices to the whole team

Once the whole team has been able to identify the good practices in the code, it is possible to take stock with everyone to identify which practices have been most identified over the period. This is the last mode, the Summary.

This page gives the team a good picture of the practices which, once integrated, will allow us to improve the quality of the code.

Above all, it creates an exchange within the team by highlighting the strongest areas for improvement of the moment.

By clicking on the Per User view, you will be able to see which participants have identified the different good practices.

This view makes it possible to identify who has the knowledge about the different practices and to capitalise on this by offering people who have identifiedpractices unknown to others to explain them. Feedback can be made on the files to present these practices in a concrete way in the code.

An exchange session with the team on this view can be done within 15 minutes in each period.

During these sessions, it is also possible to create new good practices or challenge existing ones. Conducting these workshop sessions on recent code allows to focus only on practices that make sense in the team’s current context. Old practices implemented on legacy code are therefore not questioned here. It is the future that is targeted.

Conclusion

Each person in a development team has his or her own knowledge and perspective on what Clean Code is all about. However, there has to be consistency within a team.

The primary goal of this Craft Workshop is not to make corrections in the code that has already been produced but to disseminate all the good practices so that each developer integrates them into his development habits to continually improve the quality of the future code produced.

“What’s important in a team is not its current level, it’s its propensity to improve.”

Benoit Gantaume