Quality Java Codeand how we can ensure it Presentation by Oliver Doepner
Motivation∘ Lots of talk about Quality∘ What does that mean for Software Developers?∘ Code Reviews are the main recommended practice.∘ But what are the criteria for the reviews?∘ How do we come up with those criteria?∘ What is high quality code (=> criteria)?∘ How do we produce high quality code (=> practices)?∘ How do we ensure quality code (=> process)?
What is Quality Code (QC) ?Quality Code does the job (satisfies requirements). Is that enough? - No! ∘ Maintenance > 60% of software costs ∘ Understanding software > 50% of maintenanceQuality Code is built for change and maintenance. ∘ Allows for changes and improvements ∘ Does its job under changing conditions ∘ Makes trouble shooting easy ∘ Is (at least partially) reusable
Built for change and maintenance∘ Easy to understand (readable, well documented, ...)∘ Properly modularized. But not over-engineered.∘ Small changes easy. Big changes possible.∘ Has a test suite that covers its functionality.∘ Robust execution (handles corner cases, exceptions)∘ Proper logging, helpful log messages∘ Flexible (not too many hardcoded assumptions)∘ Bugs can be localized and fixed in one place.∘ Business logic in separate modules / layers∘ Does not reinvent the wheel. Follows standards.∘ Passes code inspections. No compiler warnings.∘ Efficient use of resources (memory, cpu)
Focus of this presentation1) Quality Code is easy to understand.2) Quality Code is properly modularized.Understanding a complex software application by reading itscode is usually difficult.Properly modularized code is easier to understand.=> Each part should be easy to understand.=> Understand the parts of the system / their interaction.=> Understand the system as a composition of its parts. Modularize = Structure as functional components Understand = Read, analyze, predict, change, control
Principles for proper modularization∘ High cohesion / Low coupling=> Clear separation of concerns∘ Well defined public APIs=> For packages, interfaces, classes, use Javadoc∘ Encapsulate data / hide implementation=> Limit scope and visibility∘ Locality: Small / short scopes=> declare late, avoid nesting, use methods∘ Immutability: Most data should be final=> final fields, final local variables, read-only APIs∘ "Dont repeat yourself" (DRY)=> Avoid copy & paste∘ Structure your codebase=> Use packages, maybe modules, client/server
What else makes code easy to understand?- Follow coding standards (Sun + X)- Readabilty / Meaningful naming- Sufficient up-to-date comments- Javadoc for all public methods- No unnecessary indirection- Lines of code: Less is better
Habits / Practices- Use Code Inspections / enable warnings- Write unit and integration tests- Use refactoring- Use strong types / generics- Use continuous build & integration (runs all tests)- Check in groups of related file changes- Use Javadoc to document public APIs for other devs
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.