What is the realm of true mastery of Java?

As a software developer, the pursuit should be to constantly improve their analytical problems to grasp the key points, realistically give practical and can "a sword to seal the throat" elegant solution ability, and then upgrade a bit of the realm, is to constantly upgrade their ability to innovate (that is, to create new things, put forward new ideas, Ability to solve new problems).

I personally think that spending a lot of time "mastering" a language, a platform and some tools is actually putting the cart before the horse. So, do not chase this "mastery", it seems educated player very good, in fact, Kong Yiji a just. Beijing Institute Lecturer, School of Computer Science,----------Jin Xu-liang

Do not know what counts as "real" proficient in Java. The main programming for many years, a few years ago also in FLAG work peer review top 10% level, so audacity self-proclaimed more skilled bar. Summarize your present state of being. (not limited to Java, now working with Java + Scala + TypeScript, private projects with Java + Kotlin, before C + + What also written a bunch, for most languages are common).

Still will check API, will go to Google/stackoverflow. The Java ecosystem is large, and if you use a third-party library, there are a lot of important points like spring and each edition is tuned. Memorize API is not to do, it is meaningless. You need to remember which main classes each library has, and what direction each class provides. Specific parameters, and performance details depend on the documentation.

Know how the JDK is basically implemented, can avoid the vast majority of Minrei. As for a glance at the byte Code, sorry can't do. Code tuning by Profiler, Pure manual tuning is not recommended.

It is not necessary to compile the bug again and again. The biggest role of the compiler is to check the gaps, by manual to a file to troubleshoot is not not, it is a waste of time. The general code-writing process is as follows:

Set the general direction and write the first draft.

Think write almost began to knock compile, by error to the last part of the compilation completed.

Compile over and run the test to see if there is any break existing feature.

Start writing new tests by completing the existing break. This is the main process of finding a bug, and it is much more efficient to find bugs by testing than by mental troubleshooting. Because you just write what kind of situation you expect from the output. There are unexpected results by debugger to find out where to think fork.

Writing tests will generally have new ideas for API design, relying on written tests to do one or two rounds of refactoring.

Write more than try to change, rely on the test to squeeze out the bug. When people are still struggling with how to design the perfect API How to write a bug, we have changed a few drafts to complete a bunch of dark thunder can be submitted.

The benefit of this process is that the test is complete, and what is written will not be easily break by others.

Will simplify the complex problem. Often there are new people to me spit groove, next door big god good cow, code beautiful like painting, all kinds of technology hanging fried days, but do not fully understand. Unlike your code, it seems like there is nothing special around you, just write it to work. Experienced programmers will know that the majority of colleagues in the project is the average level, if you have to write the cattle break code, many people can not understand, maintenance will be wrong. How to encapsulate complex logic, with a simple interface to hide the burning brain content, is the programmer to mature signs.

Knowing what open source options are available in the ECO system, unnecessary wheels are not built, and when created, they provide ample justification for why existing open source cannot be met and must be done on its own.

Not superstitious big open source/Big company project. Using a third-party library will go to the source code, see where to write well where the writing is not ideal. Even if the Java language itself has many design flaws (criticism of Java), refer to others ' lessons, recognize the shortcomings of existing tools, and avoid the same mistakes in your own design.

Agree with Clevelandalto, understand the pros and cons of the language, choose the right tool. Don't use Java when it's not suitable for Java.

Welcome to join the Learning Exchange Group 569772982, we learn to communicate together.

What is the realm of true mastery of Java?