How to throw the logic of the future program?

Question

Software design

I have a task to write a program in C++. But before you do something, you need to throw a plan of action.

How to correctly throw in the logic of the future program so that later it would not be redone in the middle or at the end? Are there any instructions, cheat sheets, standards and templates for this?
Because I am not strong in PL (beginner), I want to make few mistakes. But I don't know where to start, how to build the logic of a future program, what tools and resources to use, how to pack it all into a finished product, etc.

Answer 1

You won't learn how to write and design software if you don't do it yourself.
Rewriting a program anew is a normal process called refactoring. "On the beach", even before you start writing code, you will not see all the subtleties and nuances. So slapping yourself on the forehead and throwing the code in the trash = a normal creative development process.
After several such races on a rake, you will gain experience - the errors and difficulties that you will begin to face will be such that you can’t say in a book or read on StackOverflow.

Answer 2

I'm guessing: no way. If you want to make few mistakes - don't do anything. If the project is important to you, hire a contractor.
What a laugh! We cry at you looking. There are no royal ways in programming .

Answer 3

It all starts on a piece of paper. If you are designing one, then you do not need to adhere to any formal description schemes. Just so that it was clear to yourself what and how.
There are two approaches - from interface to logic or vice versa - from logic to interface. What is better, what is worse - taste. From the interface to the logic, it turns out a little more "KISS-like" and "YAGNI-like", since you only throw in those features that you want to implement. You can also work from logic to interface, but there is a risk of going into premature optimization.
Further, the logic is divided into task blocks and data models. For models, you define what actions will need to be performed with them - this is how methods are defined. Here you define the signatures of these methods (parameters, their types, return values). If the project is large, then it would be nice to sketch out a UML schema.
After you have defined the class hierarchy, you can already run the IDE and immediately create definitions for all the classes that you drew on paper. In each class, you draw method stubs (you can immediately mark it with a TODO comment so as not to omit anything).
The next part that they don't like is writing unit tests that determine how which method should behave in order not to break anything (well, yes, I know, tests are for insecure wimps, but still, this is important).
Well, after all this, start writing code. It will be easy and pleasant for you. You will roughly imagine how much you have already done, and how much is left. Bugs will be caught by tests, and you will not write extra code that no one will use in the future.

Answer 4

If the project is very important, look towards the TDD methodology.

Answer 5

It's called "architecture". If you are a beginner and want to create an application with a more or less good architecture, try some framework known in your stack. Frameworks often dictate their architecture or have ready-made project templates that provide "a thousand little things". It is also possible / necessary to start understanding the wisdom of architecture by studying patterns (factory, dependency injection, adapter, etc.) and approaches (MVC, TDD, SOLID, DRY, etc.)
But as for the business logic , everything here is too specific and depends on the subject area. I would advise during development to think from time to time on the topic "how can I then extend this module / class / method without editing its code?". This sometimes gives very good ideas.

Answer 6

Take a leaf and draw how your program will work. When I write large programs with classes in Python, I always do this so as not to get confused in the code.