[Translation] 7 deadly sins in software development
Friends, I present to you the translation of the article "The 7 deadly sins of software development" by Neil McAllister, published on infoworld.com .
I want to make a reservation right away that I translated the word “feature” quite often in this article as a “feature”, since This is a fairly common translation option, as for me.
So let's go.
')
To become a good software developer takes years of training and practice. However, without proper discipline, even the best programmers risk falling victim to the worst traits of human nature. Some bad habits are so insidious that they appear again and again, even among the most experienced developers. It's about 7 deadly sins of software development. Read on and you will learn how passion, gluttony, greed, laziness, anger, envy and pride may have already eroded the project you are working on at the moment.
Modern programming languages ​​tend to include more and more new features over time. They pile up abstractions layer by layer, adding new keywords and structures to help improve readability and code reuse - but only if you spend some time learning how to use them correctly.
At the same time, the field of programming knowledge itself has changed in recent years. You now have at your disposal giant volumes dedicated to design patterns, and every few months someone offers a new development methodology, vowing that its use will turn you into God among programmers.
But what looks good on paper does not always work in practice. And the fact that you can do something does not mean that you have to do it. Programming guru Joel Spolsky says it like this: “Product release is a feature. Very important feature. And your product must possess it. ” Programmers who are engaged in fetishism of their development tools, inevitably overlook this moment, and even the simplest of projects can get bogged down in the hell of development. Resist these base impulses and stick to the solutions that really work.
Nothing delivers such pleasure as product release. Once you have the finished version, it is tempting to start planning the next iteration of development. What new features to add? Which of them we did not have time to do during the development of the first version?
It's easy to forget that the code is rarely great. The amount of functionality naturally increases with each iteration of development, and programmers, as a rule, only exacerbate the mistakes that were made in past iterations. This, in turn, leads to bloated and fragile code that is too entangled to effectively support it.
Instead of absorbing new features a plate behind the plate, hold yourself. Evaluate existing code for quality and maintainability. Refactor the code in a separate line in the budget of each new project iteration. Perhaps customers will see only new features in each release, but over time they will thank you for the fact that your product is not overgrown with fat.
Excessive desire for power and strength - how else can one explain the motives of those programmers who are competing with their colleagues? It all starts with the fact that some teams are simply excluded from email lists, then the meetings are held behind closed doors. Well, after that one of the teams writes the library, which re-implements most of the functionality that has already been implemented by another team.
Programmer teams rarely reinvent the wheel by malicious intent, but the lack of well-defined goals can easily lead to a much wider field of responsibility than is really necessary. The result is redundant, unsupported code, not to mention losses from the point of view of the project budget due to duplication of development. One of the most important tasks of a software development project management should be the awareness of each of the teams of what other teams are doing and the understanding of the common goal. Your slogan should be the words: "Share everything equally."
The list of basic programming errors is quite long, but the sin of not checking the input data is so destructive that you need to be said about it separately. It is puzzling that this rather amateurish error is still manifested in code written by some experienced programmers. And yet, research into the causes of many security holes in the systems (from buffer overflow errors to SQL injection) leads directly to code that operates on input data without checking them for validity and correct formatting.
Modern programming languages ​​provide a large number of tools to avoid this error, but they still need to be properly used. Remember that a web form that uses javascript to validate input data can be easily circumvented by turning off javascript in the browser, or when accessed without using a browser at all. Input validation should be flashed to your application code, not scattered in the UI. Anything less is just laziness.
What act on your part can be more hostile towards your colleagues than the absence of comments in the code? Yes, I know, I know: well-written code is better than any documentation. And you know what? The 2 methods you wrote at 2 am last Tuesday are not very well written code. (And if you are a Perl hacker, you have to sing Ave Maria nine times).
Programmers easily forget that the code they write today can live many more years after they leave the company. And those who come to replace them are faced with the inevitable task of finding out what each piece of code was intended for. Therefore, be merciful, leave them at least a couple of hints on it.
But remember that meaningless comments, as well as unnecessary inflexion, can be even worse than a complete lack of comments. Comments like “it doesn't work” or “never touch it!” Are not very helpful to others. Unnecessary comments explaining simple operations like variable initialization are also useless. The code best documents what it does; comments are needed in order to understand why .
It is hard to believe that in 2011 there are still projects that are stored as a group of folders on a file server, jealously guarded by one “keeper”. On the developers' computers all over the office there are scattered copies of these folders, each a little different from the others, although no one knows exactly what.
Perhaps you have reasons for not implementing version control in your projects. Perhaps the project was small, but now it’s just out of control. But today you have a large number of powerful, effective version control systems at your disposal, which you can use for free. Service providers are even ready to place the code of your distributed projects on their servers for minimal money. There are no objective reasons why you should not create a code repository as one of the first steps when launching a new project. This applies even to small projects. The only exception is the case when you just can not accept the fact that the changes in the code will be committed by someone other than you.
You often want to pat yourself on the back and thank you for a job well done. But how do you know that it is really well done? What metrics do you use?
You cannot be sure that your code works as it should and does not contain any defects, unless you use special test cases for this test. But too many developers simply cannot compile test cases for their code. They claim that the time spent on testing is time that was not spent on implementing new features. In fact, some developers do not even include QA testing in their project budgets.
What can I say, except that pride always accompanies a fall? By the time the code containing the defects falls into the hands of customers, it will be too late to change anything. The more time you spend on unit testing before releasing your code, the more problems you will avoid in the future.
PS From myself I would like to add that many ideas have something in common with entire chapters in Steve McConnell's The Perfect Code. If you haven’t read it yet, I highly recommend correcting this omission :)
I want to make a reservation right away that I translated the word “feature” quite often in this article as a “feature”, since This is a fairly common translation option, as for me.
So let's go.
')
To become a good software developer takes years of training and practice. However, without proper discipline, even the best programmers risk falling victim to the worst traits of human nature. Some bad habits are so insidious that they appear again and again, even among the most experienced developers. It's about 7 deadly sins of software development. Read on and you will learn how passion, gluttony, greed, laziness, anger, envy and pride may have already eroded the project you are working on at the moment.
1. Passion (excess design)
Modern programming languages ​​tend to include more and more new features over time. They pile up abstractions layer by layer, adding new keywords and structures to help improve readability and code reuse - but only if you spend some time learning how to use them correctly.
At the same time, the field of programming knowledge itself has changed in recent years. You now have at your disposal giant volumes dedicated to design patterns, and every few months someone offers a new development methodology, vowing that its use will turn you into God among programmers.
But what looks good on paper does not always work in practice. And the fact that you can do something does not mean that you have to do it. Programming guru Joel Spolsky says it like this: “Product release is a feature. Very important feature. And your product must possess it. ” Programmers who are engaged in fetishism of their development tools, inevitably overlook this moment, and even the simplest of projects can get bogged down in the hell of development. Resist these base impulses and stick to the solutions that really work.
2. Gluttony (inability to refactor)
Nothing delivers such pleasure as product release. Once you have the finished version, it is tempting to start planning the next iteration of development. What new features to add? Which of them we did not have time to do during the development of the first version?
It's easy to forget that the code is rarely great. The amount of functionality naturally increases with each iteration of development, and programmers, as a rule, only exacerbate the mistakes that were made in past iterations. This, in turn, leads to bloated and fragile code that is too entangled to effectively support it.
Instead of absorbing new features a plate behind the plate, hold yourself. Evaluate existing code for quality and maintainability. Refactor the code in a separate line in the budget of each new project iteration. Perhaps customers will see only new features in each release, but over time they will thank you for the fact that your product is not overgrown with fat.
3. Greed (competition between development teams)
Excessive desire for power and strength - how else can one explain the motives of those programmers who are competing with their colleagues? It all starts with the fact that some teams are simply excluded from email lists, then the meetings are held behind closed doors. Well, after that one of the teams writes the library, which re-implements most of the functionality that has already been implemented by another team.
Programmer teams rarely reinvent the wheel by malicious intent, but the lack of well-defined goals can easily lead to a much wider field of responsibility than is really necessary. The result is redundant, unsupported code, not to mention losses from the point of view of the project budget due to duplication of development. One of the most important tasks of a software development project management should be the awareness of each of the teams of what other teams are doing and the understanding of the common goal. Your slogan should be the words: "Share everything equally."
4. Laziness (no validation of input data)
The list of basic programming errors is quite long, but the sin of not checking the input data is so destructive that you need to be said about it separately. It is puzzling that this rather amateurish error is still manifested in code written by some experienced programmers. And yet, research into the causes of many security holes in the systems (from buffer overflow errors to SQL injection) leads directly to code that operates on input data without checking them for validity and correct formatting.
Modern programming languages ​​provide a large number of tools to avoid this error, but they still need to be properly used. Remember that a web form that uses javascript to validate input data can be easily circumvented by turning off javascript in the browser, or when accessed without using a browser at all. Input validation should be flashed to your application code, not scattered in the UI. Anything less is just laziness.
5. Anger (lack of practice to comment on the code)
What act on your part can be more hostile towards your colleagues than the absence of comments in the code? Yes, I know, I know: well-written code is better than any documentation. And you know what? The 2 methods you wrote at 2 am last Tuesday are not very well written code. (And if you are a Perl hacker, you have to sing Ave Maria nine times).
Programmers easily forget that the code they write today can live many more years after they leave the company. And those who come to replace them are faced with the inevitable task of finding out what each piece of code was intended for. Therefore, be merciful, leave them at least a couple of hints on it.
But remember that meaningless comments, as well as unnecessary inflexion, can be even worse than a complete lack of comments. Comments like “it doesn't work” or “never touch it!” Are not very helpful to others. Unnecessary comments explaining simple operations like variable initialization are also useless. The code best documents what it does; comments are needed in order to understand why .
6. Envy (not using version control systems)
It is hard to believe that in 2011 there are still projects that are stored as a group of folders on a file server, jealously guarded by one “keeper”. On the developers' computers all over the office there are scattered copies of these folders, each a little different from the others, although no one knows exactly what.
Perhaps you have reasons for not implementing version control in your projects. Perhaps the project was small, but now it’s just out of control. But today you have a large number of powerful, effective version control systems at your disposal, which you can use for free. Service providers are even ready to place the code of your distributed projects on their servers for minimal money. There are no objective reasons why you should not create a code repository as one of the first steps when launching a new project. This applies even to small projects. The only exception is the case when you just can not accept the fact that the changes in the code will be committed by someone other than you.
7. Pride (no unit testing)
You often want to pat yourself on the back and thank you for a job well done. But how do you know that it is really well done? What metrics do you use?
You cannot be sure that your code works as it should and does not contain any defects, unless you use special test cases for this test. But too many developers simply cannot compile test cases for their code. They claim that the time spent on testing is time that was not spent on implementing new features. In fact, some developers do not even include QA testing in their project budgets.
What can I say, except that pride always accompanies a fall? By the time the code containing the defects falls into the hands of customers, it will be too late to change anything. The more time you spend on unit testing before releasing your code, the more problems you will avoid in the future.
PS From myself I would like to add that many ideas have something in common with entire chapters in Steve McConnell's The Perfect Code. If you haven’t read it yet, I highly recommend correcting this omission :)
Source: https://habr.com/ru/post/114593/
All Articles