How to avoid duplicate code and functionality in a large project?

Question

Programming

What if more than 15+ people from different companies work in the project, naturally there is no communication between them, only the code for the merge branch, this is all that connects them. And sometimes it is not clear whether something is already ready to solve a particular problem. You sit and do, and then you find already deep in the project something that already solves the problem, you just had to use it.
How then to organize the work?
How to find out if they have done, is there already a similar functionality in the service?
Is it done right?
How to find it?
How to avoid duplicate code and functionality?

Answer 1

By the standards of large projects, 15 people is a small project.
1. First, you need to use one of the development methodologies. Scrum is great for distributed teams and refactoring. All developers will be aware of everything.
2. Use the issue tracker. Jira is a great option.
3.workflow . _ All steps should be regulated from setting a task and creating its PM to closing its QA after testing. This will prevent parallel execution of the same task. You also need to regulate the rules for naming branches and commits in Git and their merging.
4. Communicate. Slack- a great messenger for distributed teams. Google Meet - for calls.
5. Correct, transparent architecture and use of frameworks. No bikes in serious projects. Otherwise, it will be extremely difficult to support the project. With a good architecture, a developer will know where to check for the presence of a component, utility, and so on, before adding the desired functionality himself. This, together with points 1, 2 and 4, should completely exclude duplicates.
6. Documentation. Use Apiary to document APIs . Advantages of Apiary - fast, efficient, standardized and understandable.
Write documentation on environment setup, project setup, and workflow for new developers.
There is no point in documenting features, components and application modules when using popular frameworks, otherwise you can get a ton of irrelevant and illiterately written documentation, on which developers will also spend a lot of time.
If you need reference materials for users, serious multilingual documentation for a customer, or a product description for investors, hire a technical writer.
7. Code review - fronts check the code on the front, backs on the backend, mobile developers on mobile phones, etc. PRmerge only after a sufficient number of approves (eg 3). So developers will not only be aware of everything that happens with the project on their part, but will also learn from each other and use the same approaches to solve similar problems.
8. Toolkit: precommits, linters, autotests, etc.
9. Optionally, division into teams.

Answer 2

No way.
The developer culture and the lack of race will ease the problems with this.

Answer 3

To achieve the consistency of the system, an architect is needed - a person who has a systemic vision of the system.