Shulou(Shulou.com)06/02 Report--

The agreed software quality

Improving software quality is an ideal that we have always pursued, but the only constant truth of software development is change. in order to cope with the ever-changing software development process, agile development advocates a software development concept that embraces change. at least it brings a lot of luck to software developers.

The ultimate goal of these software development models and methodologies is to improve software development management and quality, not so much to improve quality as to maintain a certain level. Although there are many different methodologies for agile development (such as Scrum, XP, etc.), we note that these methodologies are bound to mention the concept of "continuous integration (Continuous Integration)." Who on earth is continuous integration? Make it so valued in software engineering. To put it another way, I often compare agile development to martial arts, which is virtual and represents the core idea of methodology, and its moves are the effective medium. however, continuous integration is one of the martial arts moves realized by agile development.

Master the rhythm of software development

No matter what Min Jiekai has sent, let's first talk about why you should be recommended for "continuous integration". In software development, we must attach great importance to project management, because there are too many uncertain factors in the process of software construction, and the project is always Delay. Often occurs in the late stage of product development, the system gradually began to emerge a variety of signs of Bug and instability, the later the version submission deadline Delay, the higher the chance. Continuous integration is to avoid such a situation, I think the biggest advantage of continuous integration is to be able to "master the rhythm of software development"!

Huh? What is the rhythm of software development? This actually indicates our mastery of the software development project and ensures that the software can deliver products that meet the specifications and quality requirements within the promised time. In the process of continuous integration, we will make the current health status of the software transparent at any time. Once these states are transparent, the problems are easy to be revealed, and then the problems are easy to be mastered and eliminated. Instead of delivering it to the customer, it is found that there is something wrong with a feature. Common software development projects have the following wishes:

Programmers want to write programs realistically.

The project manager wants to have a firm grasp of the schedule

The organization wants to reduce costs and development risks

Customers want to get products of high quality

We also hope to make these wishes come true by mastering the rhythm of software development!

Quickly avoid turning from disease to disease.

If we participate in the poor software development process for a long time, it is easy to lose faith and insistence on software quality over time, which does great harm to the organization and team, but also because it is not easy to eradicate. Engineers work overtime for the project schedule, while PM sacrifices quality for the schedule. Programmers gradually in order to quickly solve the immediate problem, began to build software, began to use some strange methods (Dirty Hard Code) to solve the Bug... automatically generated by the system. I think you should understand what these strange methods refer to? As time goes by, our feelings for software will fade. Anyway, with the blessing of Murphy Theorem, the project will be delayed and Bug will never be finished. In the face of the complexity of software development, we have unwittingly changed from disease to disease, the disease can be cured, and the disease can only be controlled.

So what exactly is continuous integration?

Wouldn't it be nice to assume that we can keep track of the state of the software at any time and make the state of all the software in development transparent? Going back to the topic of "continuous integration", I simply explain that "continuous" means "non-stop, non-stop, always, just do something". What about "integration"? The integration in software development is not "run the Code written by everyone together to see if there is anything wrong!" ". By analogy, the word "continuous integration" means "if you have nothing to do, just run the Code you wrote together to see if there is anything wrong!" "Oh, doesn't that sound easy!?

Let's start with the intention of continuous integration. Agile development (Agile), which we often come into contact with, often releases a new version in a very short cycle (about two weeks of Scrum) in order to adapt to change quickly, which is called Small Release in XP. However, each release does not focus on how many new features are added? But to produce a product that is getting closer to the market. Note that every released software must be able to be executed correctly! In many agile development methodologies, it is mentioned that code that can be executed correctly trumps everything, and certainly better than damn files.

The question is, how can we verify that the software works properly in a short period of time? If you have less functionality at first, you can take some time to test it manually, but there will be no way to have more features later, let alone to test the features of the new version, let alone to make sure that the existing features work properly. This is the time for "continuous integration" to work. Back to what I just mentioned: "if you have nothing to do, just run the Code written by everyone together to see if there is anything wrong!" "for us, such a thing is actually automatically building and testing Code from the version control system. Once we continue to do this in the process of development, we can immediately detect when the software is unstable, it will be able to greatly reduce the risk and time of integration testing, because we are conducting integration testing anytime and anywhere!

About testing and Automation

The tests mentioned above are not manual or semi-automatic tests, but fully automated tests. In the process of repeated and intensive testing, I'm sure you don't want to do it manually (paying for a job and student test is not the solution), and as long as people do it, there is a chance to be wrong! Automated testing would be a better method.

In fact, the issue of "writing tests" is probably the most difficult to promote in the whole process of continuous integration, often because our education does not make novice programmers understand the importance of testing programs at the beginning. Daily work is also in the pursuit of functional implementation, rather than the correct implementation of functions, often only pay attention to the results of the execution of the program itself (with the eyes). In agile development, the concept of test-driven development (TDD, Test-driven development) has also been mentioned, but if you develop a system without experienced software architects, then this model will be more difficult to implement in practice, because it is often found that there is no way to automatically test the existing software architecture design. If you want to change it, you have to make a big change, and the confidence and idea of testing will be destroyed.

In fact, in the process of testing, there is a smell of re-reviewing the system, for example, we can all find more software design deficiencies and find more designs that can be improved, such as using decoupling, object abstraction, data connection layer (Data Access Layer), Mock Object, Dummy Data and other techniques to reconstruct the architecture. Another great way to implement testing is to implement pair programming (Pair Programming), but what does this have to do with testing? Let's think about it first. in pair programming, one person often writes the program and the other writes the test. this process forces us to design code that can be tested by other programs, indirectly achieving automated testing. The concepts at the top of many organizations must be adjusted, and it is difficult for some bosses to understand why two people should do the same thing, but the company has to pay two people's salary!

It is difficult to implement automated testing, but these are not the reasons for us to avoid. In fact, we do not have to rush to improve test coverage in the first place, starting with basic functional testing. Generally speaking, there are two directions that can be achieved slowly:

1. Test the correctness of the basic functions first, at least to ensure that the functions can be performed (though not necessarily right).

two。 When the Bug appears on the system, write a test program with replication errors before solving the Bug, and then fix the Bug to ensure that the same Bug will not happen again in the future.

These two points are particularly effective for systems that are already under development, where automated testing can be built slowly, and it is much easier to get started. I have seen a practical example of adding automated testing at the later stage of a software that has been developed for a long time. Although the coverage is less than 30%, the manager made a very binding decision to integrate the version control system. The future Commit code can not reduce the coverage of the entire system. So automatic testing will be carried out after each Commit, constraining that future code must be forced to write automated tests to ensure that the quality of the product will not get worse and worse.

There are many modes and kinds of testing, try to find out the automated testing methods suitable for your own products, and there is no certain standard answer. Finally, although the test coverage we can achieve is limited, or the current complex software architecture makes it difficult to write tests, these are no excuses. We have to start before there is room for improvement.

System feedback

As mentioned earlier, because the continuous integration system is being integrated and tested all the time, it will issue a warning to the developer when the continuous integration finds that the software is unstable (refers to build or test failure). This behavior is called "Feedback system feedback", which is a very important thing in the continuous integration system. When we receive such feedback from the system, we should deal with it immediately, rather than wait until we are close to the product release deadline before we begin to face the warning given to us by continuous integration, causing worries about product schedule and quality.

The easiest way to achieve system feedback is through "daily build", which is usually performed at night (or Nightly Build). Since programmers in good physical and mental health usually submit stable code before leaving work, it is a good way to conduct integration testing in the dead of night. Because the system updates the latest program code every night to build, when there is a problem, it will issue a "system feedback" warning, usually Email to inform several relevant losers, so that the victim can start to deal with the problem early the next morning, as far as possible so that the software we build can maintain a stable state at any time in the software development process. If you can even release the system under development at any time under reasonable test coverage, isn't that the spirit of agile development to "adapt to change quickly"?

The spirit of continuous integration: automation + testing + system feedback

As each software project is different, there is no absolute standard answer to the software construction process, only to do the corresponding approach that is suitable for the team. In practice, to build a continuous integration system, it does take a lot of effort to write Script build scripts, especially in the automated construction and execution of the test environment. Although the methods are different, all the concepts revolve around the three spirits of "automation + testing + system feedback". I think we all need the courage to continue to devote ourselves to continuous integration and make the software better! I believe we can all create software that we can be proud of!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.