Scribd
Upload
5 views22 pages

AgileAndDesign Evolution

Uploaded by

HellHackers
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
5 views22 pages

AgileAndDesign Evolution

Uploaded by

HellHackers
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 22

Quick Survey

How many of us

• are in Agile Development?


• use TDD (Test Driven
Development)?
• work on Java pla:orm?
• work on .Net pla:orm?
Waterfall

2
Agile

3
What has Changed?

No Big Design Upfront

Clear separaCon between Architecture and Design

Less focus on Paper/DocumentaCon

Focus on Today’s requirements

More prepared for change

More focus on Code

4
No Big Design Up Front

No separate Design phase

Everyday focus on Design


• No Design Rot

Design Evolves

Decisions made Just In Time


5
Design Architecture Demarcated

Architectural Decisions are hard to change


• Which framework to use for front end?
• Do we want to use ORM?

Design Decisions today are easy to change


• What should be done in a super class?
• Should a class be abstract?
• Should you have a separate method for a
funcConality?
• Should you create a new class?

6
Less focus on Documentation

Detailed Design Documents


• Are usually outdated by the Cme first development
cycle is complete?
• When rubber meets the road, there will be
changes
• Are not updated when code changes
Architectural DocumentaCon is important.

Less focus doesn’t mean NO documentaCon.

7
Focus on Today’s Requirements

Requirements Change. PERIOD.

Aim to meet today’s requirements with


Clean Code.

Complex Design only when Simple Design


does not solve the problem.
• Start simple and evolve to use Design PaXerns

8
Change is Expected

Things Change. PERIOD.

BeXer Prepared for Change


• Good automated test bed
• Simple Design
• BeXer Refactoring tools
• BeXer Build tools - Maven
9
More Focus On Code

“Code” is given utmost importance

Design discussions are done over code

Designer’s are expected to Code

Developer’s are expected to Design


• And this is where the importance of making Design
simple is important. Even starCng developers are
expected to be able to Design.

10
Basic Knowledge for Designer

Focus on Principles

4 Principles of Simple Design

SOLID Principles

Test Driven Development


• Refactoring

11
Standards vs Principles

Clarity of Code

Complexity of a method should less than equal to 10

Length of the method < 35

A class should not be greater than 500 lines

There should not be Magic Numbers


12
Problems if we follow only Standards

Standards change.
• Numbers like 35 (Method Length), 10 (Complexity), 7 (lines of duplicaCon) change

Tools Improve every day


• 3 Types of DuplicaCon – Now sonar finds Type 2 duplicaCons as well.
• JavaScript rules for complexity.

Most important Maintainability rules are not checked by the tools


• How good the variable/method names are?
• Is decomposiCon properly done?

Standards without understanding principles causes problems


• SituaCons like public staCc int ZERO = 0;
• doThis() calls doThis1() and doThis2()

13
4 Principles of Simple Design
o Runs all tests

o Contains no duplicaCon

o Express intent of programmers

o Minimizes number of classes and methods

14
SOLID Principles
oS SRP - Single responsibility principle

oO OCP - Open/closed principle

oL LSP - Liskov subsCtuCon principle

oI ISP - Interface segregaCon principle

oD DIP - Dependency inversion principle

15
TDD

16
TDD

17
Refactoring

o Altering Structure of Code without affecCng “Behaviour”

o Toughest part of Refactoring is the order or sequencing of


Refactoring steps

o ConCnuous Refactoring – aided by Tests – leads to “Clean


Code”

18
Example Code 1

19
Example Code 1

20
Example Code 2

21
Thank you

You might also like