Be careful to avoid these seven programming misunderstandings!

We rarely see people talk openly about their mistakes.

People can not escape from doing wrong? It’s hard to say, but reflecting on past mistakes can prevent you from making the same mistakes in the future—at least in the short term.

Mohamed Barouma is a professional programmer of 5 years, but like anyone, he makes mistakes.

He said: "Normally, I don't realize what I did wrong right away; I only know what mistakes I made after being exposed to the correct way of doing things."

Combined with his original text, this article summarizes the seven major misunderstandings he made.

1. Not using a proper ORM

Data access layer code is always confusing, boring and boring. Unfortunately, this is often not discovered until the end.

Mohamed and ORM have a bad relationship. ORM, Object Relational Mapping, is the abbreviation of Object Relational Model. Its function is to make a mapping between the relational database and the object, so that the program can manipulate the database by manipulating the description object.

When Mohamed first made a simple internal accounting application, he found that just to complete the basic program, he had to write a lot of code. So he began to immerse himself in ADO.NET and manually wrote a homemade ORM with a very special and customized table schema to meet the purpose.

For a period of time, this ORM worked quite well. Until a few months later, the company's business needs changed, which led to changes in the entire table schema. Then, there were repeated modifications to the ORM. . This process was so painful that Mohamed finally chose the strongly typed dataset adapter.

Although this matter has been resolved, if a more suitable ORM (such as NHibernate) can be found to complete the work, Mohamed will still be obliged to do so. At least when the number of his users increases, he does not have to worry about changing the database supply. business.

2. Didn’t learn to use generics

Mohamed Barouma’s career as a professional programmer began with Net 1.1. At the time, the main problem with Net 1.1 was that it had no generics support, which meant it couldn't have a strongly typed list and had to settle for a boring ArrayList. However, using Arraylist to perform type conversion and boxing in Java code will make reading and writing very painful.

Therefore, Net 1.1 programmers used CodeSmith to generate a strongly typed collection list.

But as the code base grew, those custom-generated lists themselves became an unmanageable monster. As long as you often create objects or call methods to achieve your goals, you will later modify the code to cause confusion and errors.

If you switch to Net 2.0 and start using generics as soon as they are available, instead of creating more and more custom collection lists that are difficult to maintain, everything will be solved.

3. Never give up "reinventing the wheel"

This is a commonplace topic, "reinvent the wheel" (Reinvent The Wheel). New programmers always like to "reinvent the wheel" over and over again, thinking that the current implementation is not good enough, so they have to rewrite the whole thing from scratch.

Why is it called "making wheels"? Just like the real wheel was determined to be round thousands of years ago, many databases have long been mature and easy to use, but there are still countless programmers who persevere in "making wheels", and some A moth flies into a flame, a worm flies into a tree, but some people are unique and innovative. This is the magical attraction of "making a wheel".

Among them is Mohamed, who wants to rewrite his own UI controls because Windows Forms UI controls are too simple. In the end, the GUI tool he created was easily defeated by the commercialized .Net UI control system, and another "wheel" created by a new programmer was sunk into the ocean of code.

4. Not too streamlined documentation

Many programmers who have just entered the industry will find the code documentation very good at first because it uses simple English comments What the code is doing. But in fact, these documents usually become a piece of waste paper after a few code changes, becoming stale, outdated, or just plain wrong.

Often people spend a lot of time writing code documentation - such as XML documents, only to find that they need to update the documentation when the code is changed. Because its functions may have changed. Updating the code is necessary, but updating the XML document is not: it is a burden, it consumes time, and it is useless.

Eventually, changing the XML document repeatedly makes people gradually lose patience and move on to other things.

5. Not using automated builds

Deployment and packaging of applications is relatively easier than programming, so it is often placed at a very low priority. But soon, the shoddy build will be unable to work, and will be subject to various complaints:

"Prerequisites are missing, how to fix it?"

"The dll is not updated, what can you do? Can you give me a patch?"

"Why is my icon missing?"

Immediately afterwards, calls came to the table like an avalanche. This was a real experience for Mohamed, and it left him exhausted that day—not from the programming, but from the mind-numbing process of redeployment and repackaging.

In all of this, some time could have been saved by writing automated scripts, otherwise the time wasted on debugging afterwards would definitely be several times more than the time that can be saved. Software should be built with one click, otherwise it is a waste.

6. No stopping relying on visual inspection and debugging

Visual Studio makes it easy to debug code and conduct dynamic inspections, which also makes it possible to create a form And displaying the output is very simple. But if you get too addicted to the debugger, this benefit will turn into a disadvantage.

why? Imagine if a method is only called 45 minutes after the application is up and running. Do you plan to wait 45 minutes before starting debugging?

So, break down the application into components that can be called independently. submodule so that you can prepare the input value that produces the error output and start testing it from there.

7. No unit testing

Many programmers may have thought: "My application is trivial and it can be easily covered by manual testing." ;Unit testing is for large and complex things, not for my program."

As you can imagine, this will directly create a code that has no separation of concerns, is difficult to refactor, and is completely unmaintainable. library.

"Creepy-footed" is almost a common problem among many novice programmers, who are afraid to make even the slightest modification to the code, because any change may or may not lead to destructive changes. As a result, it got out of hand in the end and the problems that arose could not be solved. Working with this legacy code is not only boring and stressful, but also mentally stressful.

But using unit testing can greatly increase the life of the code. Mohamed hopes that he can learn the "art" of unit testing and practice unit testing from the first day of school, but unfortunately the school does not teach this.

In the world, countless exciting innovations are derived from countless trials and errors, but even so, it is still necessary to avoid basic mistakes. In your programming life, what other ridiculous "common misunderstandings" have you encountered? Or has it created some "fatal misunderstandings" that are puzzling? Welcome to leave a message below to share your experience in learning programming.

References:

https://betterprogramming.pub/7-big-mistakes-i-have-made-in-my-career-as-a-software- engineer-f14ef540be10

The above is the detailed content of Be careful to avoid these seven programming misunderstandings!. For more information, please follow other related articles on the PHP Chinese website!