Working in the IT industry for more than ten years, I want to tell you...
**
Only focus on subdivisions, people who do not lay a good computer foundation are actually quite easy to hit a wall.
Some time ago, a friend’s company had a lot of bugs in the Android client, and he found a new Android development to take over. He didn’t know the technology himself, and wanted me to help me see how the new Android development level is.
I actually went there with a half-push-and-half mentality. After all, I felt that laymen's guidance to experts is blind command.
But after reading the code base and chatting with the developers, I found more and more that, in fact, their Android development team had obvious problems:
1. The data structure foundation is not solid.
The data structure has always been recognized as ArrayList. There are a lot of key-value lookups in the business, and it must be traversed by list. When asked why, the developer replied that HashMap is not useful because it doesn't know much, and List can also be implemented. As for what is HashSet? Can you eat it?
2. The code design ability is weak, the OOP understanding is not comprehensive, and the logic branch management is not in place.
There are more than ten variables of a class member. After reading the code carefully, we find that many of them are temporary variables at the function level, and there is no need to upgrade them to the class member level. Asking the reason is to say, "If you think about it, write it down, maybe it will be useful in the future." With so many member variables, I just want to scold my mother when debugging.
For some objects with complex state management, such as uninitialized, initialized, failed initialization, and repeated initialization of the map SDK, these state branches are not fully covered. Just follow the example in the Demo, and only deal with the operation logic assuming successful operation. The logic branch is ignored. As a result, the program hangs when the SDK state falls into the branch that the code does not handle during the actual runtime. These problems are difficult to find through black box testing.
3. Too superstitious about frameworks and feel that Android development is simply based on a set of frameworks.
In the code base of Friend's company, the realization of the singleton pattern is bizarre. Some threads are not safe, some are extremely verbose. Communicating with the developers, they found that they are very superstitious about some of the writing in the framework, and they think it is absolutely correct. Everyone is right to do this. As for why they only do it, they don’t think too much, and they won’t consider applying it. Sex.
A developer in a friend’s company wrote a set of so-called "framework" and put it on github for people to use, and there are hundreds of stars. After reading it, I feel that this thing is not so much a framework, but more like "killing you." 3000" is the same thing: it relies on a lot of different frameworks written by other foreigners, and writes and encapsulates some initial scaffolding code to become its own framework. Even in the business code he wrote, the EventBus event listener was not removed correctly when the Activity exited, but he had a high level of confidence in his own level, and felt that he was a stubborn talent in my friend's company.
4. The basis of Java native multi-threaded programming is almost zero. Synchronized and volatile semantics are not understood, and thread applications are basically new and start. Nothing else. Not to mention the tool classes in the concurrent package.
At that time, I told my friends about it. My friends thought they could interview first to see if there was a better one, ride a donkey to find a horse, and if there was a suitable trial period, they would invite this bodhisattva away. I just bite the bullet and take a look.
At that time, the conditions for JD to open were 2-3 years of work experience, about 15K before monthly salary and taxes, and a bachelor degree. According to experience, it is not difficult to find a decent Java back-end development under this condition, even if it is not a high salary. But after interviewing more than ten people, I became a little desperate.
In response to existing problems, I paid more attention to data structure foundation and code design during the interview. There are only 2 people who can answer the data structure very well, and the others are similar to the current level. In terms of code design ability, it is also a common weakness. Let him implement a cache by himself, and there should be many people who can't say anything about the connection method, let alone the implementation details. As for the HTTP protocol, some details such as GET and POST are not answered well, and there are very few people who know about HTTPS.
But these should be really universal questions for the usual Java interviews. Android development is really more than just binding a view, sending a network request, and then updating the interface. Many Android developers only stay in a state of self-satisfaction when they can read or store apps. If you understand the four major components, butterknife and retrofit can be a fresh trick. But in my opinion, the front-end development is more difficult than the back-end, for example:
1. There are many asynchronous operations and complex state management. In order to fully manage the state of view and model in the callback hell, at the same time, the class responsibilities are allocated well, and the activity does not expand. Just doing this well, I think it is already commendable. Many people in MVP follow the example. As for why it is done, it is easy to pass. Moreover, the design model is not a panacea. It does not mean that it will be good after use. It depends on the applicable business scenario.
2. The state recovery needs to be handled well. As long as the complex business process is long, you need to consider how to recover the interrupted process, whether it is handed over to the back-end for maintenance, or the front-end records information and submits it as a transaction. My friend’s app often fails to be restored after being forced out, or the information from the previous order is left over to the next order.
3. Version management and migration of local data when overwriting, installing and updating apps. Take QQ Music as an example. Such a huge song library and playlist will definitely use a lightweight database similar to sqlite locally. During the overwrite installation, the table structure may need to be updated. How to manage the cross-version db structure upgrade and exception handling are all university questions. Even if you don't use this level of sqlite, how to manage the cache data in SharedPreference is a matter of thinking.
4. Adaptation to multi-version systems. Needless to say, everyone knows it.
The above problems are the same problems encountered even in iOS development. So I think when interviewing for an Android development position, it is really not too much to examine the basics of JavaSE. If he asks you about the content of EE, you can really roll his eyes.
As for using kt as a shield, the Java foundation is not solid, and there will only be more problems with kt. JVM is a barrier that cannot be bypassed. Do you know what happened to the synchronized annotation in kt? Do you know the difference between inline and crossinline?
I have used kt for half a year, and I feel trembling, and the places where the effect is uncertain and stable are all implemented in old and practical Java. But the kt coroutine is really fragrant, and the callback can be eliminated on android.
I have always felt that, as a developer, you must always maintain a sense of crisis, always look farther and learn more, and you will not be unemployed at 30. As the saying goes, if you have more skills, don’t you have to do it.
Over the years, I have collected and sorted out a lot of Java learning materials based on my experience and peacetime. There are also a lot of interview materials
for mind mapping for my continuous update of the knowledge base. If you need it, you can let me know in the comments below