_{Photo: ivan dupont}

Hello! My name is Dmitry Isaikin, and more recently, I am engaged in mobile development. Why recent? Three months ago I was the head of the C / C ++ group for the development of Mail.Ru Mail. But once I once again thought about the fact that I less and less like what I do. More time began to take away the duties of the team leader: motivation, stimulation, accountability, administrative concerns. And then I decided: it's time to change something. Posted a resume, went to a few interviews. All this time I thought about what I want. I was offered to head the direction of development in one fairly large company, and I almost agreed. But, “having slept” with this decision a sleepless night, I realized that such work would not be my joy. There was also an option to go as a senior developer to another good company. But there they would have to do about the same work as in previous years.

Either as a joke, or seriously, I suggested moving to another department to the position of an iOS developer (this was a completely unfamiliar area). I have long wanted to do something new, but I was stopped by the inevitable drop in income in this case. And with the internal transition, a fall in wages could have been avoided. A miracle happened - they took me. Without an interview, without a trial period (in fact, the interview did take place a week later, during which I read the documentation, tutorials, Habr and various articles on iOS development for 12 hours a day). In this way, after having spent nearly ten years as a developer of high-loaded server solutions, I discovered a completely new, wonderful and huge world of client side.

Now, three months later, I can firmly state that I made the right choice. During this time I learned a lot of new things, I began to comprehend the wisdom of client development. I looked at the server “on the other side of the barricades” (I used to work on the server part of the Mail.Ru and My.com mail services, now I am developing their mobile versions).
')
Server and client development are very similar. But there are also quite significant differences that require completely different approaches in solving the same tasks. I’m sure that I’m not going to become a client-side guru soon, but I decided to share my thoughts on this. Notice, the purpose of this article in no case was made an attempt to find out that the client or the server is cooler. On the contrary, I will try to show that each of these worlds is unique, and that a developer can benefit a lot from the transition from one area to another.

Work environment

Any more or less complex server system consists of a sufficiently large (several dozen) number of interconnected components. These are databases (we mainly had MySQL and Tarantool), queues, web servers, proxy servers, balancers, monitoring systems, backups, a bunch of self-written services with the necessary business logic. When developing a new functionality, it is often necessary to change the code of several components at once. To check and debug the code, it is convenient to have your own installation of the entire system. It needs to be deployed, configured, filled with test data. And then periodically update and rebuild, as many components are in active development. By the way, the complexity and heterogeneity of the server system implies the need to somehow manage this complexity. These are various systems of deployment, management, configuration, monitoring, diagnostics, collection, analysis and storage of logs. Sometimes the development of these infrastructural components has to spend the lion's share of time and effort.

When developing a client mobile application, the main part of this complexity is hidden behind server APIs. In most cases, the production-cluster acts as a server for the test version of the application, so no effort is required from the client developer to support it. All that is needed for development is a powerful enough laptop with SDK and IDE installed. Well, the test phone.

Scalability

How often this happens in server life: for some reason (mass mailings on Valentine's Day, or search engine optimizers tried, or managers bought traffic, or major sales began - specific scenarios depend on the specifics of the service) there is a serious influx of users. The load on the server system increases. One of the subsystems (usually the database) is slightly degraded due to the increased load, begins to respond more slowly, or even ceases to fit within an acceptable response time. As a result, the total processing time of a single request on the business logic server increases, which, in turn, leads to an increase in the number of simultaneously working workflows. The server is running out of free memory, the operating system, trying to serve an increased number of processes, is now mainly involved in context switching and shuffling pages in memory. This worsens the situation even more. Here the balancer is involved, throwing a dull server out of the load and thereby increasing the load on the servers remaining in the line. Congratulations, our site is laid down, and raising it without removing the load will be very problematic.

It is clear that such situations usually arise only at the very beginning of the development of a new service. In the future, either the developers correct the lack of the system, or the service is gradually bent.

In order to successfully experience such excesses, the server software must be sufficiently “elastic” and scalable. Then the growth of the load will not lead to the failure of the service entirely, but, for example, only to a slight degradation in the speed of processing requests. In this case, the temporary increase in load can just wait, and if the load has increased forever (that is, the service has become more popular), it is enough to compensate for it by delivering the required number of servers. Sometimes for this it is necessary to seriously rework the architecture of the entire application, purposefully looking for and eliminating the bottlenecks of the system.

In the world of client software, there is simply no such problem. Each user brings with him a device with its own processor and memory. And no matter how many installations of the application, each copy of it works on its device.

Equipment failure

Server software should be able to survive hardware failure. If one of the servers fails, the system must continue to work as if nothing had happened. Not only that user data should not be lost - ideally, users should not notice anything at all. To achieve high availability, techniques such as data replication, hot-swap servers, redundancy, server duplication, and the elimination of single points of failure are used. Fallen requests due to server failure can be redirected to another server group (depending on the business logic).

And if, for example, the phone fails, no one will demand that the application continue to work on this device. The user will burn, of course, but then he will go and buy himself a new phone - most likely, more cool and powerful. Again, install the applications he needs and continue to work. The main thing that our application was not to blame for the breakdown of the phone.

Bandwidth and response speed

Perhaps one of the most important non-functional requirements for a client application is the responsiveness of the application interface to user actions. Moreover, it is the subjective sensations of the speed of response that are essential, and not the real response. The user does not like to wait: if he turned to the application, then right now he needed to do something important. And when the application slows down, it's annoying. Noticed how slowly the CI server starts to work when you are about to go home and just want to make sure that this time the tests will pass successfully? Sometimes you have to sacrifice the real speed of work, just to create the impression that the user has the maximum performance of the application. For this purpose, for example, animation and progress indicators are used.

For server software, on the contrary, it is important to be able to process a huge number of simultaneous requests (there are many users, few servers), preferably with a minimum request processing time (latency). But the response generation time is by no means the main parameter during optimization. Sometimes a slight increase in processing time can significantly improve the throughput of the system as a whole. For example, once it was a great revelation to me that some clients for a memcache postpone execution of requests for several tens of milliseconds in order to group them into one request.

Updates

The big plus of server development for me personally is the possibility of precise control of software versions working in production. Usually in combat, no more than two versions spin at the same time (I’m talking about in-house development, with boxed products everything is much worse). This allows you to keep in mind one current version of the code base. After detecting and correcting an error about it, you can safely forget it; you do not need to backport edits to other supported versions of the program, the code of which has already been almost repeatedly rewritten. No need to understand whether this bug is also there and how to fix it in this particular code variation.

The control of combat versions also makes it possible, relatively easily and smoothly, in several stages, to conduct a move to a new data scheme. Usually moving is carried out in three stages. First, a version that can read data in both formats, both old and new, rolls out. After everyone makes sure that the system works in a regular mode, without bugs, it is replaced by a version of the program, which, like the previous one, reads data in both formats, but already writes only in a new format (in fact, the rollout can simply be in the inclusion of options in the config - depends on the specific case). Then, after the end of the complete data conversion, the support code of the old format is completely deleted. Relocation completed.

So, on the server it is necessary to ensure the correct functioning of the system in a situation where some of the servers have already been updated, and they want data in the new format, and some of the servers do not yet exist, and submit data in the old format to them. But on the client, there is no such problem with data schema migration. When updating the application at a convenient time for the user (when he himself agreed to install the update and is ready to suffer a little), you can safely convert the data in a monopoly mode, successively applying to it a series of necessary transformations. That is, there is even no need to develop an intermediate version. Beauty.

But here is a zoo version on the client for sure. And I, as a former server developer, do not like it. As soon as I imagine that someone, using the application, stumbles on for a week or a month as a bug that I have fixed ... Maybe I will get used to it in time, but for now I’m already throwing a shiver!

For example, if a critical error is detected on the server, we can quickly make a fix, develop a set of measures to repair broken data, and roll out this fix to production-servers in a short time. In the case of a mobile application, even if the corrected version is promptly placed on the stop, there is no guarantee that the user will throw it in to update. Someone saves Internet traffic, someone has no time to update, someone has no updates at all. And some could even remove the "buggy attachment."

Resource management

Modern mobile phones have quite serious computational capabilities, which allows the developer to focus not only on efficiency, but also on the beauty of the code. Popular languages ​​in client development also contribute to this. I am glad that I got to know Objective-C right now, when automatic reference counting is used throughout the language. C / C ++ allows you to use resources very efficiently, and this optimization opportunity often leads to an excessive complexity of the algorithm - just to allocate memory on the stack, and not on the heap, just to reduce the number of calls to virtual functions. The dynamic nature of Objective-C, in which there are practically no opportunities for premature optimization, initially causes internal resistance, but after a while the voltage drops, and you start to get a more flexible, beautiful, concise code.

Conclusion

As you can see, the client and server programmer has completely different tasks. Their programs operate under completely different conditions, with almost diametrically opposite requirements being put forward to them. Accordingly, they solve problems in different ways. Different approaches are used, architectural solutions. Even our views on life are different, I guess.

So was it worth going over to the other side of the barricades? In my case, it was worth it. Often in our lives, high professionalism means narrow specialization. The more a person dives into his area, the more he is “sharpened” under it. This is a natural process. Over time, this, however, leads to the fact that a person stops developing, learning new things. His knowledge and experience are fully sufficient for the effective solution of the tasks facing him. He gets bored. In this case, the most correct and successful choice may be a change of profession or at least a direction.

So, you also began to notice a loss of interest in your work? Do not rush to post a resume, for a start, I would advise to understand the reason. Will the problem be solved by changing jobs? Maybe you will be able to achieve your goals and fulfillment of desires at this work, to the mutual benefit for yourself and the company?

For example, do you think that nobody notices your results, do you crave fame, but does it not come up? Then it makes sense to make a presentation at a profile conference or a fashionable meeting. Or maybe you are tired of constantly “messing up” and stepping on the same rake? Learn from the lessons and plan how to avoid such mistakes in the future. Or, for example, do you want more authority? Most of the leaders (right ones) are happy to delegate part of their duties if an able, reliable and responsible person is ready to take them. Enough to come and ask. But note that more authority usually implies greater responsibility.

If you are dissatisfied with the quality of the product released by your team or you do not like the approach to development or testing, release planning (or maybe you do not even have release planning as such), then it may well be that you can correct everything. Well, or at least something to improve. Analyze what needs improvement. Maybe it's time to start writing unit tests? Start by writing a couple of tests for your new functionality. See that the manager has poorly formulated your task? Meet with him and try to clarify the details, discuss the problems and shortcomings that you see.

But suppose you understand that you don’t like your profession. Let's choose. The main thing - do not go on about the fashion. Modern society dictates: of course, you need to go up, become the head - you will drink coffee and not do anything at all. Firstly, this is not true - you will have to work a lot, just the responsibilities will be different. And secondly, even if so, how long can you not do anything? There is a big difference - doing nothing for two weeks while on vacation or for life. So first figure out whether you want to become a boss, take responsibility for other people, or is it just a tribute to fashion. Very often, people find themselves in unloved work just because of fashion. In my opinion, the best solution is to find an option in which your previous experience will provide a synergistic effect. For example, if you were an excellent purchasing manager, your experience can help you become an excellent sales manager.

Programmers can advise you to try your hand at testing. Your skills and knowledge of the specifics of the development will help you with the appropriate desire to become a very good tester. In essence, the task of the tester is to make sure that the program satisfies the declared characteristics. The task of the programmer is to make the program satisfy them. Tasks are similar, but different. And problems arise different. And they need to be addressed in different ways. Related field experience can help a lot. Similarly, a tester can try his hand at developing. His testing skills and a look at the system in terms of quality assurance and quality control will help him become a very good programmer. Again, in the presence of desire and ability.

If you also decide to do client development for iOS, do not postpone it. To get basic knowledge, just read a few manuals on the official Apple website. In addition, GitHub is full of finished projects on almost all topics. Read their code - it will allow you to quickly and fully understand the practical aspects and secrets of development for iOS.

And some used literature.

• Programming with Objective-C
• Introduction to runtime language
• App Programming Guide for iOS
• Interface Design Guidelines (HIG)
• Useful articles about runtime language: Objective-C Runtime. Theory and practical application , Extending existing methods (Method Swizzling) , Objective-C what is actually a method and self? + runtime , Objective-C runtime from within
• UIViewController'a life cycle
• iOS Navigation View Controller example
• Auto Layout Tutorial in iOS 9 Part 1: Getting Started
• Adaptive Layout Tutorial in iOS 9: Getting Started
• The development guru's blog can be read in its entirety: NSBlog "A failure in the hot air department"
• Also a very good site: NSHipster is a journal of the overlooked bits in Objective-C, Swift, and Cocoa.
• Memory management, deeper immersion: About Memory Management
• Method of error handling adopted in the language: Introduction to Error Handling Programming Guide For Cocoa