qr code c# I t s all about reducing risk in Visual C#.NET

Generation QR Code in Visual C#.NET I t s all about reducing risk

Your customer doesn t like risk. Your manager doesn t like risk. Your project manager should have plans in place to mitigate risk. In the end, you shouldn t like risk either. CI is all about reducing risk. Perhaps the biggest risk in software development is schedule slippage in other words, the project being delivered late. Because of the feedback mechanism in the CI

Alex Handy, Survey finds that incremental Java builds are speeding up, Software Development Times, Oct. 29, 2009, www.sdtimes.com/link/33867.

process, team members always know the status of the current build, which helps you know whether the project is getting behind schedule. Feedback mechanisms will be presented in chapter 5. The next biggest risk is bugs. It s been shown that the later in the process you find a bug, the more costly it is to fix. Some estimates suggest that it costs as much as $4,000 to fix a single bug in internal, home-grown corporate web applications. In 2005, a well-known antivirus company had a bug in an update. That single bug caused customers to lose confidence in the antivirus software and forced the company to lower its quarterly income and revenue forecasts by $8 million. Do you want your company to experience similar costs One of the caveats of CI is that bugs are fixed as soon as they re reported. By integrating and testing the software with each build, you can identify and fix bugs earlier in the process. We ll discuss unit testing in chapter 6 and application testing in chapter 7. Have you considered how many different code paths exist in your application Have you tested each if/else combination How about every case of a switch statement In his book Testing Computer Software (John Wiley & Sons, 1999), Cem Kaner mentions a 20-line program written by G. J. Meyers that has 100 trillion paths. Code coverage is a methodology that checks which paths are tested and which aren t. A great thing about code coverage is that you can automate it in your CI process. It s impossible to test every combination; but the more you test, the fewer issues will be uncovered by your customers. Code coverage will also be presented in chapter 6. Another risk is database updates. It s never easy to add columns to a table or new tables to a database. With continuous database integration, you ll know that database changes work properly and without data loss. We ll discuss continuous database integration in more detail in chapter 11. Developers often hate coding and architectural standards, but they have a useful purpose: they ensure that the application follows best practices, which in turn makes the application perform better and makes it easier to maintain. Code reviews catch some of these issues; but because code reviews are a manual process, things are missed. Why not automate standards compliance as part of your CI process We ll cover code analysis in chapter 8. Comments are rarely put in code, and documentation is generated even less often. Many people say that if you re agile, you don t have documentation, but this isn t true. Agile says that you value working software over documentation. But some documentation is still needed, especially if you re creating assemblies for use by other developers. Here s another opportunity for automation in your CI process, and one that ll be covered in chapter 9. How do you know that your installation process works correctly There are few things that frustrate users more than when they can t install an application. Create and test the entire installation process in your CI system. We ll cover deployment and delivery in chapter 10.