The first job, or how not to develop under iOS
In this article I will try to talk about non-trivial problems that novice developers may encounter. If you, dear reader, are already working in this area, you are unlikely to get something new for yourself, but if you are just learning or taking your first steps, then some of these tips can help you. They will touch the language a little and relate more to some common things related to the development process. If the article turns out not to be trivial, then I will try to write similar articles on the subject of some specific tasks.
Introductory five words about myself and why I want to write this article: graduated from Bachelor of Moscow State Technical University. N. E. Bauman, Swift and iOS began to study development on CS193P in the summer of 2015, had not had any programming experience before. Having found my first job, which in its essence is a kind of startup, I really did not understand what UITableView is, asynchrony, I did not even hear about cocoapods. The task was to write a large, about 50 screens, client-server application. After half a year of work, the application is close to readiness. And now, rewriting the same UIViewController for the third time, I thought that if someone would tell me all those already seemingly obvious things, when I first started, the development process would be reduced by a month, and the number of negative emotions received during the work, many times.
The first 3 months I used the version control built into xcode, and everything was fine until a second developer joined me. The number of some amazing errors at the xcode level was incredible, sometimes a simple merge took 2 hours of time. Of course, after some time we have already avoided all the pitfalls, but every time we pray that everything goes well is not a very pleasant activity, because we tried to use the console, and since then there has not been a single problem with this part of work ...
Never, never try to work in one .storyboard file, even if you are programming one. Spread more or less complete UI blocks into separate files. It will save you work days. At first, everything is just fine, but, .storyboard is inherently an XML file, and therefore, when working with one file by several people, any attempt to merge will cause a conflict. And then you have to open the file as XML and correct everything there with your hands, which is hellishly hellish. Another pitfall that manifests itself in the later stages of development is the wild lags when working with it. If you have in .storyboard, for example, 30 screens, then on MacBook Air 13 '2012 it will open about 30 seconds, if xcode just does not crash with an error.
')
I don’t know, maybe I’m the only one, but when I started, I thought: “ Pf, then I will comment everything at once, why it is necessary at all, I’ll never watch my code, and I know what I wrote .” This is a huge mistake. When I now rework the code that I wrote at the very beginning, I actually do it all over again, because, looking at the code, I just don’t understand why I did this or that thing, where this function came from or why I introduced this condition . You should always leave at least a minimal comment to what you have written, otherwise, then you will encounter the fact that you will spend twice the time to parse the written.
If you work for someone and started doing some work without a structured and transparent technical task - you are in shit. Lack of TK leads to total darkness in the work when you redo one screen 10 times, because the customer / boss / the one who pays money will come up with new crazy ideas that you will have to embody, embodying them your application deadline will move, and You will think that once you change one and the same thing 10 times, the term moves. Not. They will ask you in time, and to dissuade that you reworked something there may turn out to be good, but the situation is not pleasant. Always ask meticulously about each item of the assignment to avoid such situations.
This site is a Mecca of novice developers, and it is certainly fantastically useful, applicable to iOS development, but a couple of things are also associated with it, which I did not discover immediately. Firstly, you should not take the first correct solution: such a rush at a long distance can lead to the fact that after a while you look at this code and pierce your face with a facepalm. Look at a few solutions and think about which one is more applicable to your situation. Secondly, try not just copying the code, but trying to figure it out, this speeds up the learning process, but, most importantly, in which case you can change this code without the participation of search engines. This implies thirdly: stack overflow perfectly helps with standard tasks, but as soon as you have non-trivial problems that completely relate only to your code - it’s better not to hope for help from there, but then you will be helped by the skills of using documentation and knowing your code, derived from second.
Maximum customize your UI-elements with the help of an assistant. Code clutter with something like
Create folders for groups of files from the beginning. Those folders that are displayed in the left-hand menu of xcode do not have anything with the physical location of the files: when you drag a file into such a folder, it will remain on the hard disk where it was created. When creating it, it is very important to immediately think where this file will be located, since in the future you can change its address, and there will be no problems with one file, but I discovered this when there were about 50 files in my root, which I then manually moved there where it was supposed to be from, and there was little pleasure in it.
That's all, I hope someone this advice will help avoid the problems that I faced.
Introductory five words about myself and why I want to write this article: graduated from Bachelor of Moscow State Technical University. N. E. Bauman, Swift and iOS began to study development on CS193P in the summer of 2015, had not had any programming experience before. Having found my first job, which in its essence is a kind of startup, I really did not understand what UITableView is, asynchrony, I did not even hear about cocoapods. The task was to write a large, about 50 screens, client-server application. After half a year of work, the application is close to readiness. And now, rewriting the same UIViewController for the third time, I thought that if someone would tell me all those already seemingly obvious things, when I first started, the development process would be reduced by a month, and the number of negative emotions received during the work, many times.
1. git, xcode, console
The first 3 months I used the version control built into xcode, and everything was fine until a second developer joined me. The number of some amazing errors at the xcode level was incredible, sometimes a simple merge took 2 hours of time. Of course, after some time we have already avoided all the pitfalls, but every time we pray that everything goes well is not a very pleasant activity, because we tried to use the console, and since then there has not been a single problem with this part of work ...
2. storyboards
Never, never try to work in one .storyboard file, even if you are programming one. Spread more or less complete UI blocks into separate files. It will save you work days. At first, everything is just fine, but, .storyboard is inherently an XML file, and therefore, when working with one file by several people, any attempt to merge will cause a conflict. And then you have to open the file as XML and correct everything there with your hands, which is hellishly hellish. Another pitfall that manifests itself in the later stages of development is the wild lags when working with it. If you have in .storyboard, for example, 30 screens, then on MacBook Air 13 '2012 it will open about 30 seconds, if xcode just does not crash with an error.
')
3. Commenting and documentation
I don’t know, maybe I’m the only one, but when I started, I thought: “ Pf, then I will comment everything at once, why it is necessary at all, I’ll never watch my code, and I know what I wrote .” This is a huge mistake. When I now rework the code that I wrote at the very beginning, I actually do it all over again, because, looking at the code, I just don’t understand why I did this or that thing, where this function came from or why I introduced this condition . You should always leave at least a minimal comment to what you have written, otherwise, then you will encounter the fact that you will spend twice the time to parse the written.
4. Terms of Reference and Schedule
If you work for someone and started doing some work without a structured and transparent technical task - you are in shit. Lack of TK leads to total darkness in the work when you redo one screen 10 times, because the customer / boss / the one who pays money will come up with new crazy ideas that you will have to embody, embodying them your application deadline will move, and You will think that once you change one and the same thing 10 times, the term moves. Not. They will ask you in time, and to dissuade that you reworked something there may turn out to be good, but the situation is not pleasant. Always ask meticulously about each item of the assignment to avoid such situations.
5. Stack overflow
This site is a Mecca of novice developers, and it is certainly fantastically useful, applicable to iOS development, but a couple of things are also associated with it, which I did not discover immediately. Firstly, you should not take the first correct solution: such a rush at a long distance can lead to the fact that after a while you look at this code and pierce your face with a facepalm. Look at a few solutions and think about which one is more applicable to your situation. Secondly, try not just copying the code, but trying to figure it out, this speeds up the learning process, but, most importantly, in which case you can change this code without the participation of search engines. This implies thirdly: stack overflow perfectly helps with standard tasks, but as soon as you have non-trivial problems that completely relate only to your code - it’s better not to hope for help from there, but then you will be helped by the skills of using documentation and knowing your code, derived from second.
6. @IBInspectable
Maximum customize your UI-elements with the help of an assistant. Code clutter with something like
self.customView.backgroundColor = .clear not good, but if it is all the same necessary, carry all these settings into a separate function, this will help keep your code readable.
7. Folder Tree
Create folders for groups of files from the beginning. Those folders that are displayed in the left-hand menu of xcode do not have anything with the physical location of the files: when you drag a file into such a folder, it will remain on the hard disk where it was created. When creating it, it is very important to immediately think where this file will be located, since in the future you can change its address, and there will be no problems with one file, but I discovered this when there were about 50 files in my root, which I then manually moved there where it was supposed to be from, and there was little pleasure in it.
That's all, I hope someone this advice will help avoid the problems that I faced.
Source: https://habr.com/ru/post/315000/
All Articles