This post is part of a series of 7 blog posts on the topic How to create a learning culture for software development teams:
Wikis are tools for sharing and centralizing knowledge within an organization. They are often generic and used beyond the Tech professions, such as by sales, marketing, HR teams, etc…
Confluence or Notion are among the solutions most commonly used. Some teams prefer to use the Wiki tools integrated into GitLab or GitHub. We can find several types of content in those tools:
These wikis are free to access, and their collaborative nature means that each person can, in theory, contribute to enriching the knowledge base. Although these tools embody a wealthy knowledge base, with practice, several limitations are observed:
If they are efficient to centralize knowledge, wikis have certain limitations if you want to tailor them fully to the context of a development team. And this phenomenon is even more accentuated if we consider that it takes place in each team if we are in an organization of several tens or even hundreds of teams!
These tools have several objectives: to detect potential defects, and vulnerabilities automatically, Code Smells, non-compliance with specific standards, and to provide an overview of these problems on a project. They are mainly used at two levels:
Highlighting best practices when they are not followed has an educational side. A person who does not know a given rule will be warned: this instant feedback loop helps developers to get appropriate with coding rules.
One must also be aware of certain limitations with these tools. They are generally based on low-level syntactic rules, and will sometimes be inefficient to detect high-level patterns. A solution such as Promyze can address this issue by providing the ability to highlight such rules, which in some cases are impossible to identify automatically. Also, these tools need to be configured upstream with the project context, at the risk of seeing many false positives. Finally, the audited practices must also be well documented to help developers understand how to solve an identified problem.
Linters should be seen as a support for teams, able to cover a defined spectrum of problems in the code. They should not be seen as the only support that can ensure the team’s code quality. Bad code can slip through the cracks of these tools!
Promyze, the collaborative platform dedicated to improve developers’ skills through best practices sharing and definition