April 30, 2019 at 18:26Tips 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 outsource and in outstaff, I even had a chance 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 single out some principles or rules for a qualitative approach to application development. At first it was advice to my friend. Giving him advice, I thought that I lacked such advice when I was just starting my development path. What can I say, some moments I realized for myself relatively recently, and some are already at a new place of work. And so the idea came up to make a list of tips that I would like to share with myself five to six years ago. I’m sure that in another five years I will have something to say to myself today.
And the first thing I would like to say to myself as before is: “Your code is bad!”. In common people, “govnokod”. And my foreign colleagues in the development workshop have “monkey code”.
No, this is not what you thought. I do not want to emphasize that I used to be a bad coder, and 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 caught themselves thinking that they could not figure out the new library or the new technology. Or some of us have gone to extremes in trying to write the feature perfectly, following all the principles of OOP, SOLID. Which in turn led to a lot of time and sometimes led to a dead end. Sometimes, in attempts to write the perfect code, monsters were born that carried a 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 first of all worry, be nervous about the quality of your code. It is impossible to predict everything. And it’s better to just relax, write easier, and as you know, than to suffer and worry in vain. With experience, decisions will come by themselves. Sometimes it’s necessary to “nagovodnodit”, they will encounter problems that this shitcode will cause and understand once and for all that it’s better not to do this.
The second moment, which I mentioned earlier, is that it is almost impossible to predict everything. Yes, With experience comes the understanding of what you are doing And you can predict the development path of the project. But it comes with experience. And if experience is not enough, then you should not try to make the code universal. There are frequent cases when your feature, which you thought for a long time and so carefully at first, and then wrote, is simply thrown out of the application. Also, there are cases when applications change only because at the customer’s mind it all seemed different. And after long hours of painstaking transfer of the interface from design to code, 100,500 changes suddenly appear. This is only the beginning, because after the first redoing, more and more new edits will come. And in the case when the developer does not have enough experience, this process can take not only a lot of time, but also bring not the most pleasant sensations that are put off by unpleasant thoughts somewhere in the secret corners of the mind, turning the development process from a fun lesson into hellish pain. Therefore, take care of your nerves and do not suit the ideal. Sometimes you can talk a little bit.
Third point: this is again a purely psychological moment, namely criticism from other developers. As everyone knows, all domestic developers consider any other code - shit code. Even if he is shown his own code, which he does not recognize, he is likely to call him a shit. Often such criticism is accompanied by the moral satisfaction of the critic himself. As noted by experienced developers, it’s the people who most often call someone else’s code govnodkod exactly those who at one time novnokovodil more than. And the louder someone screams “govnokod”, the more of his “cakes” he left in his path.
In addition, any virgins who recall themselves young must necessarily admit that he has been a novocode to fame.
Therefore, I advise you to use the expression "Your code was and will be a shit", as a shield from not always constructive criticism. I also want to note that your code will always be shit because development does not stand still. Every year the quality of your code only improves. So the current code will eventually turn into govnokod.
I don’t want it to seem that I advise only govnokod, therefore I will begin to give advice on how to avoid that bad code. And I would like to start with the principle that I have set aside 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 you to replace the solution of one large problem with a series of smaller tasks, albeit interconnected, but simpler.
As Wikipedia says. But this is only part of what I put in 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 direct captain of evidence. But! In practice, these boundaries are often blurred and it turns out that the ViewController or Activity contains a piece of business logic.
I think an example of the “Login” screen will be simple and understandable. Here the developer begins to implement the MVC architecture. It seems there is a separate View, like Controller with Model also adds, as it should. 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 abandoning such vicious thoughts and strictly adhere to the principle of “Divide and conquer” to separate UI and business logic . And even if the architecture requires the addition of a ViewModel class, in which there will be one two lines of code, you should do so. Because there are often cases when a screen in which there was originally one button, over time, grow to unthinkable difficulties. If you follow the separation of logical components in advance, then this will greatly facilitate life in the future.
You can especially feel the essence of the strict separation of UI and logic, in cases where you have to transfer screens from one project to another. Or in a situation where, under different conditions, different algorithms are used in business logic. 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 the strict separation, I would add the separation of screens and navigation logic for mobile applications. What do I mean by that?
My practice has prompted me to make it easier to code for a particular screen by taking out the navigation logic separately. A screen, specifically View, for iOS is a UIViewController, and sometimes a UIView, and for Android Activity, or Fragment, they should not be engaged in a function to display itself, as well as switch to other screens. Each of these classes should only care about what is happening on a particular screen, or rather, only for rendering a specific screen and interacting with a business logic class (Presenter, ViewModel and others).
These are just two of many examples where you need to fundamentally follow the separation. Following this principle will greatly facilitate further work with the project. Even if govnokod is got in any of separate components.
Seamlessly proceeding from the previous advice, I want to move on to the next one, namely strict adherence to a single style in the project.
What do I mean by that?
To begin with, the key word here is strict, 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 general appearance of the project and greatly facilitate the navigation of the project, search by code, and speed up the process of introducing a new developer to the project. I think it’s not worth reminding that after a while we ourselves can become this new person with our old code.
Again, proceeding from 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 talk about the best architectures or to say that you need to choose this 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 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 be applied. Be it VIPER, REDUX, MVP or MVC. There are of course pros and cons to each of the above architectures. Over time, more and more new approaches to the design of the architecture of the project.
I will say more specifically about my idea. If you have already started using VIPER, then strictly follow its principles. Even if it seems that for a one-button screen there are too many files to create units of lines of code, do not bypass these rules under any circumstances. Because, at such moments like this, the govnokod is born, which then, like a snowball, everything grows and grows.
I advise you to get acquainted with the most popular architectures and choose either the one you like or the most popular before starting a new project. I strongly recommend choosing the second option, namely starting with the most popular architecture, as 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 in which cases it is recommended to use it.
For example, if you have a small project on which there are one two developers, then you should not take VIPER due to the fact that this is a rather cumbersome architecture that performs very well on large projects and in large teams. So that there are no cases when the code for creating VIPER is many times more than the code of the business logic itself.
Personally, I now prefer the MVVM + Router architecture. It works well on a small project where I am a single developer.
Bottom line: the main thing is not which architecture you have chosen, but how exactly do you follow it.
I also want to add, if the project is not being developed from scratch, then first of all you need to familiarize yourself with the current architecture and the general style of the project, and begin to follow it. You should not break out with screams that there is govnokod (returning to the first advice) and start redoing everything. An exception may be a complete anarchy on the project or the lack of a common style.
In conclusion, I want to say that pausing for refactoring is a good approach. Refactoring is a very important part of quality application development. Yes, we don’t write the perfect code right away, but leaving it as it is is not good either. It often happens that the original implementation does not have the ability to scale when you need 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 existing code in order to adapt it to new features.
Your code is bad
And the first thing I would like to say to myself as before is: “Your code is bad!”. In common people, “govnokod”. And my foreign colleagues in the development workshop have “monkey code”.
No, this is not what you thought. I do not want to emphasize that I used to be a bad coder, and 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 caught themselves thinking that they could not figure out the new library or the new technology. Or some of us have gone to extremes in trying to write the feature perfectly, following all the principles of OOP, SOLID. Which in turn led to a lot of time and sometimes led to a dead end. Sometimes, in attempts to write the perfect code, monsters were born that carried a 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 first of all worry, be nervous about the quality of your code. It is impossible to predict everything. And it’s better to just relax, write easier, and as you know, than to suffer and worry in vain. With experience, decisions will come by themselves. Sometimes it’s necessary to “nagovodnodit”, they will encounter problems that this shitcode will cause and understand once and for all that it’s better not to do this.
The second moment, which I mentioned earlier, is that it is almost impossible to predict everything. Yes, With experience comes the understanding of what you are doing And you can predict the development path of the project. But it comes with experience. And if experience is not enough, then you should not try to make the code universal. There are frequent cases when your feature, which you thought for a long time and so carefully at first, and then wrote, is simply thrown out of the application. Also, there are cases when applications change only because at the customer’s mind it all seemed different. And after long hours of painstaking transfer of the interface from design to code, 100,500 changes suddenly appear. This is only the beginning, because after the first redoing, more and more new edits will come. And in the case when the developer does not have enough experience, this process can take not only a lot of time, but also bring not the most pleasant sensations that are put off by unpleasant thoughts somewhere in the secret corners of the mind, turning the development process from a fun lesson into hellish pain. Therefore, take care of your nerves and do not suit the ideal. Sometimes you can talk a little bit.
Third point: this is again a purely psychological moment, namely criticism from other developers. As everyone knows, all domestic developers consider any other code - shit code. Even if he is shown his own code, which he does not recognize, he is likely to call him a shit. Often such criticism is accompanied by the moral satisfaction of the critic himself. As noted by experienced developers, it’s the people who most often call someone else’s code govnodkod exactly those who at one time novnokovodil more than. And the louder someone screams “govnokod”, the more of his “cakes” he left in his path.
In addition, any virgins who recall themselves young must necessarily admit that he has been a novocode to fame.
Therefore, I advise you to use the expression "Your code was and will be a shit", as a shield from not always constructive criticism. I also want to note that your code will always be shit because development does not stand still. Every year the quality of your code only improves. So the current code will eventually turn into govnokod.
Divide and rule
I don’t want it to seem that I advise only govnokod, therefore I will begin to give advice on how to avoid that bad code. And I would like to start with the principle that I have set aside 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 you to replace the solution of one large problem with a series of smaller tasks, albeit interconnected, but simpler.
As Wikipedia says. But this is only part of what I put in 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 direct captain of evidence. But! In practice, these boundaries are often blurred and it turns out that the ViewController or Activity contains a piece of business logic.
I think an example of the “Login” screen will be simple and understandable. Here the developer begins to implement the MVC architecture. It seems there is a separate View, like Controller with Model also adds, as it should. 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 abandoning such vicious thoughts and strictly adhere to the principle of “Divide and conquer” to separate UI and business logic . And even if the architecture requires the addition of a ViewModel class, in which there will be one two lines of code, you should do so. Because there are often cases when a screen in which there was originally one button, over time, grow to unthinkable difficulties. If you follow the separation of logical components in advance, then this will greatly facilitate life in the future.
You can especially feel the essence of the strict separation of UI and logic, in cases where you have to transfer screens from one project to another. Or in a situation where, under different conditions, different algorithms are used in business logic. 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 the strict separation, I would add the separation of screens and navigation logic for mobile applications. What do I mean by that?
My practice has prompted me to make it easier to code for a particular screen by taking out the navigation logic separately. A screen, specifically View, for iOS is a UIViewController, and sometimes a UIView, and for Android Activity, or Fragment, they should not be engaged in a function to display itself, as well as switch to other screens. Each of these classes should only care about what is happening on a particular screen, or rather, only for rendering a specific screen and interacting with a business logic class (Presenter, ViewModel and others).
These are just two of many examples where you need to fundamentally follow the separation. Following this principle will greatly facilitate further work with the project. Even if govnokod is got in any of separate components.
Single style
Seamlessly proceeding from the previous advice, I want to move on to the next one, namely strict adherence to a single style in the project.
What do I mean by that?
To begin with, the key word here is strict, 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 general appearance of the project and greatly facilitate the navigation of the project, search by code, and speed up the process of introducing a new developer to the project. I think it’s not worth reminding that after a while we ourselves can become this new person with our old code.
The choice of architecture and following it
Again, proceeding from 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 talk about the best architectures or to say that you need to choose this 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 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 be applied. Be it VIPER, REDUX, MVP or MVC. There are of course pros and cons to each of the above architectures. Over time, more and more new approaches to the design of the architecture of the project.
I will say more specifically about my idea. If you have already started using VIPER, then strictly follow its principles. Even if it seems that for a one-button screen there are too many files to create units of lines of code, do not bypass these rules under any circumstances. Because, at such moments like this, the govnokod is born, which then, like a snowball, everything grows and grows.
I advise you to get acquainted with the most popular architectures and choose either the one you like or the most popular before starting a new project. I strongly recommend choosing the second option, namely starting with the most popular architecture, as 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 in which cases it is recommended to use it.
For example, if you have a small project on which there are one two developers, then you should not take VIPER due to the fact that this is a rather cumbersome architecture that performs very well on large projects and in large teams. So that there are no cases when the code for creating VIPER is many times more than the code of the business logic itself.
Personally, I now prefer the MVVM + Router architecture. It works well on a small project where I am a single developer.
Bottom line: the main thing is not which architecture you have chosen, but how exactly do you follow it.
I also want to add, if the project is not being developed from scratch, then first of all you need to familiarize yourself with the current architecture and the general style of the project, and begin to follow it. You should not break out with screams that there is govnokod (returning to the first advice) and start redoing everything. An exception may be a complete anarchy on the project or the lack of a common style.
Refactoring Pauses
In conclusion, I want to say that pausing for refactoring is a good approach. Refactoring is a very important part of quality application development. Yes, we don’t write the perfect code right away, but leaving it as it is is not good either. It often happens that the original implementation does not have the ability to scale when you need 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 existing code in order to adapt it to new features.