Why is code quality not very popular?

Question

I like that my code is streamlined, that is, it is correctly formatted, readable, designed, tested, checked for errors, etc. In fact, I'm fanatical. ( Perhaps even more than a fanatic ... ) But in my experience, actions that help the quality of the code are unlikely to be implemented. (By the quality of the code, I mean the quality of the code that you create every day. The whole topic is software quality with development processes, etc. It is much broader, and not the scope of this question.)

The quality of the code does not seem popular. Some examples from my experience include

• Probably every Java developer knows JUnit, almost all languages ​​implement xUnit frameworks, but in all the companies that I know there were very few correct unit tests (if at all). I know that unit tests cannot always be written due to technical limitations or timelines, but in the cases I saw, unit testing would be an option. If a developer wants to write some tests for his new code, he can do it. I came to the conclusion that the developers do not want to write tests.

• Static code analysis is often performed in small projects, but is not actually used to enforce coding agreements or look for possible errors in corporate projects. Usually, even compiler warnings, such as null pointer access, are ignored.

• Conferences and conference journals will talk a lot about EJB3.1, OSGI, Cloud and other new technologies, but hardly about new technologies or testing tools, new approaches to static code analysis (for example, SAT-solution), development processes that help to support better quality, like some nasty beast of outdated code was tested ... (I have not attended many conferences, and it probably looks different for conferences on flexible topics, since unit testing and CI and the like have more at sokuyu value there.)

So why is code quality so unpopular / considered boring?

EDIT:
Thank you for your responses. Most of them relate to unit testing (and was discussed in a related question ). But there are many other things that can be used to maintain high quality code (see related question ). Even if you cannot use unit tests, you can use daily builds, add some static code analysis to your development or development environment, try to program pairs or perform critical code checks.

Answer 1

One obvious answer for the part of Qaru is not a forum. This is a database of questions and answers, which means that attempts to duplicate questions are avoided.

How many different questions about code quality can you imagine? That’s why there aren’t 50,000 questions about “code quality”

In addition, anyone who claims that conference speakers do not want to talk about unit testing or code quality should obviously go to more conferences.

I have also seen more than enough articles on continuous integration.

There are general excuses for not but they are just excuses. If someone wants to write tests for his / her new code, then this is possible

In fact? Even if your boss says, “I won’t pay you for wasting time on unit tests”? Even if you are working on any embedded platform without unit testing modules? Even if you work on a tight schedule, trying to hit some short-term goals, even at the cost of long-term code quality?

No. Unable to write unit tests. There are many common obstacles. This does not mean that we should not try to write more and better tests. Just sometimes we don’t get this opportunity.

Personally, I’m tired of discussing "code quality" because they tend to

• too preoccupied with hypothetical examples and too often are the brainchild of some person who really didn’t consider how applicable he is to other people's projects or codebases of different sizes than the one he is working on,
• tend to get too emotional, and fill our code with too many human features (think of the term “code smell,” for a good example)
• dominated by people who write awful bloated, complex and complex code with too many levels of abstraction or who will judge whether the code can be reused "it looks like I can just take this piece of code and use it in a future project", and not much more meaningful "I really was able to take this piece of code and reuse it in different projects."

I am definitely interested in writing quality code. I'm just inclined to what people usually say about the quality of the code.

Answer 2

Code review is not an exact science. The indicators used are somehow controversial. Somewhere on this page: “You cannot control what you cannot measure”

Suppose you have one huge function of 5000 lines with 35 parameters. You can unit test as much as you want, it can do exactly what it should do. Whatever the input. Therefore, based on unit testing, this feature is "perfect." In addition to being correct, there are several other quality attributes that you might want to measure . Performance, scalability, maintainability, usability, etc. Have you ever wondered why software is such a nightmare?

Quality control of real software projects goes far beyond simple code verification. If you test the V-Model software development , you will notice that coding is only a small part of the whole equation.

Quality control software can reach 60% of the total cost of your project. This is huge. Instead, people prefer to shrink to 0% and go home, thinking they have made the right choice. I think the real reason why so little time is devoted to software quality is that software quality is not well understood.

• What do you need to measure?
• How do we measure it?
• Who will measure it?
• What will I gain / lose from measuring it?

Many do-it-yourself bowler pots do not understand the relationship between "less mistakes now" and "more profits later." Instead, all they see is "time wasted" and "less profit now." Even if the beautiful graphics shown demonstrate the opposite.

In addition, software quality control and software development in general is a relatively new discipline. Many software spaces have so far been occupied by cyber cowboys. How many times have you heard that someone can program? Anyone can write code that is accurate, but that’s not all who can be a programmer.

EDIT *

I met this document (PDF) , which is from a guy who said: “You can’t control what you can,” t measures. “He basically says that controlling everything is not as desirable as he thought at first. This is not an exact recipe cooking that you can blindly apply to all projects, like schools of software that want to make you think. It just adds another control parameter: “I want to control this project? Will he be needed? "

Answer 3

• Laziness / Considered boring
• Management feels unnecessary - Ignorant attitude "Just do it right."
• "This small project does not need code quality management" turns into "Now it would be too expensive to manage the quality of code on this large project"

I do not agree that it is boring. The solid modular testing design makes creating tests a breeze and even more fun.

Calculating vector flow control - PASSED Assigning flux capacitor variance level - PASSED Rerouting superconductors for faster dialing sequence - PASSED Running Firefly hull checks - PASSED Unit tests complete. 4/4 PASSED. 

Like everything that can be boring, if you do too much, but spend 10 or 20 minutes writing some random tests for some complex functions after several hours of coding, this will not suck the creative life from you.

Answer 4

Why is code quality so unpopular?

Because our profession is unprofessional.

However, there are people who care about the quality of the code. You can find such people, for example, from the Software Craftsmanship discussion group . But, unfortunately, most people in the software industry do not understand the value of code quality or do not even know what constitutes good code.

Answer 5

I think the answer is the same as the question "Why is the quality of the code not popular?"

I believe that the main reasons are:

• Laziness of developers. Why invest time in the preparation of unit tests, review the solution, if it is already implemented?
• Improper management. Why ask developers to cope with the quality of the code if there are thousands of new feature requests, and programmers can simply implement something, instead of taking care of the quality of the already implemented one.

Answer 6

The short answer. This is one of those intangible assets that only other, mostly experienced, developers and engineers evaluate if something is wrong. At this point, managers and clients are outraged and demand that formal processes not be in place.

Longer answer: this short-sighted approach is not limited to software development. The best example of this is probably the American auto industry (or what remains of it).

It is also more difficult to justify formal engineering processes when projects begin their life as disposable or discarded. Of course, long ago, when the project is completed, it takes its own life (and becomes noticeable), as various business units start depending on this for their own business process.

At this point, a new solution needs to be developed; but without the practice of using these tools and good practices, these tools are less useless. They become a laborious obstacle. I see this situation too often in companies where IT teams support the business, where development is often reactionary rather than active.

Edit: Of course, these bad habits and many others are the real reason that consulting firms, such as Thought Work, can continue to grow as well as they do.

Answer 7

One of the important factors that I have not mentioned yet is that any process improvement (unit testing, continuous integration, code reviews, etc.) must have a lawyer in an organization committed to technology, has a corresponding influence within the organization, and wants to do work to convince others of value.

For example, I saw exactly one engineering organization where a code review was seriously considered. This company had a vice president of software, which was a true supporter, and he sat in reviews of codes to make sure that they were being done correctly. By the way, they had the best performance and quality of any team with which I worked.

Another example is that I implemented a partial testing solution in another company. At first, no one used it, despite the perseverance of the leadership. But some of us did our best to discuss unit testing and provide as much help as possible to anyone who wanted to start unit testing. In the end, several of the most respected developers signed up as soon as they began to see the benefits of unit testing. After that, our testing improved significantly.

I just thought about something else - some tools take a considerable amount of time to get started, and that startup time may be difficult. Static analysis tools can be terrible - you run the tool and it reports 2000 problems, most of which are harmless. Once you correctly configure the tool, the false-positive problem will be greatly reduced, but someone should take this time and be sure to maintain the configuration of the tool over time.

Answer 8

Probably every Java developer knows JUnit ...

Although I believe that most or many developers have heard of JUnit / nUnit / other testing platforms, they know less how to write a test using this structure. And very few of them understand well how to make testing a part of the solution.

I have known about unit testing and unit test frameworks for at least 7 years. I tried to use it in a small project 5-6 years ago, but only in the last few years I learned how to do it right. (i.e. found a way that works for me and my team ...)

For me, some of these things were:

• Search for a workflow that involves unit testing.
• Integrating unit testing in my IDE and having shortcuts to run / debug tests.
• Learning how to test. (How, for example, how to test login or file access. How to abstract from the database. How to make bullying and use a mocking structure. Learn methods and patterns that increase testability.)
• Having some tests is better than no tests at all.
• Additional tests can be written later when an error is detected. Write a test confirming the error, then correct the error.
• You will need to practice this.

So, until you find the right path; yes, it’s boring, not useful, hard to do, time, etc.

EDIT: In this blogpost I will talk in detail about some of the reasons given here for unit testing.

Answer 9

This is the basic psychology of pain. When you run to meet the deadline, the quality of the code takes last place. We hate it because it's boring and boring.

Answer 10

Is the quality of the code unpopular? Let me dispute this fact.

Conferences such as Agile 2009 provide many presentations about continuous integration, as well as test methods and tools. A technical conference, such as Devoxx and Jazoon, also has its share of these items. There is even a conference dedicated to continuous integration and testing ( CITCON , which is held 3 times a year on 3 continents). In fact, my personal feeling is that these conversations are so common that they are on the verge of complete boredom for me.

And in my experience as a consultant, advising on code quality methods and tools is actually pretty easy to sell (albeit not very well paid).

However, although I believe that code quality is a popular topic of discussion, I would rather agree that developers do not (generally) have good or sufficient tests. I have a fairly simple explanation for this fact.

In essence, this boils down to the fact that these methods are still quite new (TDD is 15 years old, CI is less than 10), and they have to compete with 1) managers, 2) developers whose methods have "worked well enough so far" (whatever that means.) According to Jeffrey Moore, modern code quality methods are still in the early stages of the adoption curve, and it will take time until the whole industry accepts them.

The good news is that now I meet developers fresh from the university who have been trained by TDD and are really interested in it. This is a recent development. After many of them enter the market, the industry will have no choice but to change.

Answer 11

It's pretty simple when you look at the proverb “Good, fast, cheap: pick two.” In my experience, 98% of the time, it’s Fast and Cheap, and if necessary the other should suffer.

Answer 12

This reminds me of this Monty Python skit:

"Exciting? No, no. Dull, dull, dull. Oh my god, he's boring, he's so desperately boring and tiring, stuffy and boring and de-edible DULL."

Answer 13

I would say for many reasons.

First of all, if the application / project is small or does not contain really important data on a large scale, the time required to write the tests is best used to write the actual application.

There is a threshold where quality requirements are at the level required for unit testing.

There is also a problem with many methods that cannot be easily verified. They can rely on data in a database or similar, which creates a headache when setting up layout data that needs to be passed to methods. Even if you customize the layout data - can you be sure that the database will behave the same?

Unit tests are also weak in finding problems that have not been addressed. That is, unit testing is bad at modeling the unexpected. If you have not taken into account what can happen during a power outage, if the network link sends incorrect data, which is still the correct CRC. Writing tests for this is useless.

I’m all a proponent of code validation because they allow programmers to share experiences and code style with other programmers.

Answer 14

"There are general prerequisites for not writing tests, but they are justifications."

They? Get eight programmers in a room together, ask them a question about how best to maintain the quality of the code, and you will get nine different answers depending on their age, education and preferences. 1970s Computer scientists laughed at the concept of unit testing; I'm not sure they were wrong.

Answer 15

Management should be sold at a cost that takes more time to save time on the road. Since they cannot actually measure “errors that are not fixed,” they are often more concerned about meeting deadlines and dates than the long-term quality of the project.

Answer 16

The quality of the code is subjective. Subjective topics are always tiring.

Since the goal is to do something that works, the quality of the code always comes in the second. This adds time and cost. (I'm not saying that this should not be considered a good thing.)

In 99% of cases, there are no third parties for poor quality code (unless you make software to switch spaces or trips).

• It works? = Concrete.
• It is beautiful? = In the eye of the beholder.

Read Fred Brooks "Mythical Man of the Month". There is no silver bullet.

Answer 17

Unit testing requires additional work. If a programmer sees that his product "works" (for example, without unit testing), why do this? Especially when it is not so interesting as the implementation of the next function in the program, etc. Most people are just lazy when it comes to it, which is not very good ...

Answer 18

The quality of the code depends on the context and is difficult to generalize no matter how much effort it tries to make.

This is similar to the difference between theory and application.

Answer 19

I have also not seen unit tests written on a regular basis. The reason for this was that the code was changed too much at the beginning of the project, so everyone refused to write unit tests until everything was stable. After that, everyone was happy and did not need unit tests. Thus, we have several tests that remain there as a story, but they are not used and are probably not compatible with the current code.

I personally believe that writing unit tests for large projects is not possible, although I admit that I have not tried or talked with people who did this. There are so many rules in business logic that if you change something a little, you have no way of knowing which tests to update outside of those that will be broken. Who knows, old tests now may not cover all the possibilities, and it takes time to remember what was written five years ago.

Another reason is lack of time. When you have a task that says "Completion time: O, 5 people / days", you only have time for its implementation and a shallow check, so as not to think about all possible cases and relationships with other parts of the project and write all the necessary tests . It may take 0.5 days to implement something, and a couple of weeks to write tests. If you were not specifically ordered to create tests, no one will understand this huge loss of time, which will lead to screams / bad reviews. And no, for our sophisticated enterprise application, I can't come up with a good test coverage for a task in five minutes. This will take time and, possibly, a very deep knowledge of most application modules.

Thus, the reasons why I see them is the loss of time, which does not provide any useful functions and a nightmare for maintaining / updating old tests to reflect new business rules. Even if someone wanted to, only experienced colleagues could write these tests - at least a one-year participation in the project, but really need two or three. Therefore, new colleagues do not cope with the proper tests. And it makes no sense to create bad tests.

Answer 20

It's boring to "catch some random" feature "with extreme importance for more than one day in a mysterious code jungle written by someone else x years ago, without any clue what is going wrong, why it is not, and there are absolutely no ideas what could fix it when it was supposed to end in a few hours, and when this is done, no one will be satisfied with the cause of the huge delay.

I was there - I saw it.

Answer 21

Many concepts that are emphasized in modern work on code quality do not take into account the main indicator of code quality: the code must be functional in the first place. Everything else is just a means to an end.

Some people do not feel that they have time to find out the latest quirkiness in software development and that they can write high-quality code already. I can’t judge them, but, in my opinion, it’s very difficult to use your code for long periods of time if people cannot read, understand and modify it.

Answer 22

The lack of "code quality" is not worth the user, seller, architect, or code developer; this slows down the next iteration, but I can come up with several successful products that seem to be made from hair and dirt.

I find unit testing to make me more productive, but I saw a lot of poorly formatted, unreadable poorly designed code that passed all of its tests (usually a long code that has been fixed many times). After passing the tests, you will get dear Skoda, and not the skill of Bristol . But if you have a "low quality code" and you pass the tests and consistently fulfill the requirements of the user, then this is a valid business model.

My conclusion is that the developers do not want to write tests.

I'm not sure. In part, the entire learning process in software is independent of the test and probably should be - instead of asking the exercise to be passed, give students single tests. It’s normal in mathematics to run a test, why not in software development?

Another thing is that units are required for unit testing. Some developers find modulation and encapsulation difficult to succeed. A good technical leader will create a modular architecture that localizes the scope of the device, so testing individually is simplified; many systems do not have good architects that facilitate testability or do not refactor regularly enough to reduce inter-unit communication.

It is also difficult to test applications with a distributed or graphical interface due to the inherent connection. I was only on one team that did it well, and it had the same large testing department as the development department.

Static code analysis is often reproduced in small projects, but is not actually used to enforce coding rules or look for possible errors in corporate projects.

Each set of coding rules that I saw that was not automated was logically inconsistent, sometimes to the point of unsuitability — even those that claimed to have been used “successfully” in several projects. Non-automatic coding standards appear to be political rather than technical documents.

, , .

, .

Answer 23

, ( , ), , , . , , , "-".

, , , , .

Answer 24

, , , , - ( / ).

, "", .

Answer 25

, , - - . . , - , ?

, . , , , , , ...

Answer 26

I dont know. Sonar ? , Maven , , . , .

Answer 27

, , .

Answer 28

, . , . . , " , ", , , PMD , . / ( PMD , ) ( , ).

, . FindBugs , instaceof . , FindBugs .

, , 500 , 500 . , , ( .).

, . , . 100% , , - . , -, ( ) , , , todo , .

, , , , -, . , , DbUnit .

Answer 29

, "" . " " " ".

- , , . :

http://agileinaflash.blogspot.com/2010/02/seven-code-virtues.html

, , . , . , . , .

, , . , .

Answer 30

, , , . == ? , . == ? , , . , , .

, , , ( , , ). , - , . , .

- , , ( maven).

- (unit test , -), , .

, HtmlUnit , . -. SQL- ( DbUnit , . 5 - , ). - , , , , , .