Don't put off until tomorrow what you can do today

Don't put off until tomorrow what you can do today. This idea has become one of the key ones for me in developing and documenting applications. "Why?" you may ask.

It's very simple. Tell yourself: "I'll fix this later, and I'll rewrite this later. But this can wait for now. And I'll think about the file system later"? Well, this "later" may never come. And your project will turn into garbage. And even if you remember that it's time to move something somewhere, instead of two files you will have 100 or more. And you will no longer remember what is responsible for what and where it is. As a result, instead of one hour, you will spend a day or more on refactoring, which could and should have been avoided.

In general, the key thing is not to rush to write code right away, but to think everything through first. The structure, architecture, all these little features and so on. At least in general terms. Otherwise, your project will very soon bring you pain, and you will spend time on something completely different from what you would like.

But often laziness, deadlines and other factors prevent this from being done. And here I have no clear recipe for how to treat it. You see, I myself, due to my experience, sometimes stepped on the same rake. But the awareness and understanding did not come to me right away.

Sometimes I saw projects where a simple refactoring of styles took several hours, because all the css was written in one file of 3000 lines. There, identical classes were repeated, and sometimes it was unclear where I broke it, having fixed it in one place. This happened precisely because those who did the code initially did not think about it at all.

Refactoring is an expensive thing in itself. Sometimes in teams and during development, time is always tight. Therefore, even a week or two for refactoring is very cool. And a month is just a dream! That is why it is necessary and important to build the basic tree of project development correctly from the very beginning.

Another problem is that even if we understand in words what we shouldn't do and what we shouldn't, we then go and write code ourselves and don't follow these rules. It's like with advice from good people. They seem to be right, and I agree with them. But then I go and still do it in such a way that it turns out not to be what they advised. And why? Because it's not enough to know, you also need to feel it and understand it internally. And this requires both time and suitable situations. That is, until you pick up all these rakes yourself, you won't be able to realize this - no matter what others tell you and no matter how wise they are.

Sometimes I look at my code that I wrote a year, two, three years ago and think: oh, did I really write that? Well, that's not right! It's all a journey, an evolution.

Just leave yourself time for reflection, analysis and observation. Or even contemplation. It can sometimes lead you to the right path.

But the downside of our frontend — or even a curse — is that the same task can often be solved in different ways. And sometimes there are many of these ways! And at first, some developers have all of them in their heads and it’s hard to figure out what to choose. Of course, I’m exaggerating to emphasize the artistic point. Other languages ​​also have several solutions to a particular problem.

The key reason why we get into a trap is that each specific task on the frontend is not difficult. But there are many of them. The interface comes first, there are many inputs and outputs, and they all have to coexist and work correctly. And when all these layers start to come together, you get a huge layered pie, where the layers can also penetrate each other, and you can’t really figure them out. And if different people wrote it, then no one remembers why Vasya decided not to put this data in the store, no one remembers who wrote this module and how it works. And eventually there comes a point when it’s easier to write it again, because nothing can save you here. And this is an endless cycle of reincarnations, which development revolves around.

And it will spin. You can just make everything a little softer and better.

It is not always worth bringing some heavy stuff into a project if it is as simple as two kopecks. So let it remain simple. But the opposite is also true: it is not always possible to get by with simple implementations, without ts, classes or external services.

In general, I would like to summarize

Before you start coding your app or write that documentation, figure out: what do you need and what do you want to do? What tools will you need for this? What tasks will your app solve? What will potentially be added to it? But don't think 100 steps ahead. Look at 1-2.

If the stack is defined, then define the tools, libraries, and architecture.

After you've written the first iteration with the main page and anything else that already works, do a little revision of what you have. You might notice that somewhere the loading is not working optimally, then you can add some tool. Or something duplicates the same functions.

Repeat the revision process periodically. At least once a month. Set aside time for this. Otherwise, you may encounter problems that, at first glance, should not have arisen. And this will allow you to maintain the code so that it does not become legacy. Of course, if you did not initially choose outdated tools for work.