Change the demand as soon as the test is raised. Am I a scumbag?

Author: Xiao Fu Ge
Blog: https://bugstack.cn
Series: https://mp.weixin.qq.com/s/PhR8HvGC49d0cerYxGJ3_g

Precipitate, share, grow, so that you and others can gain something! 😄

R&D hates me!

Brother Fu, I just came to the company's product, that is, I still know a little bit of technology, because I used to study software engineering, but I don't like to write code, so I want to make a product and direct others to write code. coveted idea is finally realized

I finally got into R&D through the king assist, snack feeding, and introduction of people, but recently they hated me a little bit. Because I received a request from a business boss who is anxious to go online, but because the pace of going online is too anxious, most of the time from BRP review to PRD output has been taken up, and the schedule for R&D and testing can only be reversed, and this during also always make minor changes in demand, research and development, said his code has become feces mountain, and I like that mix feces stick, adjacent to the test again a thick stick !

Then, I don’t want to be a stick again. I want to know what makes the yard brick brother big, I will try my best to bypass it in the future. I am a good product with a conscience!

---

The above is a fabricated paragraph, but I just need to read the ID card. Basically, as long as you write code for research and development, you will encounter a variety of products, but not all products understand how to write code for research and development, and you will encounter so many The problem, so I want to talk about those pitted roads in conjunction with this paragraph, and how our R&D is going.

The pits I stepped on in those years

1. New code, hurry up

When a new requirement is too late for R&D thinking, design, and review, and the reserved online time is stuck, it can only be a way of stacking people how to write functions quickly, there will be no documents, no comments, and no Single test, especially at this stage when there are many unidentified functions of the product repeatedly modified, it will even mess up the implementation of the code.

Maybe the product, the business, and even the boss who raised this requirement can't figure it out. Is it just writing code? Is it so difficult to modify? Yes, it’s like you gave a pile of picked up bricks, buckled sand, and hand-drawn drawings. The need is to build a toilet. Now that the pit in the toilet is dug, it’s a shelf. We can’t change it. We don’t want it. The toilet is out, and I need a pigsty. It seems that pigs have to poop, and the pits dug are enough. Modifications and changes, expansion and expansion of the area, the pigsty seems to work, but this time has buried a lot of hidden dangers, when the pig enters the field, I will give it to you. The arch collapsed, but just when the plaster-style patching pigsty was about to install the water pipe, the product conveyed the latest intention of the boss. Now we have decided to live in this venue, and we have to change the UI interface and give it a luxurious decoration. knows how to build a house and dig the foundation, but when it comes to writing code, it seems that they don’t understand

For example, how does the code die?

• There is no plan for the demand, and you can add what you want, and if you add it, you will have an accident. This is also the scene that most R&D faces every day.
• From the proposal of a requirement to R&D, testing and verification, and online deployment, these processes require a reasonable evaluation time to execute, otherwise there will be no experience product as good as Apple's IOS.

2. Handover, Duo Shi Shan

Do you think that the projects you develop start from scratch? In fact, it is not. In particular, Internet companies often quickly adjust to market changes, which may also cause the code you to take over may be written by others, or even by many individuals accumulatively. The code you wrote before, like a baby, will also be piled up into a mountain of shit by others.

What is the vo2dto code? There are also more than 12 ways to write json2object There are also N ways to generate a number ID. So nowadays, if anyone takes over other people’s code, they can’t find documentation or comments at all. The method names are in random English and Pinyin. It is common to write queryBatch as queryBitch. So, with so many different kinds of code with multiple implementations of the same function, how can iterate requirements in it faster? I don’t know what I am going to change, but I dare not delete

The product may not be understood again. Isn’t it enough to delete it? Will it be difficult? Yes, what do you think about it. For example, your house is a three-bedroom house, with a bathroom, a kitchen, a living room, and a bedroom. The first guest still pays attention to installing a toilet, buying a sofa, and installing a bed in the bedroom. , Was later handed over to the agent for rent. The agent said it was not a waste. The kitchen was so big and there was nothing installed. I dismantled and disassembled a bed, installed a toilet, separate bathroom, and rented one more room. The living room also gave it a partition, connected to the upper and lower water pipes, and also gave it a separate bathroom. The master bedroom and the second bedroom are equipped with separate bathrooms. Ok, then the house was handed over to you, and you rented it as a whole, and found that there were toilets everywhere in the house. Whenever they were torn down, they started to spray water. I don’t know how their water pipes were connected, and they were repaired by a master. In terms of cost, it is better to dismantle and redecorate. n't look like it, the code can't be refactored at all, it can only be rewritten!

3. Reusable, not fit

You can’t reinvent the wheel. Why don’t you use the existing ones? What are the innovations of your own writing? Why don’t you find a certain department to investigate. Are you technically self-satisfied? You’re still scared after hearing this. It’s not scary. It’s clear that you might be writing the project better, faster, and proficiently. But now, in order to make a project, you need to go through all the departments to investigate what components they have to support. Your needs will begin to require documentation, docking, and joint debugging. Okay, your needs may not have been great. Now it will take two weeks to meet what you even did in three days. increase the workload, and the year-end bonus is yours again!

In general, when reporting, defending, and reporting, everyone packs what they do in very leather. Even as long as you use this component, the company will be able to market for three years in the morning. But once the report is finished, when you go to ask you whether this thing can be docked, when it's over, this piece is not supported, and that piece cannot be done. Why? Because the design of a demand function is often biased towards its own business requirements, rather than a unified standard solution, it cannot solve the individual requirements of other business departments, and even in order to support a small part of the function, it must be sorted out from beginning to end. Development, adding tables, adding fields, writing classes, writing methods, and writing single tests are not so easy to support. Poor support may bring a very heavy burden to your own system.

The product may not be understood again. Doesn’t it reduce development by reusing it? This is like, an old man, the eldest wife and a few concubines in the family, the eldest wife is usually a judge and divides the cakes. The elder aunt likes to express herself, walks close to the eldest wife, and gives him and the eldest wife if there is nothing wrong. Reporting the results of the recent work, the auntie had no results when she entered the door, and told the master that she wanted to be a pantsuit. The master said that the auntie last time reported that she did not have pants, did you waste the time and do it again? Just wear it in one go. The auntie found the auntie and asked if the pants could be borrowed and worn. The auntie said it was a bit difficult. My pants are too small, and you can’t fit your figure. I want to change it to your size. You can mention it. It’s neck, look at it, or let’s talk to the master, you just said that your pants are more customized, and you have to have some special features, such as skirts for unfolding, pants for folding, pants for summer, and cotton trousers for winter. This will give you approval and you will be innovative.

Climbing up is the past

1. Improve one's own abilities

After working for so long, I deeply feel that even very technical projects can be written using CRUD+ ifelse in front of the R&D without much experience. What is the PRD process of the product? In the code What’s the trend of branch judgment, there will be no model abstraction and some common refinement. Writing code in this way can only make the code rotten. It has nothing to do with the product, has nothing to do with the scheduling, only with Your own technical ability is related to the project experience, maybe just because you wrote it.

After experiencing this, I will compare each new feature with the last time, reuse those better implementations, and optimize the implementations that are not so good, so as to settle out a little bit of my own technical implementation. Accumulation of experience in the process. Slowly I have a certain conditioned reflex, knowing that those projects will stimulate me to create better designs, and those projects can reuse my previous logic, so that the requirements can be completed quickly and with high quality, and the product can be satisfied. Iteration of functions. grows, it is one's own gain

2. Compliance with norms and standards

In fact, you need to know that humans are not machines with stable output. As long as humans are writing code, there will be irregularities, lack of processes, and abnormalities. Therefore, these need to have a set standard, and everyone will implement it in a unified manner. In this way, even when there is a problem, you can quickly locate and deal with it. Otherwise, if you develop in one way and code in another standard, a team will eventually have to maintain two sets of content, which is labor intensive and problems may occur.

Especially when the project we develop is not a small workshop, it is especially important from the market BD, business operation proposes BRD, product review PRD, architecture design, R&D details, code review, completion test, and online control. Delivery needs to be verified, and every link needs to have implementation standards. If the entire group, the entire department, and the entire company have standard process specifications, there will not be so many even when handing over code, coordinating resources, and joint development. Obstacles are blocking our deep friendship.

3. Multi-communication between production, research and testing

We cannot guarantee that the product will not change the demand, even when it is about to go online, because of the market, because of risk control, because of the process, because of finances, etc., may not even be some special reasons that R&D knows about. It is impossible to change your demand to get you online. The R&D may ask why it can’t be brought up early. It’s because these special situations are caused by uncertainty, just like the code we are running. No one knows that it’s because of the network, IO, load, and stardom. Propaganda traffic has soared, which has caused problems.

In order to better meet product requirements, the best way is to communicate and communicate more, especially in the early stage of product requirements design. Check their PRD documents in advance. There may be a lot of services you can provide, and some of them are products. After hesitating which way to implement the function, after discussing with you, decide to reuse the system you already have. So communication can really bring you great benefits for later development, and reduce the emergence of many unnecessary things!

---

• Business, don’t do scum
• Products, don’t do research and development scum
• R&D, don’t test the scum man
• Test, do not do business

Do one thing, do one thing well, we are not the next scumbag, and we are also responsible for our own growth!