I just had a more than 2-week long vacation/business trip and I couldn't remember actually what was I working in my coding and where I stopped. Could someone recommend a best practice to solve this?
Copious notes. Write down your thoughts, your progress, in as much detail as needed to clear your mind.
It's no different from when you do a problem analysis tracking down a bug and someone else is going to execute the fix (or yourself at some indeterminate point in the future). Write down EVERYTHING of consequence. When I do it I won't usually write in the line numbers per se as they may have changed by the time the ticket is executed, but class names, method names, etc. etc. where changes are to be made are mentioned.
And try to leave the codebase in a somewhat predictable state. Don't leave in the middle of implementing a method for example. Leave the entire method unimplemented and make a note that it's the next thing to be done.
The most obvious recommendation is to always stop at a point where all of the work is "done". So when you return, you start on something new instead of trying to remember where you left of.
Instead of looking at it as a vacation time, look at it as if you worked in some different part of the application. So after few weeks, you return to module you worked on few weeks or months back. To me, best solution to this are automated tests. With automated tests, I can start playing around with code. When I mess up, I can look at which test failed and see what the intention behind the code was. This allows to quickly remember what the code was meant to do and what was reasoning behind it.
How do you know where you stopped in your codes after a 2-week break?
The same way I know where I stopped after I take a bathroom break.
You take notes, you make to do lists, you don't walk away from the 2 hours of work that it took to get an idea spun up in your brain without writing it down.
Add method names, file names, ideas worth exploring, things to check out, questions to answer.
Then go to the bathroom before you make a mess.
The process is remarkably similar when going on vacation. The only difference is how much work other people did while you were gone. Maybe talk to them before jumping right back in.
Simple. Keep a notebook which records all work done that day and lessons learnt. Make a record every time you stop work. I use // to indicate breaks in work but do whatever suits you.
This is also a valuable tool for project management queries when they're asking why you didn't finish X, Y & Z on a given day.
For a more senior (i.e. older) developer like myself who probably has fewer years ahead than behind, it acts as a source of pride for everything you've achieved over the years. I have many of these in the loft covering different jobs and roles and like to dig them out every so often.
Do you follow AGILE ?
If you do then you can have sprints, with Kunban charts...
So it could point you out to the feature \ bug you were working on...
How it going to help OP ?
When user stories are broken down to tasks, ideally tasks should be less then a day, so when you come after 2,4,8 weeks holidays, you will work on next task assigned to you :)
Commit regularly and when come back, check commit history, it's really easy with Azure DevOPS or sourcetree...