CSDN "A certain programmer has eaten shit? We walk into his life and reveal the story behind it
————————— Next let’s go into his story and what exactly makes him eat shit
This is the confession of this programmer. I am curious not that he has eaten shit, I am wondering what it tastes like~
Next, we will start to consult this ordinary programmer, what caused him to do this kind of thing behavior?
I believe that many smart programmers already know why they eat shit~
That's right, ™'s mountain of code shit!!!
It is said that a netizen has experienced a "shit mountain" and joined a software company that has been established for 10 years. The netizen applied for an intermediate programmer at the time, but after a few months of entry, he magically adjusted to a senior programmer. This is not Because his skill level has improved by leaps and bounds in a few months, but because the following things have happened in these three months:
- The former team member No. 1 and I ran away after finishing the handover!
- The former team leader and the newly recruited team leader ran away after handing over!
- The former team member No. 2 and the newly recruited junior programmer ran away after handing over!
- The new team leader ran away after handing over to me!
- After the new team member (female) covered her face and cried bitterly at the workstation, the team changed! (The kind of crying that covers her face and tears without making a sound)
- There is a serious shortage of staff in the group. I solve production bugs during the day and write new requirements at night!
The above is just the tip of the "shit mountain", the "shit" is because there are many problems in the ancestral code and it really stinks, and the "shan" is because there is too much shit. The most ironic thing is that in order to manage the "shit mountain", you may have also pulled "shit" a few times in it...
Sometimes I change things on a whim... The code is wrong from beginning to end... //Don't move, I tried it
Sometimes when you delete only one line of code, the following may happen
You never know that adult meltdowns are often just a split second! ! ! !
Some people will say that I just moved a little bit, why did I overturn the car, often a little thought of my own may become the last straw that breaks the camel's back.
For the ancestral code, I summarize my life insights, which are four big characters:
hit stone with egg
Advice as someone who has been through ancestral code a few times.
Rule 1: Never try to refactor.
I'm sure everyone has heard this sentence. Ten years of programmer blood and tears, don't refactor the code!
Don't take the road of refactoring too easy, because refactoring can be unexpectedly simple or unexpectedly complex
Why not rebuild Shishan?
Younger programmers often have the urge to refactor mountains of shit, and this willingness to write code well is excellent. But refactoring isn't just about removing bad code and writing it again. If you don't think carefully before refactoring, the code you write over again is not necessarily better than a mountain of shit. Refactor or not
Article 2: Code reduction ancestral code There are many useless codes, all of which are the pits left by the predecessors when they walked the road to immortality
You can delete them all, and sometimes it can optimize the ancestral code. This is the most simple and direct optimization method. Simple and direct violence may improve the compilation speed of later code.
Article 3: Keep patching and fix bugs if there are bugs
As a programmer, you should be thankful for the shit mountain of code, and the engineering nature of the shit mountain of code that big companies must have.
If code engineering is the same as building bridges, it can be intensified and scaled with tools.
Guaranteed accuracy with the instrument, so that quality and quantity... stitch and mend for another year. If you don't want to work hard to introvert, then you can live in the company for a long time.
Item 4: Modify some SQL statements and optimize SQL if the SQL query is slow
In fact, this is easy to handle. Start slow query, find the slow query place, and do subtraction. If it is a query of multi-join tables, perform data redundancy and reduce the query volume. Check the index (since it is a mountain of ancestry, I don't believe that the database index will be built perfectly), and rewrite the SQL statement. This kind of reform is very practical and solves the slow problem from the source. For example, if you have 100 SQL queries in the ancestral code of a page, you optimize it to 50 sentences. Can the speed go up? Much easier than changing the code. Or if you add an index, it used to take 20 seconds for a SQL query, but now it takes 5 seconds. It’s really a trade that you don’t want to invest in.
Article 5: Article 5 is to improve from the inside, or to improve from the outside.
What if you could avoid being a mountain of code shit?
The mountain of shit is piled up little by little. It is especially easy for companies without code review. Not to mention this elimination plan, newcomers should not leave such code anyway, write their own comments, leave it and submit it to the collaboration platform, not so Jin Gui, bring it up and wait for your teammates to watch?
So there is no way to avoid it, and there will always be times when you need to refactor your code. Just try to write as well as you can, and write good tests so that refactoring the code isn't particularly painful. Be sure to write notes and the like, a good habit will save many poor people. For example, I am already on the verge of running away.
Even if you feel like you're a god when you write code and you can't go wrong, after a few months you'll still feel like shit when you look at it.
I've always wanted to write a project with a clear logic and no redundant code.
Day 1: The product manager gave me the project, and then said that it will be launched in a month. Generally, hehe, trivial
Day 2 : The product said it needs a small change, um, no problem, trivial
Day 3 : The product said, to add a function, um, sister problem, trivial
Day 4 : The product said that this function needs to be changed in this way, eh?
It's a bit difficult, but it can still be changed. The product does not say that it will be delayed.
Day 5 : Here, here, and here, all need to be changed. When I look at the code, I have a headache, but I still start to change it. …
The 20th day : The product told me that Party A felt that it was not planned well at the beginning and needed to change a lot of things. I: Yes, can the launch be delayed for a while? Product: This is impossible, although I am very unwilling, but I still do things according to the meaning of the product, after all, the requirements of Party A's father.
Day 30 : The product came to be next to me. Without saying a word, I had finished thinking about it, and I had to change it again, or there was a new demand.
After five minutes, the product said: Brother, there are some changes in demand, let's have a small meeting? Me: Okay, have you made an appointment for the meeting room?
Product: Now that the computer, screen projection, and files are ready, go now? Then after a long time, I finally finished all kinds of needs. At this time, it is impossible not to write shit-like code. What time is the launch time? The project is not a project that has just started. This is how shit-like code comes out. I like to write code.
I'm here today, I still have half an hour to get off work, I can't fish, I have to get off work hard
If you like my article, you can give me a triple ~~~
Next, let's talk about the programmer I interviewed in the Force Project group, emmm
Let's add some mosaics~
Brother bit's blog homepage: https://blog.csdn.net/A757291228 (If you like it, you can pay attention to it)
