Shotgun Programming
This style of programming is one where developers treat code in a very casual way. "Well, this method call went wrong...then I'll try to change the outgoing parameter from false to true!", of course still going wrong, so our programmer would be like: "Okay, then I'll comment out the whole method", or some other more arbitrary approach, until the call succeeds. Or be pointed out a correct way by some programmer next to you.
If we pair a regular programmer with a lucky programmer , the regular program can go crazy right away, and the regular programmer's IQ can be minimized. Two lucky programmers shouldn't be pair programming together because their destructive talents can do worse damage than just one.
luck programming
This is a gentler way of programming than shotgun programming, and I believe this is probably the way most programmers will use it. This style of programming often occurs when programmers don't know exactly what they're doing, and don't know the nature and reality of the program they're writing, but can get the program to work.
They write programs in a lucky way, and at some point, they don't even know the cause of a bug, and they start to change the code in confusion.
Once there is a problem, they will use two paths:
1) Stop, understand the program, and find the cause of the error.
2) Use the shotgun programmatically to start solving the problem.
Test Driven Development (Test Driven Development) is the kind of programmer that can be used to save millions of bad luck programming. So, they have a more NB excuse: as long as my program passes the test, what else do you have to say? Don't scold me, test-driven development is a good thing, and it is mainly used to control the problems caused by the development of luck.
Cargo-Cult Programming
About Cargo Cults The term comes from the indigenous people of certain Pacific islands during World War II. During the war, the United States used these small islands as depots on the Pacific battlefield. They built their own airstrips on these small islands to transport war supplies. And the indigenous people on those small islands have never seen an airplane. When they saw an airplane, they felt that they were quite cows, and they could bring all kinds of items and food to those white people. When World War II ended, those indigenous people modeled the airstrips and built the towers out of bamboo. And just there expecting a plane to bring them items and food.
Cargo Cult programming is a very popular programming method, programmers who use this method will learn the programming method of other programming masters, although they do not know why the masters do it, but they think it will make the program work. . For example, there were a large number of programmers who overused EJBs and Entity Beans in the first year of J2EE.
Carving a boat for sword programming
Carving a boat and seeking a sword is a very popular fable. This style of programming is very common in programmer circles. For example, one day, you found a null pointer exception, so you went to the place where the null pointer exception occurred, and simply put a judgment: if (p != NULL).
Yes, such a fix can make your program work, but you don't really solve the problem. You're just taking note of where the sword fell by the side of your boat, and doing so just hides the problem, and in the end it just makes your program behave in a weird way. You should find out why the pointer is null and then fix that.
Design Pattern-Driven Programming
As the name of this programming says, this style of programming uses a lot of design patterns. In your program, there are design patterns all over the place, and your code is full of Facade, Observer, Strategy, Adapter, etc. . As a result, the business logic to be processed by your program is disrupted by these design patterns and cannot be read. In the end, you don't know whether the business requirements are repeated or the design patterns are important. In short, the program logic of the actual business requirements is disrupted by various design patterns. Unsightly.
detective programming
When solving a bug, the detective programmer investigates the cause of the bug. Then, investigate the cause of the cause of this bug. Then, it analyzes the causal relationship between fixing the code and causing other code to fail. Then, he will use a text search to find all the code that uses this change, and continue to find the calling code one level higher. In the end, the programmer would write test cases for 30 different situations, even if the test cases had nothing to do with the bug, and in the end, the programmer had enough confidence to fix exactly one typo.
At the same time, another normal program fixes the other 5 bugs.
butchery programming
