How to stop shit-coding and making wrong architectural decisions?

Question

Programming

Actually the essence of the question above is how to write maintainable code?
What to google, what to learn? Can you recommend some literature to read?
Can you call yourself a middle if your code is shit?

Answer 1

how to write maintainable code?

In short, follow SOLID/GRASP. I liked a tweet from one of the React Router contributors:
https://twitter.com/mjackson/status/1171524189850701825
Most common mistake software developers make: putting stuff in the wrong place. Coupling responsibilities and concepts that should be kept separate.
For me, this is 95% of software development. Just figuring out *where* things belong.
Fundamental knowledge, like the aforementioned SOLID / GRASP, patterns (not only classical patterns, but generally well-known solutions to certain problems), basic data structures. Frameworks / libraries will always come / go, something will be forgotten. And fundamental knowledge is always relevant.
I will speak for myself. I have not read any of these famous books in my life. Wrote a lot of shit code at home, a lot. Deleted, rewritten. I looked at the code of other people, analyzed it, tried to adopt what I considered correct.
Don't try to evaluate yourself. Each company has its own concepts of the middle. And if someone has been coding Lisp for 35 years, and then jumps to Angular - who is he, a junior or a senior?
And, yes, we all write shit code to some extent. If someone proves to you that he writes super clean code, don't listen.
It's impossible. All projects that are a little more complicated than CRUDs sooner or later become overgrown with shitcode. Nobody writes perfect code. The code must work and solve business problems.

Answer 2

Can you call yourself a middle if your code is shit?

Nope. If only a shitty middle. Well, depending on how shit - there are also different varieties. Maybe your code is very even compared to.
Practice. I was always very proud of the solutions that I shit-coded, but during the development process it turned out that they were not so hot (it just became very inconvenient to work with the code, especially when the project was your own and you returned to it after six months), and an understanding came of why. In the next project, I tried to avoid the previous rake and stepped on new ones. As a result, now, if I’m shit-coding, it’s already consciously, and this, as you understand, is already a completely different level of skill)

Answer 3

How not to start shit*coding?

Answer 4

Practice as much as possible, try to find a competent mentor or a job where there will be a more senior programmer than you, who can prompt and explain what is bad and what is good.

Answer 5

To do this, you first need to just do shitty coding.
Yes, you can.
Literature, practically any. But the must-haves are:
Clean Code, Clean Architecture, Perfect Programmer (Robert Martin) and Perfect Code (Steve McConnell).

Answer 6

The answer is simple: you need to first develop the architecture of the code , and only then start coding.
But not vice versa - not while coding to "invent" the architecture of the code "on the go"!
It is the thinking of the sequence of actions of the code during coding that gives rise to shit code.

Answer 7

Learn from someone else's code. Read Martin's book Clean Code

Answer 8

Programming is knowledge, skills and abilities (you can sometimes say "art" when talking about talented people) FIND COMPROMISES . Trade-offs between the speed of the task (which means the cost of development) and the quality/clarity of your code, between the speed of its execution and the amount of memory/resources consumed, between the presence/absence of tests and the completeness/quality of their coverage of your code....and many other trade-offs. . In the end, programming is such a huge "constructor" in which you can put figures together a huge number of times and options. Some options will be optimal and elegant, but most of them are far from being the same. The better the skills-knowledge, the better the option. The more attempts (successful and unsuccessful), the greater your experience as a designer.
Any, even if (suddenly!) Initially "perfectly written code" as the project develops (it's good when the business is successful and develops) can turn into shit code by itself, because "it overgrows with crutches" when adding "features" (new functionality ). This is a normal and natural process of "code/system evolution". Trying to keep unit/integration/what_tests up to date, learning how to refactor both code and tests are skills that need to be developed. You can also on personal projects, because for you personally they are more interesting and valuable in terms of quality and you are usually not strictly limited in time. You can "solve problems", you can participate in open source projects.
"Classical knowledge/works" always remain "they were written about above, you can still read books about the "art of creating an evolving software architecture" for development. Not to be called an "architect" right away, but at least just try to plan development in advance, design a project/module/component/function/etc in this aspect, evaluate possible shortcomings of the current code/design/architecture. This is difficult for Middle, but there is nothing wrong with gaining new knowledge and skills if there is enough free time (and there is always very little of it). It must be understood that this field of knowledge / profession continues and will continue to develop, new languages ​​/ paradigms / libraries / ideas will appear, therefore, independent development of (practical) skills and (theoretical) knowledge for practice is the key to success. Knowledge without practice and "appropriateness of their application" in this or that case/context, they can also be useless and/or harmful. No need for fanaticism!
Yes, sometimes it's hard not to cheat, but you have to compromise with yourself, put todo marks in the code and enter "technical debt" tasks into jira. Those debt accumulates and if it is not eliminated, then sooner or later the project becomes difficult and painful to maintain.
As a developer with 18+ experience in this profession, I agree with the previous comments. There is no universal and only working recipe for "not shit-coding", you have to develop, grow up as you gain practical experience and knowledge.

Answer 9

How to stop shit-coding and making wrong architectural decisions?

Write code as if it were accompanied by a violent psychopath who knows where you live