This question already has an answer here:
My company has a fairly large software project (a couple million lines of code spread across many assemblies.) One sticking point we've consistently run into during code reviews has been with the use of shared classes. We have various classes in a shared assembly used for solving common problems that occur throughout our code. These classes might do things like formatting a name or exporting a file - operations that we need to repeat in various places throughout the program.
We frequently have to fail code reviews because programmers are not aware of the shared classes available to them, leading them to reinvent the existing class. For example, a programmer might not know that there is a class designed to export a file to our specifications, so they write their own more-specific version. This becomes even more of an issue if the shared class was created recently, and isn't used in too many places yet. More junior programmers spend a lot of time reinventing wheels while doing tasks that, with full knowledge of the shared assemblies, would have been relatively simple.
What are some techniques we might try for spreading knowledge of these shared assemblies? Typical code documentation seems insufficient here, since the issue is with knowing whether a class exists in the first place. Are there good ways to document shared assemblies that would allow programmers to quickly answer the question of "Does a class already exist in our code that does x"? What can we do when adding a new shared class to let developers know about the class and encourage its continued use?