Software Development Practices in Practice

Dennis Doomenft. Jonne Kats & Peter Hesseling
Software Development Practices in Practice

09:00 – 10:15Iteration 110:30 – 12:00 Iteration 212:00 – 13:00 Lunch13:00 – 14:15 Iteration 314:30 – 15:45 Iteration 416:00 – 17:00 Iteration 5
Agenda
Product Backlog
Aspects of Software Quality
The Demo Case
Acceptance Testing
Domain Driven Design
Automatic Testing
Test Driven Development
Mocking
RefactoringPerformance Testing
Behavior Driven Development
Design Principles & Patterns
Clean Code
CQRS

Orthogonal
Reversibility
Feedback
Iterative Development
Minimal Duplication
Aspects of software quality

Use Evolutionary Design & Reference Architecture
Treat your code as a book
Always check-in with better quality (!= software rot)
Adhere to Clean Code
Use Coding Guidelines
Prevent duplication
The Golden Rules

Don't forget YAGNI
Don't make assumptions on legacy code
Use TDD or BDD
Consider using DDD if applicable
Refactor aggressively
Design towards patterns
More Golden Rules

The Kitchen

Acceptance Testing Driven Development
Jonne Kats

Breaks a complex domain into small chunks
Uses highly expressive models (typically UML sketches)
Intimately involves business
Understandable by everyone
Promotes a loosely coupled design
Provides guidelines for large organizations

Ubiquitous Language
One common unambiguous language
Includes concepts and verbs
Ensures collaborate understanding of the domain
Originates from business
Maintain a glossary (incl. translations)
Apply to everything; code, tests, UI
When refactoring, refactor everything

Entity
Has identity in domain
Identity never changes
Enforces business rules on its properties
Is not directly accessible
Often has a functional identifier

Value Object
No identity, just lightweight data
Immutable
Behaves like a primitive type
Often reusable
Examples: TimeFrame, ISBN, PostalCode, Email, Address

Aggregate
Closely related entities and value objects
Has global identity
Only accessed through its Aggregate Root entity
Ensures integrity of all entities
Typically loaded and saved as one unit
Loaded using a repository and (often) created using a factory
Deleting the root, deletes everything in the aggregate

Domain Services
Stateless
Often the entry point into the model
Enforce rules on multiple aggregates
Implemented as methods or Commands

Strategic Design
Bounded Contexts
Context Maps
Shared Kernel
Customer/supplier development teams
Conformist
Anti-corruption layer
Separate Ways

Unit Tests
Fast in-memory tests
Independent of any resources
Integration Tests
Access databases, files, services, I/O
End-2-End Tests
Full tests including all related systems
Automated Testing

Small and focused
Intention revealing
Repeatable
Have no side-effects
Independent
Have a clear name
Tests should be...

It is important not to show what is not important
Use Object Mother or Test Data Builder
Signal the importance of variables using 'a', 'the', 'some‘
Start small
Test what you know now (and assemble the rest)
Guidelines for testing

Isolate The Ugly Stuff
Use Dependency Injection
Prefer state-based tests
Test one condition
Guidelines for testing

Is a design process
Great for quality tests
Tests are your first users
Can be your documentation
If TDD hurts => you're doing it wrong
Red-Green-Refactor
Better for state-based tests
28 May 2009
Dennis Doomen

Design Effects
More client control
More interfaces/factories
More focused
Less coupling
Problems
UI
Persistent Data
False sense of security
Losing the overview
More code to maintain

Stubs are stand-ins with fixed values
Mocks can be used for expectations
Frameworks: Rhino Mocks, NMock, MOQ, TypeMock (commercial)
Guidelines
Don't mock chatty interfaces
Don't have more than 2-3 mocks per test
Only mock your nearest neigbors
Mocking
28 May 2009
Dennis Doomen

Karl Seguin wrote:
Refusing
Getting too excited
Testing everything!
Integration testing
Discover mocking
Mocking everything
Becoming effective
Phases of automated testing
28 May 2009
Dennis Doomen

Safe Delete
Encapsulate Field
Use Base Type where Possible
Replace Constructor with Factory Method
Convert Extension Method to Plain Static (vv)
Convert Method to Property (vv)
Convert Property to Auto-Property
Extract Class from Parameters
Rename Member / Type
Rename / Move Namespace
Extract Interface / Method / Superclass
Pull Up & Down
Introduce Field, Variable or Parameter
Move To File (in Folder)
Change Signature
Refactoring

Performance Testing
Peter Hesseling

Flows naturally from user storiesAs a...I want...so that into Given...when...then
More behavior oriented
‘TDD Done Right’
Great for exploring the Ubiquitous Language using exploratory specs
Seems easier to start with
More intention revealing
Difficult to implement with MSTest
No single framework (yet)

MSpec 0.3

Subspec

The Kitchen Reference Architecture
Dennis Doomen
Application Shell
Silverlight 4
Views (XAML + C#)
DI
MVVM Support
View Models
Commands
Controller
Kitchen Context
Application Services
Unity for SL
DTOs
WCF RIA Services
Enterprise Library
Kitchen Service
Domain Model
Domain Events
Domain Services
Translation
Policy Injection
Validation
Logging
DI
NHibernate(+ Fluent & LINQ)
Service Agents
Unit of Work
Repositories
AutoMapper
Database
Backoffice Systems

The Principle of Least Surprise
Single Responsiblity Principle
Open Closed Principle
Liskov Substitution Principle
Interface Seggregation Principle
Dependency Inversion Principle
Law of Demeter (a.k.a. Writing Shy Code)
Command Query Separation
Design Principles

Patterns

Communicate design
Solve common challenges
Promote object-oriented design
Promote loose coupling and reuse
Go hand in hand with S.O.L.I.D.
Purpose of Patterns

Technical Patternssingleton, factory, adapter, chain of responsibility, strategy, state, bridge, proxy, command, interpreter, mediator, memento, observer, template, composite
Architectural PatternsCQRS, layer supertype, SOA, MVC, MVP, PM, Pipes & Filters,
Patterns Examples

Domain Patternsdomain model, transaction script, business actions, entity factory, repository, entity, value object, aggregate, domain service, domain events, specification, query objects Strategic PatternsShared Kernel, Customer/Supplier, Conformist, Anti-Coruption Layer, Separate Ways
Patterns Examples

Gregg Irwin said:
You use it without being aware
You hear about it, read up on it, and tinker a bit
You learn more and start using it explicitly, if naïvely
You get the fire and evangelize
Something "clicks"
You learn more and apply it "less naïvely" and more implicitly
Time passes and you see flaws
You question the concept (often because you misapplied it)
You either forget about it or add knowledge and experience
You use it without being aware that you're using it
Phases of Pattern Adoption

Only if the data and actions are available in all states!
State Pattern

Domain Event Pattern

Query-by-Example
Query Object
Specification
LINQ
Query Patterns

Used in WCSF
Many interaction tests
Requires a lot of mocking
Strong view control
Model View Presenter

Few interaction tests
Many state-based tests
Requires less mocking
No view control
Presentation Model

Microsoft variant of PM
Easy data binding
Bi-directional synchronization
Model View View-Model

Responsibilities
Hides access to the DB
Behaves like a collection (implements ICollection<T>)
Could support Transparent Persistency
Lazy loading
Automatic flushing
Provides optimizations such as caching
Provides exception shielding
Repository Pattern

Recommendations
Use an ORM such as NHibernate, Entity Framework or LLGenPro
One repository per DDD aggregate root
Use interfaces to allow faking/stubing
Implement IQueryable (LINQ)
Use Query Object or Specification patterns
Repository Pattern

Responsibilities
Encapsulate peculiars of external systems
Reduces impact of changes
Facilitate single sign-on
Caching
Resistant against temporary network problems
Monitoring and tracing
Service Agents

Recommendations
Use interfaces to enable mocking/stubbing
Use service agents for reporting servers and/of file I/O
Use a workflow
Service Agents

Clean Code

Smells
Too many, output or flag arguments
Inline Comments not related to a complex algorithm
Dead Code
Inconsistency (solve similar problems with similar solutions)
Artificial Coupling
Obscured Intent
Misplaced Responsibility
Clean Code

Guidelines
Functions Names Should Say What They Do and Should Do One Thing and be short
One Switch To Rule Them All (!)
Be Precise
Don' Mix Levels of Abstractions
Always treat warnings as errors
Clean Code

Case Study
The Kitchen

US01 - Als kok wil ik recepten kunnen bijhouden met titel, beschrijving, instructies, bereidingstijd, ingredienten en moeilijkheidsgraad.
US02 - Als kok wil ik kunnen zien wat de kosten van een recept bij benadering zijn (op basis van de productprijzen)
US03 - Als kok wil ik per eter een profiel kunnen bijhouden met naam, adres, telefoonummer en adresgegevens.
US 04 - Als kok wil ik per eter kunnen aangeven of een eter allergisch is, dat product niet lust, of liever niet eet
US05 - Als kok wil ik een boodschappenlijstje kunnen genereren o.b.v. een of meerdere recepten.
User Stories
Dennis Doomen

US06 - Als kok wil ik de boodschappen kunnen laten bestellen bij AH's Albert.nl
US07 - Als kok wil ik dat de applicatie een willekeurig recept of weekmenu kan genereren, rekening houdend met de voorkeuren van mijn club/gezin
US08 - Daarbij mogen gekochte recepten van de laatste 2 weken niet herhaald worden.???
US09 - Als kok wil ik mijn vrienden van Hyves, Facebook en mogelijk andere social networks kunnen importeren als profiel
US10 - Als eter wil ik mijn waardering voor een recept kunnen opvoeren
US11 - Als architect wil ik dat de applicatie op termijn met meerdere bestelservices moeten kunnen werken
User Stories
Dennis Doomen

US1
Als kok wil ik recepten kunnen bijhouden met titel, beschrijving, instructies, bereidingstijd, ingredienten en moeilijkheidsgraad.

US1 Domain Model

Initial Reference Architecture
Dennis Doomen
Views (XAML + C#)
Kitchen Service
Domain Model
Database

US1-A
Als kok wil ik recepten kunt zoeken op titel, ingredienten, moeilijkheid en bereidingstijd

US2
Als kok wil ik kunnen zien wat de kosten van een recept bij benadering zijn (op basis van de productprijzen)

US2
(onderdeel van US2 – de product beheer scherm. In dit scherm worden product-unit-prijs gegevens vastgelegd en beheerd)

US2 Domain Model

US3
Als kok wil ik per eter een profiel kunnen bijhouden met naam, email, telefoonummer en adresgegevens.

US3 Domain Model

US4
Als kok wil ik per eter kunnen aangeven of de persoon allergisch is, het product niet lust, of het product liever niet eet

US4
(onderdeel van US4 – toevoegen/wijzigen van de eter voorkeur gegevens)

US4 Domain Model

US5
Als kok wil ik een boodschappenlijstje kunnen genereren o.b.v. een of meerdere recepten.

US6
Als kok wil ik de boodschappen kunnen laten bestellen bij AH's Albert.nl

US7
Als kok wil ik dat de applicatie een willekeurig recept of weekmenu kan genereren, rekening houdend met de voorkeuren van mijn club/gezin

US9
Als kok wil ik mijn vrienden van Hyves, Facebook en mogelijk andere social networks kunnen importeren als profiel

US9
(onderdeel van US9 – profiel import scherm, per social network)

US10
Als eter wil ik mijn waardering voor een recept kunnen opvoeren

US10
(onderdeel van US10 – als kok wil ik de mening van de eters over een recept kunnen bekijken)

The Kitchen Reference Architecture
Dennis Doomen
Application Shell
Silverlight 4
Views (XAML + C#)
DI
MVVM Support
View Models
Commands
Kitchen Context
Application Services
Unity for SL
DTOs
WCF RIA Services
Unity
Kitchen Service
Domain Model
Domain Events
Domain Services
Translation
DI
NHibernate(+ Fluent & LINQ)
Service Agents
Unit of Work
Repositories
AutoMapper
Database
AH, Hyves, Facebook

Software Development Practices in Practice

by Dennis Doomen on Feb 28, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 13

Statistics

Software Development Practices in Practice — Presentation Transcript