The sadness of a young programmer

Young programmer, this is not the first work experience. But his first project proved problematic. At that time, he believed that the function did not need to change. But he was wrong, so every functional change required complete reconstruction, resulting in rampant bugs and a huge waste of time. He even tried some benign methods like writing tests. But his tests require maintenance, time to write, and more time to be executed.

Like every young developer, his growth path is filled with the voices of experienced developers, "Premature optimization is the root of evil!", and "Write tests! Test! Test!". Maybe he was just refactoring a small practical method, but at this time an experienced developer came over and warned him seriously, "Didn't I tell you not to optimize prematurely?", or "What are you doing? Are you writing tests?"

But often, young developers just put things in one ear and out the other. Because they don't understand why premature optimization should be the root of evil, and why good tests should be written. From his limited past experience, he believed that the following technical indicators did not work over time (because they tended to change) and that writing tests was a waste of time.

“Why on earth do I need to rewrite the code every time? Why on earth do I need to refactor the code I write now? And why on earth do I have to spend so much time writing things that don’t work? Testing?" the young developer roared in his mind.

So, finally one day, the young developer started working on a new project. This time, he decided to ignore the warnings of experienced developers: He believed that every piece of code he wrote would be fast, configurable, powerful, and able to withstand every parameter change. After he racked his brains to get the core of the project, the young developer couldn't help but shuddered: "Haha, what I said about those 'old guys' was wrong!" As if victory was in sight, the young developer's eyes were filled with excitement. There was a glow of victory.

However, some time after the release...

Suddenly one day, the customer informed them that a bug was found in the program. The experienced developer looked at the bug, found the problem, and asked the young developer to fix the bug of his own making.

When the young developer heard that his code was disliked, the first feeling of the young developer was anger. But after looking at the project...he found that he couldn't understand the code he wrote! He couldn't understand the meaning of these codes at all! Oh my God, woe to you!

But there is no way, this is his problem, he can only bite the bullet, okay, finally fixed this bug - but a new bug appeared in a few days. bug——patch, bug——patch, exhausted.

The young developer was about to collapse, "Maybe I'm not suitable for this kind of job, otherwise why can't I write the code well?" Amidst all the voices questioning themselves, the young developer doubtfully said Opened projects for experienced developers. He was shocked! The code is so simple and easy to understand - there are comments and tests. This is completely different from the code he wrote. The most obvious difference is: there is no additional configuration, every line of code is tested, every method has a meaningful name, and the method is very short (the longest one only has dozens of lines of code), the code only does Do what the customer asked for.

At that moment, the young developer was very frustrated, but the experienced developer came and he walked to the young developer's side. As he walked, he was actually starting to think about how to refactor these errors. code.

During the time of working together to solve problems, young developers witnessed the step-by-step process of experienced developers solving problems; sometimes experienced developers would also supervise young developers writing code.

A few days later, another release marks that the bug has been fixed. The piece of code that caused the bug has now been tested and is both easy to read and very stable. The experienced developer looked at the young developer and asked, "You should understand now, right?"

The young developer nodded. Now he does understand. The key to perfection is not to be able to predict the future, but to write code that is easy to change and tested (so that if you change the code, you don't create bugs), and only needs to meet current needs. And when he realized this, he had transformed into an "almost" experienced developer.

“Are we going to refactor the entire project now?” the young developer asked.

"Of course not! There is no budget for this." The experienced developer answered firmly.

“But what if other bugs appear?” asked the young developer.

“Freelancers can be used to solve those problems.” Replied an experienced developer.

Then, "almost" experienced developers start to be able to write good code, gradually approaching a higher level. Of course, that's another story.

Advice for young developers: Please go back and look at the code you once wrote. If your code now does not look as beautiful as before, then it means you are making progress.

Advice for experienced developers: When a young developer appears next to you, you may need to clean up their mess from time to time. If you want to get out of this situation, teach them to write decent code as quickly as possible.

Advice for freelancers: You should probably increase your remuneration

Get freeLAMPBand of BrothersOriginalPHPVideo tutorialCD/《 Talking about PHP》Essential Edition, please contact the official website customer service for details: http://www.lampbrother.net

PHPCMSSecondary developmenthttp://yun.itxdl.cn/ online/phpcms/index.php?u=5

WeChat development                                                          http://yun.itxdl.cn/online/server/index.php?u=5

JavascriptCourse

http://yun.itxdl.cn/online/js/index.php? u=5CTOTraining Camp

http://yun.itxdl.cn/online/cto/index.php?u=5 The above has introduced the sadness of young programmers, including aspects of it. I hope it will be helpful to friends who are interested in PHP tutorials.