How do you organize the development of a complex product?

Question

Programming

The point is this.
Recently, for the first time, I started working in a team developing a large project. by "large" I mean a lot of features, whistles and other things.
The project develops in iterations and features pile up and the code, of course, is not the most elegant and easy to understand and analyze.
In general, the problem is that after each sprint, I see that testers find heaps of bugs, which we then work together for 3-4 days. Because you are asked to add or fix feature A, you fix it, but along the way, you may break feature B explicitly and implicitly C (there may be an error when working with C and C). Some things, especially from domain, are covered by tests, but everything cannot be covered, and the logic is complex and the code is legacy in places.
So, in theory, it seems to me that it is possible to organize development in such a way that there are a minimum of these bugs. What do we have to do? more tests? Is it more careful to make changes to the code and check everything 100 times? Or to reconcile, "so at all"?

Answer 1

The project develops in iterations and features pile up and the code, of course, is not the most elegant and easy to understand and analyze.

Tests, TDD, refactoring, SOLID. And then there is no pain. But this, alas, is far from being met on every project.
Read books on refactoring, try to isolate changes. If you need to fix a method to fix a bug and you don't know what will happen to other places in the code, then move this method to another class or simply duplicate the method. We fixed the problem - we eliminate duplication, etc. And of course, it would be nice to write tests for things that you edit, at least functional ones, in order to reduce the number of regressions.
Bugs are good, regression bugs are bad, they are an indication that something is wrong with our code. Reducing the number of bugs is easy - more tests are needed, taking into account various invariants. But sometimes it's redundant, and it's easier to just catch and fix the bug.
I also recommend that you familiarize yourself with the practices of extreme programming, where a lot of attention is paid to feedback from the moment when the developer broke something until the moment the problem was discovered (pair programming, TDD).

Answer 2

Cover your code with tests. You will immediately see what has fallen off after each commit.

Answer 3

Business process diagram, modularity and documentation for each module.
Joints of modules should be marked on the diagram, modules themselves should be highlighted.

Answer 4

In general, it looks like you have a few problems in your team.
Firstly, either there are problems with the architecture, or the development plan is incorrectly drawn up. This may be due to ignoring the limitations of agile. It seems to me that there is both.
Secondly, programmers are not strongly motivated to write quality code, or do not have the opportunity to do so. Perhaps they do not have a domain model, and, correcting one bug, they immediately introduce a new one. It makes sense to think about the specialization of specific developers (or small groups of developers) in specific areas. Try breaking up a large project into several separate "isolated" projects, each of which should treat related subprojects as external systems. Each subproject needs its own team. This will make the project manageable and understandable to all participants.
And then, I agree with Sergey Protko , "Tests, TDD, refactoring, SOLID".

Answer 5

high code coupling, run

Answer 6

Apparently in your project:
- the code is highly connected
- tasks are performed by everyone in parallel, no one has their own components
- perhaps the sprints themselves are not quite logical, due to changing requirements
- perhaps you are not given time for refactoring, but require so that some kind of task or fix is ​​always executed.
All recommendations were given above, but it is also worth thinking about refactoring modules in the first place, then cover them with tests.