The sadness of the young programmer

the young Programmer , this is not the first time work experience. But his first project proved to be problematic. At that time, he thought that the function did not need to change. But he was wrong, so every change in functionality needed to be reconstructed, causing Bug rampant and a huge waste of time. He even tried some benign methods, such as writing tests. But his tests require maintenance, writing time, and more time to be executed.

Like every young developer , his growth path is the voice of experienced developers, "premature optimization is the root of evil!" "and" Write the test! Test! Test! ”。 Maybe he was just refactoring a small, practical approach, but this time the seasoned developer came over and solemnly warned him, "Didn't you tell me you couldn't optimize it prematurely?" "or" Are you writing a test? ”。

But often, young developers go straight to the right ear on the left ear. Because they don't understand why premature optimization should be the root of evil, and why you should write good tests. Judging from his limited experience, he argues that the next technical indicators do not work long-term (because they tend to change) and that writing tests is a waste of time.

"Exactly why do I need to rewrite the code every time?" And why do I need to refactor now after the code I've written? And why is it that I have to spend so much time writing useless tests? "Young developers are roaring in their hearts.

So, finally, one day, the young developers started a new project. This time, he decided to ignore the warnings of seasoned developers: he believed that every piece of code he wrote would be fast, configurable, powerful, and able to withstand every change in parameter specifications. After he racked his brains to fix the project's core, the young developers could not help but get up: "Haha, I said that the old man's words are wrong!" "As if the triumph is in sight, the young developer has seen a triumph in the eyes."

However, after a period of release ...

Suddenly one day, customers told them the program found a bug. The experienced developer looked at the bugand found the problem and asked the young developer to fix the bughe had caused.

Listening to their own code is rejected, the first feeling of young developers is angry. But after watching the project ... But found that he could not understand the code he wrote! He is completely ignorant of the meaning of the code! Oh, my God, alas!

But there is no way, this is his problem, he can only bite the bullet, well, finally fixed the bug--but in a few days there are new bugs. Bugs-patches,bugs-patches, burn.

The young developer is simply going to crumble, "Maybe I'm not fit for this kind of work, or how can my code always write poorly?" "In the various questioning of their own voices, young developers are dubious about opening the projects of experienced developers. He was shocked! The code is so easy to understand-there are comments and tests. This is fundamentally different from the code he wrote. The obvious difference is that there is no additional configuration, every line of code is tested, each method has a meaningful name, and the method is very short (the longest is only dozens of lines of code), the code only do what the customer asked to do.

At that moment, the young developer was very frustrated, but the experienced developer came, and he went to the young developer's side and walked away as he was actually beginning to think about how to refactor the wrong code.

In the time of working together to solve problems, young developers have witnessed the process of solving problems by experienced developers, and sometimes experienced developers supervise young developers to write code.

A few days later, another release marks a bug that has been fixed. The part of the code that caused the bug has now been tested, not only easy to read, but also very stable. The experienced developer looked at the young developer and asked, "Do you understand now?" ”

The young developer nodded. Now he does understand. To be perfect, the key is not to be able to predict the future, but to write code that is easily changed and tested (so that if you want to change the code, it doesn't cause bugs) and only needs to meet the current requirements. And when he realizes this, he is invisible, and has morphed into a "almost" seasoned developer.

"Are we going to refactor the whole project now?" "asked the young developer.

"Of course not!" It's not a budget. "The experienced developer answered categorically.

"But what if there are other bugs ?" "asked the young developer.

"It's possible for freelancers to solve those problems. "The experienced developer replied.

Then, "almost" experienced developers began to write good code, gradually approaching a higher level. Of course, this is another story.

Suggestions for young developers: go back and look at the code you've written, and if your code doesn't look as beautiful as it once was, you're making progress.

Advice for experienced developers: when you have a young developer around you, maybe you need to clean up the mess for them from now on. If you want to get out of this situation, then let them learn to write decent code as soon as possible.

For freelance advice: You might want to raise your pay.

Free pick up the LAMP Brothers and original php video tutorial CD /" php" Essentials Edition, details of the Advisory website customer Service:http:/ /www.lampbrother.net

Phpcms Two-time development http://yun.itxdl.cn/online/phpcms/index.php?u=5

Development http://yun.itxdl.cn/online/weixin/index.php?u=5

Mobile Internet server-side development http://yun.itxdl.cn/online/server/index.php?u=5

Javascript Courses http://yun.itxdl.cn/online/js/index.php?u=5

CTO Training Camp http://yun.itxdl.cn/online/cto/index.php?u=5

The above describes the sadness of young programmers, including aspects of the content, I hope that the PHP tutorial interested in a friend helpful.

