Aiti Tribe Stories (18): The Love Between Programmers and Code

[51CTO.com original article] "Friend, can you also repair computers?" This is the sentence Xiao Shi has heard most often from his friends. Whenever he heard this sentence, he felt helpless. Do programmers have to be able to repair computers? But there is no way. In the eyes of his friends, programming is a very advanced job. Maybe something will go wrong with just a move of your fingers. Life is very exciting. Well, I have watched too many movies. As a programmer who can't repair computers but tries hard to learn how to repair computers, in addition to the skills of repairing computers, he must also have the characteristics shared by most other programmers. For example: staying at home and being bored. He may also have unique characteristics, like liking to go shopping with his wife...

[[193566]]

A brief history of Java development

Let me give you a brief and serious introduction to the protagonist of this issue, Xiao Shi, who has been engaged in Java backend development for more than three years and currently serves as a resident developer for a startup company. During this period, he has experienced development in fields such as Kafka and big data. As a programmer, everyone should be fighting a life-and-death struggle with 26 letters every day, and should have their own unique insights into programming. Taking this opportunity, Xiao Shi will throw a brick and talk to you about some things about code.

1. Say NO to copy/paste

Xiao Shi read an article titled "Programmers' progress starts with writing less code every day" which mentioned that with the help of Google and the Internet, you can write line after line of code. This sentence reminded Xiao Shi of a sentence that the test supervisor said to him during his internship and job interview in college: "Writing code is not difficult, it's just copying and pasting." When he heard this, his mind couldn't help but recall what his classmates said to him: "All I do in the company now is copying and pasting all day." At that time, Xiao Shi inadvertently had a question: Is the work of a programmer so simple and boring? With this question, he stepped into the army of program development.

On the first day of Xiao Shi's work, his leader repeatedly emphasized one sentence: "Don't copy and paste when writing code." He didn't quite understand the meaning of this sentence when he just started working. At that time, he was only concerned about work efficiency and completing the work quickly to let his leader know his ability. This led to poor naming and structure of the function code, and later rework wasted more time. Now he looks back and thinks about how naive his behavior was at that time. If he just copied and pasted without trying to understand the operating mechanism behind it, it would at best represent the completion of the work.

2. The pursuit of programmers - high-quality code

"Your code is like a pile of shit." I believe everyone has heard this sentence more or less in their daily work. I once saw a post on the Internet that said: "I believe many people think their code is the best, and other people's code is terrible because they can't understand it." After all, programmers have an engineer's heart, so when they arrive at a new site, the first thing they want to do is to tear down everything from the old and start over. Yes, they will never be satisfied with simple incremental labor. Perhaps this subtle psychological positioning can explain why programmers would rather throw away the old code and rewrite it after joining a new project team than to tinker with it. They think the old code is simply a mess.

Good code is like a good joke, which is easy to understand without explanation; bad code is like ancient Chinese, which may not be easy to understand even if it is full of annotations; good code is like a book written by someone with superb writing skills, which is easy to understand and has clear chapters; bad code is like a book written by someone who has just learned to write, which is confusing, complicated, and self-defeating.

So, how do you write a good piece of code? I once read an article that I thought explained it very well. It said:

• Readability - The code you write should not only be understandable to you, but also to the developers working with you in the shortest possible time. (This is especially important)
• Maintainability - Make your code easy to modify.
• Simplicity — Don’t make your code look unnecessarily complex.
• Efficiency - Make your code run as fast as possible.
• Clarity - The names of class commands and methods should clearly express the meaning of specific actions.

3. Code optimization is necessary

Code optimization is a very important topic. Some people may think it is useless. What is the point of modifying some small details? What impact will the modification have on the running efficiency of the code? Xiao Shi has a deep understanding of this issue. For example, he wrote a function that used redis sorting before. Based on the principle of not reinventing the wheel, he resolutely used the sorting method provided by redis. After writing it, he was quite happy and learned more about redis. However, things did not go as he wished. When the code was put into the production environment and ran, the results directly confused him. Under the baptism of large-scale data, it could not run at all. That night, Xiao Shi typed the log line by line, analyzed the reasons for the slowness, and finally located it on the sorting of redis (the specific code details are not explained), and then wrote an algorithm to replace the redis sorting.

Regarding code optimization, Xiao Shi made a lot of notes, such as:

1. Try to specify the final modifier of the class. Classes with the final modifier cannot be derived.

2. Try to reuse objects as much as possible. In particular, when using String objects, use StringBuffer instead when string concatenation occurs.

3. Try to use local variables. The parameters passed when calling a method and the temporary variables created during the call are stored in the stack, which is faster. Other variables, such as static variables and instance variables, are created in the heap, which is slower. In addition, depending on the specific compiler/JVM, local variables may be further optimized.

4. In the development of Java + ORACLE application systems, SQL statements embedded in Java should be written in uppercase as much as possible to reduce the parsing burden of the ORACLE parser.

5. Try to minimize repeated calculations of variables. For example: for(int i = 0; i < list.size; i ++) {
…
}
Should be replaced with:
for(int i = 0,int len ​​= list.size();i < len; i ++) {
…
}

6. Try to adopt the lazy loading strategy, that is, start creating only when needed.
For example: String str = "aaa";
if(i == 1) {
list.add(str);
}
Should be replaced with:
if(i == 1) {
String str = "aaa";
list.add(str);
}

etc……

4. Books are important

Web industry knowledge is updated very quickly. Today there is a new version of a framework, and tomorrow there is another new framework. Sometimes we often need to keep learning new things according to the needs of the project. Therefore, we might as well read a few more good books in our spare time. If you really don’t have time to read, I also recommend that you find some blogs written by experts who have read this book. Because these may be the essence of the whole book.

The above views are from the personal insights of Xiao Shi, a core developer of the 51CTO community. Welcome to join the group (group number 312724475) to communicate and learn together~

[51CTO original article, please indicate the original author and source as 51CTO.com when reprinting on partner sites]