How to write big projects?

Question

Backend

good night. Now I started writing an application, with a bunch of settings. Well, for example, I chose 1 element, it affects the following actions, if you choose another element, then there will already be other values ​​in subsequent actions. Or, like in games, I chose the level of difficulty, or buying weapons that have different characteristics, and this also affects the following actions. I thought how it is to write everything in a literate way. Experience in such projects 0. What can you advise, suggest, show.

Answer 1

Generally speaking, the design of large systems is a whole large branch of the science / technology of programming, which is quite clearly distinguished from programming in general, does not depend much on other sections, and is being intensively developed. There are different approaches and different more or less established technologies, even standard technological processes. Special intellectual tools (see eg UML) and corresponding software tools are used. There is, actively used and developed many typical design solutions for different occasions - design patterns (aka patterns), the knowledge and use of which speeds up the process and reduces the likelihood of unsuccessful decisions - see for example. Gamma, Helm et al. - "Object Oriented Design Techniques - Design Patterns". There are various approaches to organizing the design process itself. This science (program design) is closely related to business organization, many common approaches are used (in particular, BPML, the brother of UML, is used in business process design)
So it's hard to answer your question in two words. Think, draw diagrams, google, read something on these topics (at least start with Wikipedia - https://ru.wikipedia.org/wiki/UML) , try to use something at least partially in your work.
Any programmer should get to know these topics at least superficially, but if you are planning a professional career, knowing them more or less well is a must.

Answer 2

Break into small tasks. I underestimated this method, but this is the most effective thing that can be when working with a task that has a lot of dependencies. You can also draw a dependency diagram on the board / graphic editor.

Answer 3

You put all the settings in one file (or a class if there is nothing in the global area) and in all other pages of the project you just include this file and that's it. You change the setting in the file changes everywhere. What to put in a file? Something that is used in more than 1 place in a project, something that can change frequently.
What if not to produce, you can add a multiplier. Simple level, then $m = 1 And the price is for example 5000*$m , the average level is $m = 1.5 and the complex level is $ m = 2 but you don't need to change anything in the code, the price will change itself.

Answer 4

The topic has been discussed here.
How do you keep in mind a programming project that you don't work on every day?
Initially, it is GOOD TO THINK EVERYTHING, and then write.
From that moment, new thoughts came to mind - but the essence is generally the same - to break into small subtasks, and if possible such that they make a function - and you can forget about what's inside - and remember and write down only the input output parameters.
The problem is - people are often carried away by the process (it is also pleasant) and do not think through the architecture sufficiently - as a result, an insurmountable rake is found in half of the project and the need to rewrite everything from the very beginning. And after everything is well thought out - you may not want to write - because it's already boring. )))
In any case - success! Write down how it works.

Answer 5

Use good assemblers that immediately offer a good file structure: TARS Well documented, there are articles on Habré !