Tips for novice developers
I have been working as an iOS developer for over six years. I happened to work in several different companies and teams. I worked both in the outsource and in the outstaff, it was even possible to participate in startup. And now, after several years of commercial development, as well as a couple of years of programming at the university, I began to highlight some of the principles or rules of a qualitative approach to application development. At first it was my friend's advice. Giving him advice, I thought that I lacked such advice when I was just starting my way as a developer. So what can I say, some moments I realized for myself relatively recently, and some already at a new place of work. And the idea was born to make a list of tips that I would like to share with myself five or six years ago. I am sure that in another five years I will have something to say to myself today. But let's leave it for the future.
And the first thing I want to say to myself still is: “Your code is bad!”. In common "govnokod". And foreign colleagues in the developer shop "monkey code".
No, that's not what you thought. I do not want to emphasize that I used to be a bad coder, but now my code is perfect. I want to rephrase this message and convey three key points in the sense of this advice.
“Your code was and will be bad!”
')
The first moment: there is no perfect code, no one lays the ideal architecture and there is no such code in which there would be no bugs. I think many people caught themselves thinking that they could not understand the new library or the new technology. Or some of us went to extremes in trying to write a feature perfectly, following all the principles of OOP, SOLID. That, in turn, led to great time costs, and sometimes led to a dead end. Sometimes in trying to write the perfect code, monsters were born that carried the complete list of patterns that the developer knows, or maybe even more.
With my phrase, I would like to convey the idea that you should not worry in the first place, be nervous about the quality of your code. Predict everything is impossible. And it's better to just relax, write easier and as you know, rather than suffer and worry in vain. With experience, solutions will come by themselves. Sometimes you need to “nagovnododit”, will face problems that will cause this govnokod and understand once and for all that it is not necessary to do so better.
The second moment, as I mentioned earlier, is that it is almost impossible to predict everything. Yes, with experience comes an understanding of what you are doing and you can predict the development of the project. But it comes with experience. And if the experience is not enough, then you should not try to make the code universal. There are often cases when your feature, which you have thought over for a long time and so carefully, And then wrote, they are simply discarded from the application. It is also not uncommon for applications to change only because the customer thought it was all different. And after long hours of painstakingly transferring the interface from the design to the code, suddenly there are 100,500 edits. This is only the beginning, as after the first redoing, more and more new edits will come. And in the case when the developer lacks experience, this process can take not only a lot of time but also bring not the most pleasant sensations, which are put off by unpleasant thoughts somewhere in the hidden corners of the mind, turning the development process from fun activities into hellish pain. Therefore, take care of your nerves and not fit for the ideal. Sometimes you can talk a little bit.
The third point: this is again a purely psychological moment, namely criticism from other developers. As everyone knows, all domestic developers consider any foreign code - govnokodom. Even if he shows him his own code, which he does not recognize, he will most likely name him with govnokodom. Often such criticism is accompanied by the moral satisfaction of the critic himself. As experienced developers say, most of all govnokodom call someone else's code is those who in their time nauvnododil with interest. And the louder someone shouts “govnokod”, the more his “leech” he left on his way.
In addition, any virgins who remember themselves as young are sure to admit that he is a codename for glory.
Therefore, I advise you to use the expression “Your code was and will be a govnokod”, as a shield from not always constructive criticism. I also want to note that your code will always be govnokodom because the development does not stand still. Every year the quality of your code only improves. So the current code will eventually turn into a govnod anyway.
I do not want it to seem that I advise only govnododit, so I will start giving advice on how to avoid that very bad code. And I would like to start with the principle that I singled out for myself. No, this is not inheritance or polymorphism, and not one of the principles of SOLID. I call this principle Divide and Conquer.
Yes, there is such a thing as decomposition.
Decomposition - the division of the whole into parts. Also, decomposition is a scientific method that uses the structure of the problem and allows replacing the solution of one large task with a solution of a series of smaller problems, albeit interconnected, but simpler.
As Wikipedia says. But this is only part of what I put into the meaning of my principle. Definitely yes, you need to divide the project and tasks into smaller parts. But I mean the conceptual approach to the separation of logical groups in the project.
And the first thing that I refer to this principle is the separation of the user interface and the business logic of the application. It would seem that I am now straight captain obvious. But! In practice, these boundaries are often blurred and so that ViewController or Activity contains a piece of business logic.
I think the example of the “Login” screen will be simple and clear. Here begins the developer to implement the MVC architecture. It seems there is a separate View, like the Controller with the Model also adds, as it should be. But at some point, they think: “Why should I add several classes for the screen with one single button?” And at this moment I strongly recommend to refuse such evil thoughts and strictly adhere to the “Divide and Conquer” principle to separate the UI and business logic . And even if the architecture requires adding a ViewModel class, in which there will be one two lines of code, you should do so. Because there are often cases when the screen in which there was originally one button, over time grows to unimaginable difficulties. If you follow in advance the separation of logical components, then this will make life easier in the future.
Especially to feel the essence of the strict separation of UI and logic, it is possible in cases when you have to transfer screens from one project to another. Or, in a situation where different algorithms are used in different business logic under different conditions. For example, by dividing the authorization screen into components, we can replace one of the components in the future without affecting the other. We can either replace View or Model with new authorization methods for the same data.
Do not limit the principle of “divide and conquer” only these two layers. To strict separation I would add the separation of screens and navigation logic for mobile applications. What do I mean by that?
My practice has pushed me to simplify the code for a particular screen by the fact that it is possible to separate the logic of navigation. The screen, specifically View, for iOS is UIViewController, and sometimes UIView, and for Android Activity, or Fragment, should not be engaged in the function for displaying itself, as well as switching to other screens. Each of these classes should care only about what is happening on a specific screen, or rather, only for drawing a specific screen and interacting with the business logic class (Presenter, ViewModel and others).
These are just two of many examples where you need to fundamentally follow the division. Following this principle many times will facilitate further work with the project. Even if in any of the individual components will govnokod.
Smoothly proceeding from the previous advice, I want to go to the next one, namely, strict adherence to a single style in the project.
What do I mean by that?
To begin with, the keyword is strictly here, from the word at all. Initially, we select a single approach for organizing a project, for file management, for code style, and so on. This will significantly improve the overall look of the project and make it much easier to navigate the project, search by code, speed up the process of familiarizing the new developer with the project. I think it is not necessary to remind that after a while we ourselves can become this new person with our old code.
Again, based on the previous advice, we smoothly proceed to the next one, the choice of architecture. And the main idea that I want to convey is not to tell about the best architectures or to say that you need to choose this one and not another. Not! To begin with, there is no ideal architecture that would completely cover all possible cases in the project. I once heard these words: "if there was an ideal architecture, then we, the developers, would be fired as unnecessary and replaced with scripts that generated the ideal architecture."
The main point, I believe, is not the choice of the best architecture, but again, strict adherence to the architecture that has already been chosen and started to apply. Whether at least VIPER, REDUX, MVP or MVC. Of course, there are pros and cons in each of the above architectures. Over time, there are more and more new approaches to the design of the project architecture.
More specifically I will say about my idea. If you have already started using VIPER, then strictly follow its principles. Even if it seems that for a screen with one button too many files need to be created with units of lines of code, then under no circumstances do you bypass these rules. Because, it is at such moments that the govnokod is born, which then, like a snowball, everything builds up and builds up.
I advise you before starting the development of a new project to familiarize yourself with the most popular architectures and choose either the one you like or the most popular. I strongly recommend choosing the second option, namely to start with the most popular architecture, since It will be easy to find answers to many questions. When choosing an architecture, special attention should be paid to the minuses of this architecture and then in what cases it is recommended to use it.
For example, if a small project on which there are one or two developers, then VIPER is not worth taking due to the fact that it is a rather cumbersome architecture that shows itself very well on large projects and in large teams. That there were no cases when the code for creating VIPER is more at times than the code of the business of logic itself.
Personally, I now prefer the MVVM + Router architecture. It fits well on a small project where I am a single developer.
The bottom line: the main thing is not what architecture you have chosen, but how exactly you follow it.
I also want to add that if the project is not developed from scratch, then first of all you need to familiarize yourself with the current architecture and the overall style of the project, and begin to follow it. It is not necessary to escape with shouts that there is a shit (returning to the first advice) and start redoing everything. The exception may be complete anarchy on the project or the lack of a common style.
And in conclusion, I want to say that a good approach would be to pause for refactoring. Refactoring is a very important part of good application development. Yes, we do not write the perfect code immediately, but also to keep everything as it is, is also not good. It often happens that the original implementation does not have the ability to scale when it is necessary to introduce new features. After all, it is almost impossible to predict all possible changes in future versions of the project. Also, no architecture guarantees 100% coverage of all cases. Therefore, it is important to make changes to the existing code in order to adapt it to the new features.
Your code is bad
And the first thing I want to say to myself still is: “Your code is bad!”. In common "govnokod". And foreign colleagues in the developer shop "monkey code".
No, that's not what you thought. I do not want to emphasize that I used to be a bad coder, but now my code is perfect. I want to rephrase this message and convey three key points in the sense of this advice.
“Your code was and will be bad!”
')
The first moment: there is no perfect code, no one lays the ideal architecture and there is no such code in which there would be no bugs. I think many people caught themselves thinking that they could not understand the new library or the new technology. Or some of us went to extremes in trying to write a feature perfectly, following all the principles of OOP, SOLID. That, in turn, led to great time costs, and sometimes led to a dead end. Sometimes in trying to write the perfect code, monsters were born that carried the complete list of patterns that the developer knows, or maybe even more.
With my phrase, I would like to convey the idea that you should not worry in the first place, be nervous about the quality of your code. Predict everything is impossible. And it's better to just relax, write easier and as you know, rather than suffer and worry in vain. With experience, solutions will come by themselves. Sometimes you need to “nagovnododit”, will face problems that will cause this govnokod and understand once and for all that it is not necessary to do so better.
The second moment, as I mentioned earlier, is that it is almost impossible to predict everything. Yes, with experience comes an understanding of what you are doing and you can predict the development of the project. But it comes with experience. And if the experience is not enough, then you should not try to make the code universal. There are often cases when your feature, which you have thought over for a long time and so carefully, And then wrote, they are simply discarded from the application. It is also not uncommon for applications to change only because the customer thought it was all different. And after long hours of painstakingly transferring the interface from the design to the code, suddenly there are 100,500 edits. This is only the beginning, as after the first redoing, more and more new edits will come. And in the case when the developer lacks experience, this process can take not only a lot of time but also bring not the most pleasant sensations, which are put off by unpleasant thoughts somewhere in the hidden corners of the mind, turning the development process from fun activities into hellish pain. Therefore, take care of your nerves and not fit for the ideal. Sometimes you can talk a little bit.
The third point: this is again a purely psychological moment, namely criticism from other developers. As everyone knows, all domestic developers consider any foreign code - govnokodom. Even if he shows him his own code, which he does not recognize, he will most likely name him with govnokodom. Often such criticism is accompanied by the moral satisfaction of the critic himself. As experienced developers say, most of all govnokodom call someone else's code is those who in their time nauvnododil with interest. And the louder someone shouts “govnokod”, the more his “leech” he left on his way.
In addition, any virgins who remember themselves as young are sure to admit that he is a codename for glory.
Therefore, I advise you to use the expression “Your code was and will be a govnokod”, as a shield from not always constructive criticism. I also want to note that your code will always be govnokodom because the development does not stand still. Every year the quality of your code only improves. So the current code will eventually turn into a govnod anyway.
Divide and rule
I do not want it to seem that I advise only govnododit, so I will start giving advice on how to avoid that very bad code. And I would like to start with the principle that I singled out for myself. No, this is not inheritance or polymorphism, and not one of the principles of SOLID. I call this principle Divide and Conquer.
Yes, there is such a thing as decomposition.
Decomposition - the division of the whole into parts. Also, decomposition is a scientific method that uses the structure of the problem and allows replacing the solution of one large task with a solution of a series of smaller problems, albeit interconnected, but simpler.
As Wikipedia says. But this is only part of what I put into the meaning of my principle. Definitely yes, you need to divide the project and tasks into smaller parts. But I mean the conceptual approach to the separation of logical groups in the project.
And the first thing that I refer to this principle is the separation of the user interface and the business logic of the application. It would seem that I am now straight captain obvious. But! In practice, these boundaries are often blurred and so that ViewController or Activity contains a piece of business logic.
I think the example of the “Login” screen will be simple and clear. Here begins the developer to implement the MVC architecture. It seems there is a separate View, like the Controller with the Model also adds, as it should be. But at some point, they think: “Why should I add several classes for the screen with one single button?” And at this moment I strongly recommend to refuse such evil thoughts and strictly adhere to the “Divide and Conquer” principle to separate the UI and business logic . And even if the architecture requires adding a ViewModel class, in which there will be one two lines of code, you should do so. Because there are often cases when the screen in which there was originally one button, over time grows to unimaginable difficulties. If you follow in advance the separation of logical components, then this will make life easier in the future.
Especially to feel the essence of the strict separation of UI and logic, it is possible in cases when you have to transfer screens from one project to another. Or, in a situation where different algorithms are used in different business logic under different conditions. For example, by dividing the authorization screen into components, we can replace one of the components in the future without affecting the other. We can either replace View or Model with new authorization methods for the same data.
Do not limit the principle of “divide and conquer” only these two layers. To strict separation I would add the separation of screens and navigation logic for mobile applications. What do I mean by that?
My practice has pushed me to simplify the code for a particular screen by the fact that it is possible to separate the logic of navigation. The screen, specifically View, for iOS is UIViewController, and sometimes UIView, and for Android Activity, or Fragment, should not be engaged in the function for displaying itself, as well as switching to other screens. Each of these classes should care only about what is happening on a specific screen, or rather, only for drawing a specific screen and interacting with the business logic class (Presenter, ViewModel and others).
These are just two of many examples where you need to fundamentally follow the division. Following this principle many times will facilitate further work with the project. Even if in any of the individual components will govnokod.
Uniform style
Smoothly proceeding from the previous advice, I want to go to the next one, namely, strict adherence to a single style in the project.
What do I mean by that?
To begin with, the keyword is strictly here, from the word at all. Initially, we select a single approach for organizing a project, for file management, for code style, and so on. This will significantly improve the overall look of the project and make it much easier to navigate the project, search by code, speed up the process of familiarizing the new developer with the project. I think it is not necessary to remind that after a while we ourselves can become this new person with our old code.
The choice of architecture and following it
Again, based on the previous advice, we smoothly proceed to the next one, the choice of architecture. And the main idea that I want to convey is not to tell about the best architectures or to say that you need to choose this one and not another. Not! To begin with, there is no ideal architecture that would completely cover all possible cases in the project. I once heard these words: "if there was an ideal architecture, then we, the developers, would be fired as unnecessary and replaced with scripts that generated the ideal architecture."
The main point, I believe, is not the choice of the best architecture, but again, strict adherence to the architecture that has already been chosen and started to apply. Whether at least VIPER, REDUX, MVP or MVC. Of course, there are pros and cons in each of the above architectures. Over time, there are more and more new approaches to the design of the project architecture.
More specifically I will say about my idea. If you have already started using VIPER, then strictly follow its principles. Even if it seems that for a screen with one button too many files need to be created with units of lines of code, then under no circumstances do you bypass these rules. Because, it is at such moments that the govnokod is born, which then, like a snowball, everything builds up and builds up.
I advise you before starting the development of a new project to familiarize yourself with the most popular architectures and choose either the one you like or the most popular. I strongly recommend choosing the second option, namely to start with the most popular architecture, since It will be easy to find answers to many questions. When choosing an architecture, special attention should be paid to the minuses of this architecture and then in what cases it is recommended to use it.
For example, if a small project on which there are one or two developers, then VIPER is not worth taking due to the fact that it is a rather cumbersome architecture that shows itself very well on large projects and in large teams. That there were no cases when the code for creating VIPER is more at times than the code of the business of logic itself.
Personally, I now prefer the MVVM + Router architecture. It fits well on a small project where I am a single developer.
The bottom line: the main thing is not what architecture you have chosen, but how exactly you follow it.
I also want to add that if the project is not developed from scratch, then first of all you need to familiarize yourself with the current architecture and the overall style of the project, and begin to follow it. It is not necessary to escape with shouts that there is a shit (returning to the first advice) and start redoing everything. The exception may be complete anarchy on the project or the lack of a common style.
Pause on refactoring
And in conclusion, I want to say that a good approach would be to pause for refactoring. Refactoring is a very important part of good application development. Yes, we do not write the perfect code immediately, but also to keep everything as it is, is also not good. It often happens that the original implementation does not have the ability to scale when it is necessary to introduce new features. After all, it is almost impossible to predict all possible changes in future versions of the project. Also, no architecture guarantees 100% coverage of all cases. Therefore, it is important to make changes to the existing code in order to adapt it to the new features.
Source: https://habr.com/ru/post/450206/
All Articles