Some development practices improve software quality, regardless of the domain of the application, the language in which it's written, the platform on which it runs, or the users it is intended to serve. This seminar explores fundamental principles, practices, and standards that improve software quality, no matter what the software does, how it does it, or whom it does it for.
Unlike most treatments of software quality, this seminar focuses on the critical role that programmers play, and it discusses specific strategies applicable to their activities.
Participants will gain:
An understanding of why programmer discretion plays a key role in determining software quality.
Knowledge of specific practices that help improve the quality of any software effort.
Insights into the quality-related interactions of specifications, programming, and testing.
Who Should Attend
The primary audience for this seminar is the people responsible for the code: programmers, team leads, and development managers. The information is also well-suited for professionals who work with such people (e.g., QA personnel) or who are interested in improving their organization's software development process.
Lecture and question/answer. There are no hands-on exercises.
One full day (six to seven lecture hours).
Detailed Topic Outline
The crucial role of programmers in software quality.
How quality improvement practices reduce development costs.
Requiring and enforcing useful specifications:
What is a useful specification?
Design by contract
Designing Interfaces that are easy to use correctly, hard to use incorrectly:
Applies to both APIs and UIs
The principle of least astonishment
Choosing good names
Designing "nice" classes
The importance of consistency
Employing progressive disclosure
Preventing resource leaks
Documenting interfaces before implementing them
Introducing new types
Constraining available values
Embracing static analysis:
Lint and similar utilities
Custom parsers and analyses
Code reviews and inspections
The keyhole problem:
What it is, how it manifests itself
Why it matters
How it can be avoided
Why duplication is bad
Source code duplication vs. object code duplication
Preventing source code duplication
Preventing object code duplication
Beyond code duplication
Embracing Automated Unit Testing:
What to test
What it is
How to do it
Why it's useful
How it relates to conventional post-development testing
What they are
Their beneifts, both technical and social
When to hold them; who should participate
The importance of safety
Why the material in this seminar applies to you, no matter how special your circumstances.
Sources for Additional Information
Dependency Injection is one of those terms that advanced programmers throw out with an expectation and assumption of full understanding on the part of the receiver. However, I constantly get asked by attendees, students, and clients to please recommend a good DI product and show them how to use it; and when I proceed to start talking about the subject, it becomes immediately apparent that many don't even know what they're asking about. It's easy to get infatuated by a cool buzz phrase, specially when you hear so many others using it. But to truly understand something you need to start by understanding the problem spaces that it is trying to solve. So let's bring you totally up to speed then. In this session, I'll explain dependency injection from concept to implementation, and use raw code samples to show you how it works and what problems it solves. Then I'll get into what a DI container is and some of the characteristics of the ones that are out there, including MEF. I'll end by showing you implementation examples in three different platforms.
Tests are a good thing, right? But how much should we test? What's not enough? What's too much? What should we test, and when?
In this talk, we'll look at the many levels of testing, from the outermost UI tests to unit tests, what works well, what doesn't work well. We'll look at functional testing, subcutaneous testing, integration and unit testing and where and why we would want to do each. We'll arrive at a testing strategy for the sane without retreating into dogma by looking at real-world examples of how testing strategies differ per environment and team.
At the end, you feel the fulfillment of a customized, holistic testing strategy that works for you and your team.
ASP.NET’s been around for a number of years and the team’s developed some DOs and DON’Ts. Let’s explore out very best list of DON’Ts that you can apply today at work! Come see Damian Edwards, Senior Program Manager on the ASP.NET team, share internals, secrets and not-so-secrets of the ASP.NET APIs that you should be exploiting and the ones you should be avoiding.