How to quickly plunge back into your own code?

Question

Programming

Suppose you take a vacation for a month and for a month you don’t sit down at the computer at all and don’t write a project.
How, after a month, to quickly join your own code again, if there is a lot of it? It happens that you have to sit for an hour and a half and parse your own code. Reveal "ends", etc.
How do you solve such a problem? How to pause development correctly so as not to get confused after a month in your own code?

Answer 1

"I'm in a month of vacation" - the same as "another, new developer in the project."
I look at my code, as if another developer will finish it tomorrow, while I'm out of access.
I try to adhere to generally accepted patterns, comment on points that require clarification. Commit once a day or more often on completed microtasks, with reasonable commit comments.

Answer 2

I strive to write clean code .

Answer 3

To what has already been said, Sergey Gornostaev should add that it is necessary to divide the work into parts that must be completed. If you have unfinished parts, then in a few days, even if you have documentation, you will forget about them

Answer 4

I use OOP to build a "tree" of dependencies and a "sheet" for data work-flow.
I comment on the sections responsible for the data flow processing logic and various implicit operations that rarely occur, if any (for example, specific complex conditions or whatnots for returning objects).
There is no point in commenting libraries or classes.
I store all the top-level logic in one file and start browsing from it: everything immediately "looms" in my head in terms of what is happening with the data: dependencies, calls / calls, etc.
If I haven’t finished writing something and it needs to be postponed for a long time: I put either a compilation error with a comment above it, or I raise / interrupt and display the message for myself.

Answer 5

I always write in texts what I want to do, what I have already done, well, I leave comments in the code, for me this is enough.

Answer 6

1. I break complex and large code into small parts, as they are easier to read and test
2. I write comments and documentation