How to remember the code that was written two weeks ago?

Question

Programming

Friends! There is a problem ... Tell someone how to solve it.
In short, the project that I am doing is growing and gradually taking on the form of a huge animal that is difficult to fit in my head. I start to forget what code is responsible for what, how it works and with whom it interacts.
I write comments, I try to structure everything, I scatter monotonous tasks and the like by functions, but I don’t have a complete picture of the whole project in my head, I forget something. Thus, I can write some kind of module that, through hell knows how many lines of code, can unexpectedly affect another piece of code and break something.
In general, the main problem is that I can’t get the whole holistic picture and the logic of the project into my head.
I think to start drawing mind maps for the project and describe all the functionality that I wrote in code in a visual form. So that you can look at any time and immediately understand what is connected to what and where.
But maybe there are some other life hacks? Can you help? And I'm already going crazy

Answer 1

1. How to write a lot of code, keeping it simple, like at the beginning?
   
2. I also advise you to read "Perfect Code" by S. McConnell.
   
3. Good code doesn't need to be memorized. Quality code can be forgotten as soon as it passes all the tests. You need to keep in mind only programming interfaces, but not even all, but only those used at the current level of abstraction.
   

Answer 2

This is because you are just stupidly writing code, and you need to develop (design) an application.

Answer 3

So you are not a programmer yet, but a coder. It's not scary, a matter of experience.
The main difference between a programmer and a coder is that a programmer writes code in his head - stuffing code in an IDE is the most tedious thing in programming, the whole relish is in designing. But the coder writes the code in pieces that he takes from the Internet or from his own sudden insights.
The recipe for solving your problem is simple - move away from the computer, go for a walk or sit in a cafe, on the couch or wherever you are comfortable, calm and the flies do not bite. Design your application inside and out in your head. You must clearly see all the components of the system and their interaction with each other. Then run the application - head debugging can also work if you know the programming language well. After fixing the bugs, you can sit down at the computer and transfer the code to the iron box under the table.
PROFIT!

Answer 4

It’s damn epic, no, well, I understand the methods there when I transfer 4-6 variables there, I don’t always remember what and in what order, but I definitely understand why the getCollectionAsArray() function. And I won't forget in 3 years. Either you name it briefly and incomprehensibly, or you hardcore something unstructured and chaotic, trying to roll a fix over a bug, and there are a lot of them. How is the code organized? Well, at least according to some kind of paradigm like mvc or event model? Or figachu functional, and then we'll see?

Answer 5

To write a project not on a blank slate, but to pull it on some competent framework, playing by its rules. This will help you master and understand some of the patterns, SOLID / GRASP principles that have already been recommended to you, and avoid a completely illegible mess in architecture.
Give understandable names to methods/functions/classes. Avoid long pieces of code - hit on smaller ones. Many “correct” practices will fall into place on their own if you start working on a project not in one person, but with someone.
Divide complexity into levels of abstraction. The topmost one is how your application functions in general, without details, just a few components - for example, a web client, a backend server and a third service. These 1-2-3 are easy to remember / remember) Further, how the backend works - what it interacts with (DB, Redis). Etc. in depth, in detail.

Answer 6

In general, the main problem is that I can’t get the whole holistic picture and the logic of the project into my head.

so it (the logic of the project) should be in the head initially, and not later, when the code is written. How is it possible for you to do the opposite?

Answer 7

Two weeks? And the whole project from the beginning to the current state is yours? OMG, I probably don't understand something...
Documentation is needed, so hated by programmers. The general structure of the project, its division into modules, their API and interaction rules, exchange protocols, if any. The module should be documented as if it were taken to be used by a third-party person who should come, read the API description and start using it - it is possible that this "new person" will be you yourself.

Answer 8

That is, architecture as such was not originally there?
In any case, you need to document not only the code, but also the so-called use-case and user-story, describe the interaction of modules with each other.
Such abstract documentation is very important. True, it is very desirable that it be before writing implementations.

Answer 9

TDD
+
How to perfectly remember the material read?
In general, a person can hardly keep things in mind - 3-5 abstractions
Beginners still have to keep constructions in mind

Answer 10

https://www.youtube.com/watch?v=z5WkDQVeYU4

Answer 11

I usually remember the code only while I am writing the module, then I almost forget it on purpose, because often the module has one input and one output (maybe a little more), but otherwise you only need to mean what the module roughly does.

Answer 12

Specifically, for the code, for me personally, git helps
. By commits and revestes, it is quite possible to refresh the memory of the work done, and of course, to view the work of other programmers.
Regarding mind maps, it is better to draw them initially, before writing the code, i.e. at the design stage of the application, i.e. describe what will interact and how - this will actually be Development
As an example - a regular design - first a prototype is drawn - and only then the design itself
On the topic - first we draw a diagram of the application, then we write the code
This only speaks of the lack of experience and the presence of the thinking of an ordinary programmer, and not an application developer / architect. Those. only a specific task lies in the head, and not the operation of the application as a whole.
How to fix this - participate more in the development of the application architecture - attend meetings more often on the future work of the application, make mind maps, draw a diagram on a piece of paper, on a board, think not about how to write a class and methods, but about how it will work application as a whole, i.e. the main thing is to see the overall picture of the application's work.. Draw a couple of times, think over the architecture of the application, then the brain will already start thinking in this direction, without the need to visualize anything .. Well, as a result, the application architecture will always be in your head.

Answer 13

I don’t know about life hacks, of course, but 2 weeks?
Very short memory.
I did 3-4 years, let's say a project, I remember / know everything. I "forget" only if I need to clarify some deep trifle in logic, and then not always of course.
And during this time, he also dealt with any other garbage not only in one project.
If there is a code, there are docks, I can’t imagine what else will help.
Record somewhere else? So you will forget what you wrote there, what's the point of inventing work?
Already answered about SOLID / GRASP, but this is not for shitcoders like me, but you still need to have some kind of structure / logic in common, if you don’t remember the basic things, they probably change constantly or are not very logically built.
It is also forgotten if the code is not used for a long time, and if something breaks from the new / new from the old, you need to write better so that this is basically impossible.

Answer 14

Write well-structured, modular, loose coupling / high cohesion commented code, not jumbled spaghetti.
Then you can understand in a few seconds what goes where.
If the project is rail-oriented, then there is such a thing as a mountable engine - it helps a lot.
Break the project into such mountable engines - you won’t believe how much it simplifies life, without them I can’t even imagine how you can work with arbitrarily large projects without resorting to microservices.
You can also break business logic into services (Service Object pattern) - it also helps.

Answer 15

My advice is to sleep better, eat meat and don't forget to rest.

Answer 16

First, you need a good application architecture. Due to the strictly opinionated structure of the paths in my nano-framework, I reduced the overhead by 90% to "think" and where I have what.
Secondly, modularity, ideally one module is responsible for one task. No need to fence Swiss knives, it ends badly.
Third, immutability. If you change in one place, and it breaks/falls in another, then congratulations, patient, you have a mutability of the third degree and this is fatal. Everything that can be translated into pure functions and immutable structures (here with caution, because you can shoot yourself in the foot and drop performance below the baseboard).
Again, the only source of truth saves.
And most importantly, the code must be written in such a way that it is understandable at first sight, maximum from the second. You don't need to be verbose in your code. The code should be simple and concise. Saying that snake_case is more readable than the kilometer CamelCase. I, perhaps, will agree, although I use the latter in the code mostly.
I often come across a very elegant tricky code that is impossible to understand even after an hour of meditation on it. That's what I try not to do. I try to write code so that any June can understand (obviously in the context of the project). It doesn't always happen, but often enough.
At least in recent years, I immediately understand what I did there in the project and after a month, and after 6, and after 2 years. And before, yes, it happened after 3 months you wanted to kill the donkey who wrote it, and then you remember that it was you yourself ... :D
Another point - well-structured data helps to write more transparent code.