How do you keep in mind a programming project that you don't work on every day?

Question

Programming

Good afternoon, the situation is as follows...
I've been working on a project for several months. I am programming a thing related to numerical methods for solving diffuses and physics. When I started, everything was simple and easy to keep in my head. Further, the project began to grow - due to the fact that at the very beginning it did not represent all the difficulties that I would face. I don’t work on the project every day, and the following problem was discovered - if you don’t work on the project for several days, then it’s hard to remember where I stopped, why certain pieces of code were introduced. I write comments - but not enough, the feeling that I have to write detailed letters to myself (almost like in the movie "Memento"). As a result, the day is spent on figuring out what I did a week ago - and the next day you can already write normally.
I am not a programmer, but a physicist, so I may not know some typical and obvious methods for solving such organizational issues. Advise how to be!

Answer 1

1. Write self-documenting code.
2. Generously add standardized comments to each function and variable.
3. Refactor the structure until it's completely obvious.
4. Use git with detailed descriptions of commits - with the help of annotations it will be easy to understand why this or that piece was written
5. Maintain TODO separately or using @todo comments directly in the code.

Answer 2

The same as the zoom on the map:
1. make a general scheme with functional blocks and their connections. blocks are numbered.
2. each block - detail in the new scheme.
* here you make a text description of the links and everything related to the scheme/process in a separate docx/xlsx document. (google docs)
* based on this - it won't be difficult to describe functions for coding if the level of detail of the given scheme allows.
3. goto 2.
(it's wise to use draw.io and connect to google docs/google disk)

Answer 3

It is recommended to use OOP.
When using OOP, you can first draw diagrams - the so-called UML diagrams - they usually say what a class does and draw how it relates to others.
First, you draw diagrams of what is connected with what and then write the code.
It looks something like this:
pvti.ru/data/image/pages/webkurs/p3_9.gif
In these diagrams, the first line contains the class name, the second block contains the names of variables, and the third block contains the names of methods (functions). The arrows show how classes interact with each other, who inherits from whom and who calls which methods, etc.
In general, to get an overall picture, it is very convenient to use diagrams so as not to forget what is where how it works if the program is large. Many IDEs have the ability to get the complete class tree.

Answer 4

Draw a diagram.
+ keep TODO with a list of already done and planned tasks.

Answer 5

If you write tests, create a non-working test before you finish your work.
When you sit down again, run the tests and remember what you wanted to do the last time.

Answer 6

There is a belief - if the code needs a comment, it needs to be moved to a function with a self-explanatory name

Answer 7

It seems that the author of the question should carefully study the books:
1) Steve McConnell - "Perfect code"
2) Martin Fowler and others - "Refactoring. Improving existing code."
And about "then it's hard to remember where I stopped, why certain pieces of code were introduced" - version control systems will help, subject to commenting on the changes.

Answer 8

You can’t keep it in your head, but somehow you need to remind yourself.

Answer 9

You can just periodically read / view the code, remembering what's what, how it looks, where it is called from and whom it calls, in what situations this or that part of the code works ... To navigate the terrain, you need to walk along it sometimes, and not be afraid get lost :)

Answer 10

I'll try to summarize.
1. It is necessary to initially think over and paint / paint the structure of the project.
- alas - sometimes it begins to change in the course of the play - it means they thought it out badly.
2. Break the program into small blocks.
3. Comment on everything that is possible and impossible.
4. Apparently write letters to yourself and artistic reflections why this or that is here.
Many thanks to everyone for the replies!
By the way - am I the only one - suffering from programmer sclerosis or is it common?