There are many bugs, don't mess around, don't be dominated by bugs

In software development, there are countless eternal topics, one of which is called: Bug. Legend has it that it is a bridge between development and testing, but what we are going to discuss today is not the relationship between development and testing, but the relationship between project management and bugs, because before this, many projects were not lost in development, but lost to bugs.

    It is said that before the system is delivered, you ask the project leader, is there any bug in the project? 99% of project leaders will say No, 1% will say yes. So are there any bugs when the project is delivered? In fact, a system without bugs does not exist, and the testers do not find bugs, which does not mean that the project does not have bugs. However, from another point of view, the project has been thoroughly tested by the project testing team, and no bugs have been found. It can be said that the project has no bugs. But it is also possible that the project leader did not tell the truth, and for the purpose of goodwill, said that the project has no bugs.

    Because there is no strict scale to measure a bug, you say it has it, and you say it doesn't have it without it. It is for this reason that Bug has become a topic that can never be discussed. Let's still talk about the above. From the answers of the project leaders above, we can see that most project leaders strictly require that their projects be launched without bugs. This also reflects the current status of project management. Project managers only focus on bugs, ignoring development, and take a bug-free system as the goal of launching.

    If there is enough time, I believe that all leaders will not let their projects go live with bugs. But this is not the case. In the actual project development process, the development cycle is very short, and the business of the system is very complex, the requirements are frequently changed, and many bugs are generated every day. Some project managers only care about the bugs and progress of the system, and do not consider the current changes in resources and requirements at all, which leads to developers blindly following the bugs, tearing down the east wall to make up for the west wall every day, just standing in place, while the progress of the system No growth.

    Although developers are busy every day, they are actually doing useless work. There are many bugs, don't mess around, don't be dominated by bugs. If there are suddenly more bugs in the system, on the one hand, the requirements may have changed, and on the other hand, the code structure has been disordered and needs to be refactored. If it is a bug caused by structural confusion, be sure to stop and refactor. You know, 80% of projects have experienced code refactoring (including architecture refactoring, framework refactoring, module refactoring, etc.).

    As a development engineer, I have to deal with bugs almost every day and find that many bugs are caused by developers not following the project development specifications, making the originally stable structure more and more chaotic. As the project leader, you should strengthen the review of the newcomer's code to prevent developers from destroying the system structure, resulting in countless bugs and confusion in project management.

Original works are allowed to be reproduced. When reprinting, please be sure to indicate the original source of the article, author information and this statement in the form of hyperlinks. Otherwise held liable. http://genuinecx.blog.51cto.com/2890523/1091971