Original: WeChat public account [Ah Q said code], welcome to share, please keep the source for reprinting.
I wrote an article called "After reading the code written by my colleagues, I started to imitate it silently. . . 》 The article, I accidentally read the background data today, and I was surprised. The reading volume of this article has reached an astonishing 5W+ in the WeChat official account . For me, who has never seen the market, I am quite satisfied.
Of course, the achievement of such data is inseparable from the attention of the big guys, and I would like to thank you again.
So I went to other platforms to look at the data with a curious attitude, and it felt good. After a rough calculation, the entire network has reached 10W+ ——There should be applause here, and applause for myself.
If there are still big guys who want to reprint this article later, you can contact me as soon as possible, thank you.
reading experience
What's interesting is that everyone has had a heated discussion on "reading colleagues' code". Let's experience it with two pictures.
For me, there are also some experiences and sentiments, which I would like to share with you.
fledgling
"Everyone here is rubbish, and the clown is myself" - this is how I read my colleagues' code when I first started working.
As a junior programmer, I just started working, and I only have simple programming knowledge, and I don’t know anything about design principles, design patterns, code specifications, etc., but I am "blindly confident", thinking that programming is just that.
When reading the code written by a colleague, due to my limited vision, I think it is too cumbersome, obscure, and suspected of pretending to be X, and I always think about whether I can optimize it for him. Don't say that there are really cases of "bold" colleagues optimizing codes for old employees. Fortunately, they were tested during the testing phase Bug, or they would regret it after going online.
It is recommended not to modify other people's code easily. The "chaos" of the code is not achieved overnight. It is left over after multiple version iterations or changes in requirements, and it can withstand scrutiny. If you must refactor code, it is recommended to let the coder do it himself.
After wasting all my efforts to understand my colleague's code, I suddenly felt that my colleague was really awesome. How did he come up with such an ingenious way to implement this function? The admiration is beyond words. Wouldn't it be a great achievement to learn from him for a few years.
take it easy
"Advance, attack, retreat, and defense"-this is my feeling about the second stage of reading my colleagues' code.
After working for a few years, I have a better understanding of code writing and work processes, and I have more feelings about reading other people's code. As the saying goes, "A loss is a blessing", and it's the same at work. If you don't step on the pitfalls in the project yourself, you will never know the "sinister society".
BugAfter reading other people's code or even modifying other people's code, the youthful impulsiveness and anger towards junk code have also been smoothed out by urgent projects and inexplicable things. There is less green passion and more mature calmness.
Why is it summed up as "advance, attack, retreat, and defense"? It is because after the precipitation of work, I have a basic understanding of the previous design principles, design patterns, etc., and when I encounter garbage code, I always want to show my skills, make some "contributions" to the project, and reconstruct the garbage code. Turn over, so it is called "in".
When we wanted to make drastic improvements to the project, we found that the shortcomings of the project were deeply rooted, and it was not easy to transform. However, as the construction period approached, we had to compromise with time. Use the version control tool to roll back the code silently, and continue to add "garbage" to the garbage code, which I call "retirement".
When the project goes online Bug, there is a meaningful sentence: garbage code still has the benefits of garbage code. When the project refactoring requirements discussion meeting is held next time, I will say silently in my heart: why don't you kill me!
battle-tested
"Wideness and strength, not over-design"-this is how I feel when I read my colleagues' code now.
It doesn't mean how good my technology is or how high my level is. The main reason is that I am rooted in the front line of "moving bricks". After working for a long time, I read more codes.
From the perspective of colleagues or friends around me, their personal technical capabilities are relatively strong, and their proficiency in business and architecture is relatively good. They are well aware of various design rules and code specifications, but they are not obsessed with them. The problems that can be easily solved are briefly mentioned, and the design specifications that should be paid attention to can also be easily mastered.
When talking with friends, they mentioned the problem of reading code, and they said without hesitation: There will be junk code in every project, and of course there is no lack of good design. For garbage code, it can be moderately refactored without affecting the overall situation. Of course, the cost of complete refactoring for important links is too high, and the cost of trial and error is a bit high. As for the exquisite code, I usually study it when I encounter it, and learn from design ideas to code writing with an open mind. After all, no one is perfect, especially the code.
To be lenient and fierce is to do it: be strict with yourself, minimize the output and addition of garbage code, and try to make the design standard and reasonable; treat others with a tolerant attitude, and every Individuals have different styles and different understandings of the same business, so the implementation methods are naturally different.
Of course, if you want to go to the next level, you need to combine the company's cost with software development, moderate design, and moderate reconstruction. After all, profitability is the ultimate goal of the company.
how to read
As for how to read other people's code, I will also talk about my thoughts, and I will share my thoughts here, and see you in the comment area.
Excellent comments can get a technical book at the end of the article.
Before reading the code, you can check the project prototype, planning process, "Design Document", etc. If the company's development needs are urgent or you don't have the habit of writing documents, ask a development colleague to understand the development logic process or find a product colleague to understand the requirements of the project It is also a good choice.
You must first understand the requirements and project process, which is the soul of the code.
We can also "chat" with our colleagues to learn about his implementation plan, implementation method, key technologies, etc., and when we look at the source code, we can be clear and targeted.
If you dig deep into the code, experienced "old people" can understand the hierarchical structure of the code, but "young people" who lack experience, especially those who are unclear about the framework or structure, will be at a loss, even if they will eventually If you understand the code, it may also get twice the result with half the effort.
When reading the code, you can first smooth out the overall logic according to the flow chart, and then go in-depth study of the function and implementation of each function. In the process of research, you can develop the habit of drawing flowcharts or mind mapsSpring casually, just like reading or Mybatiswaiting for clear-coded source code , so that you can see it at a glance when you read it next time. After all, a good memory is not as good as a bad pen.
If you are not good at drawing, of course you can draw a sketch in a notebook, don't stick to the form.
If you are still not good at it, then check out the code from the local branch, annotate, mark, and write questions on the local branch, do your best to "persecute" the local code, do whatever you want until it is easy for you to understand, don't be polite.
Of course, the understanding of the code can also Debugbe carried out in the mode, and the real knowledge comes from practice. It is better to run while watching it ten times, let the program move, your thoughts will fly, become more active, and it will be easier to understand.
The above is my simple point of view, please leave your point of view in the comment area!
summary
Whether it is the degree of suffering from reading other people's code, or how to read to improve efficiency, both reflect the impact of code readability on development efficiency, so we must write comments, write Comment, write comments!
Good comments can not only show the process clearly, but also write out the "pitfalls" that exist when solving problems, so that the latter can avoid detours. After all, the predecessors dug the pit, and the descendants will not care about the burial!
Ah Q will continue to update articles on java combat. If you are interested, you can pay attention to it, and you can also come to the technical group to discuss problems!