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 recommende...
What is Quality Code (QC) ?Quality Code does the job (satisfies requirements).  Is that enough? - No!  ∘ Maintenance > 60%...
Built for change and maintenance∘ Easy to understand (readable, well documented, ...)∘ Properly modularized. But not over-...
Focus of this presentation1) Quality Code is easy to understand.2) Quality Code is properly modularized.Understanding a co...
Principles for proper modularization∘ High cohesion / Low coupling=> Clear separation of concerns∘ Well defined public API...
What else makes code easy to understand?- Follow coding standards (Sun + X)- Readabilty / Meaningful naming- Sufficient up...
Habits / Practices- Use Code Inspections / enable warnings- Write unit and integration tests- Use refactoring- Use strong ...
Upcoming SlideShare
Loading in …5
×

Quality Java Code

220
-1

Published on

Some basic principles of good Software Engineering with focus on Java code

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
220
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Quality Java Code

  1. 1. Quality Java Codeand how we can ensure it Presentation by Oliver Doepner
  2. 2. 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)?
  3. 3. 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
  4. 4. 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)
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×